Extension talk:Popups

Previous page history was archived for backup purposes at Extension talk:Popups/LQT Archive 1 on 2015-06-25.

When asking a question about a preview not displaying please ensure to include information on the wikitext of the first section of the target page (markup before first heading double equals signs) and the network request.

We use Popups, TextExtracts, PageImages on our wiki.

We have lots of pages which have no text before the first section heading. In this case, the page preview used to show "..." (1.36), now it says "There was an issue displaying this preview" (1.39)

We have other pages that have no text before the section heading but do have an image. The preview used to show "..." and the image (1.36), now it shows "issue" and no image (1.39)

How can we regain the previous functionality that's been perfectly right for us?

Previous version was 1.35, sorry.

I believe this is a known issue, see phab:T272394 and especially phab:T309760 for the second example.

Ok, great, thanks.

I figured out a way to get around this a little bit by using a P html element as the very first element on the page with a class that is display:none. It was picked up just fine by the Popup. I also use page forms, SMW, and templates so the data input is very regimented and somewhat easier to control than simple free text pages. (SMW 1.39)

This extension seems to call mw.user.sessionId() unconditionally whenever someone visits a page of the wiki, regardless of whether they're logged in or not.

The effect of this is setting the cookie mwuser-sessionId (usually prefixed with the wiki's database name), which means that the wiki visitor in question will not be served any cached HTTP content for any further pages they visit!

Wikipedia seems to have a workaround against this as far as I can tell by X-Cache HTTP headers I receive from it, though I couldn't find any documentation as to how it achieves this. A fairly typical Varnish or Nginx caching mechanism will not be accommodating against this, and thus suffer greatly. (In fact, it could be making the HTTP cache nearly useless, though I haven't made measurements; it might still be useful with SEO bots or such at least.)

Even the Varnish configuration recommended on Manual:Varnish caching is suspect to this issue, as the regex used to match session tokens will match mwuser-sessionId. (EDIT: This may be wrong after all; I had not thought about the equals sign at the end of the regex. Maybe that's the key.)

I wonder if this extension could be modified not to call mw.user.sessionId() for users that aren't logged in? FYI, the two places in the code that call this are src/actions.js:83 and src/instrumentation/statsv.js:23.

This sounds like an issue that should be reported on Phabricator. Can you do this?

@TaylanKammer if you log a phabricator ticket using this bug template, we will have a look as soon as we can.

@VPoundstone-WMF: Just FYI, that form is restricted.

@TaylanKammer since the phab form is restricted, I will post the template here. Please write the ticket and tag Data Products. Thank you!

===Description

====Steps to reproduce (step by step instructions, with links, commands and necessary data to reproduce the error)**

• ...

====Observed behavior

• ...

====Expected behaviour/Acceptance criteria (returned value, expected error, performance expectations, etc.)

• ...

====Test environment info

• ...

====Console logs

• ...

====Screenshots

• ...

===Completion checklist <To be filled in by assignee>

[] Regression tests covering this bug? [] Documentation updated and conforms to [|the accessiblity guide]? [] ...

@VPoundstone-WMF Sorry for not getting back to this sooner. Here's the details. Please tell if more needed.

===Description

Enabling the Popups extension causes a session token to be assigned via JS, after any page is loaded, even for anonymous visitors.

This potentially degrades caching, since HTTP response headers for wiki pages tend to include Vary: Accept-Encoding, Cookie.

====Steps to reproduce (step by step instructions, with links, commands and necessary data to reproduce the error)**

• Disable the Popups extension in your LocalSettings.php file.
• Open a private/incognito browser window or tab, and visit your wiki in it.
• Use your browser's developer tools to confirm no cookies are stored yet.
• Enable the Popups extension in your LocalSettings.php file.
• Reload the visited wiki page in the browser window or tab from before.
• Notice that a session cookie has now been stored by your browser.

====Observed behavior

• Anonymous visitors get a session cookie as soon as they visit any wiki page; apparently through JS code, since the HTTP responses don't include any Set-Cookie headers.

====Expected behaviour/Acceptance criteria (returned value, expected error, performance expectations, etc.)

• Anonymous visitors should not get a session cookie until they've performed some action that would actually require this, such as making an edit.

====Test environment info

• MediaWiki 1.39.6 (https://bg3.wiki/wiki/Special:Version)

====Console logs

• None

====Screenshots

• None

https://phabricator.wikimedia.org/T289780

An update on this from my side: After taking a closer look at the recommended Varnish setup, it looks like the cookie mwuser-sessionId should not affect front-end caching, and I've been able to achieve something near identical with Nginx. The was indeed to only consider cookies matching the regexp ([sS]ession|Token)= with the equals sign at the end.

So, this issue with mwuser-sessionId being set would only affect a very naive front-end cache that's not fine-tuned for MediaWiki and looks at all cookies.

Images in popups are automatically centered, how can I change this to align to the top? At least in my case, the heads of the characters are cut off very often due to centering, and when aligned to the top edge this would not happen.

No ideas?

I am getting this Uncaught ExtensionDependencyError on a clean install of mediawiki using the official docker image for 1.41 (there is no 1.42 available yet). Steps followed:

• Pull the latest docker stable image
• Create a container from the latest image (1.41)
• Create LocalSettings.php and verify dependencies for TextExtracts and PageImages are included and enabled
• Turned off ReferencePreviewsBetaFeature (just in case, but tried with and without this set to false and no difference)
• Comment out the extension and its settings, restart the wiki, verify it otherwise functions normally

Since the extension page says it's compatible with 1.37+, I would assume the error is misleading. Any suggestions?

I learned some more about how the dependency management worked and confirmed that 1.42 is required by the Popups extension. That version is not released yet. Is there a workaround, such as downloading a slightly older Popups version that works with 1.41?

I had it working on MW1.35, but upgraded to MW1.39. The master branch, and REL1_39 branch, of this extension caused 500 errors because they both require MW1.42.

I checked out the REL1_37 branch and it all worked again :-)

For MW1.41 it's probably something similar - just work your way down the branches till one works.

I have a wiki hosted by miraheze.org and I can enable popups, and they work, but I would like to be able to selectively enable or disable them for a page. I am going through the web-based menu and don't have MediaWiki downloaded.

Is there a way to enable or disable popups within a page's code?

The documentation mentions $wgPopupsPageDisabled = [ 'Example' ];. Isn't this what you are looking for?

I get the annoying popup message in any article with no content in the lead section.

On my vragwiki I prefer dividing into sections and starting with a section. Is there a workaround?

Its no problem when using gadget Navigation popups, only at extension Popups.

What the Popups extension internally does is a TextExtracts API call like this one. Technically these articles don't have an intro when they start with a section heading. This is a limitation of the TextExtracts extension. As far as I'm aware of there are currently no resources to improve the code that is responsible for this. We discussed some workarounds in a previous thread. You can try if these work for you.

I finally disabled $wgPopupsTextExtractsIntroOnly and after moving pictures before the heading everything works fine if not beeing logged in and using the popup-gadged instead. Thanks!

I noticed that popups don't work for links inside svg, for example made via Extension:ImageMap. Is this really the case, and is there any way to fix this?

Do you have a link to a page with such an SVG that I could take a look at?

It seems that the extension is hardcoded to show only the article title as bolded and the rest is plain text. However, I wish to have page previews similar to Wikipedia, where the bolded text is as shown in the article with contents in parenthesis is left out. Is there a means of getting this? Can this be done in MediaWiki:Common.css? If so, does anyone know a code?

As of now this is intentionally hard-coded in the Popups extension as well as in the TextExtracts API that serves the text snippets.

Hi

on our company wiki we have a page for each user with their info (mail, room, phone etc.) in the top of the page.

The generated popups have the line breaks stripped from the info, which makes it hard to read

should look like this:

phone

room

mail

department

but does look like this:

phone room mail dep

artment

i spent hours fiddling with templates and modules to implement some kiond of padding with dots and/or invisible non-zero-length characters but have had no luck so far in making this work for all user (or even one)

I appreciate any kind of help

~~robert

I think there is currently no way to influence the formatting in the popup, except you make changes to the code of the Popups extension, and probably the TextExtracts extension as well. Since T233099 it should also be possible to inject new popup types from your own extension.

Hi Thiemo, Thanks for the pointer.

I'm wondering what part of Popups would need to be changed. TextExtracts does include the br elements in the summary. Where do they get stripped?

~~robert

Per 188.149.42.241: The page cannot start with ==TEXT== and images are not drawn from the gallery code. So for those that might have the same problem, your page should start with just some text, maybe a short description depending on what you're making, before starting to put in headings. And there have to be at least one image that is not inside a gallery tag.

Pop-up works but it displays nothing but "There was an issue displaying this preview".

Please provide more context, or direct links to specific examples, so that people can understand where the issue is (which wiki, which page, etc) and try to replicate it, or provide other relevant advice or pointers. Thanks.

Sorry...

I think it's solved now though. The page cannot start with ==TEXT== and images are not drawn from the gallery code. So for those that might have the same problem, your page should start with just some text, maybe a short description depending on what you're making, before starting to put in headings. And there have to be at least one image that is not inside a gallery tag.