Talk:Page Previews

Jump to navigation Jump to search

About this board

Page Previews solves the core problem of users opening multiple tabs to gain an understanding of a word in the context of the subject they are reading. Whenever a reader hovers over a link to another article, a short summary of the subject, including its graphical image, is provided to them so they can decide whether they need to visit that subject more fully before continuing the current subject.

Please give us feedback on your experience using this feature so we can change and improve it. Each language is welcome in this discussion!

You can read more about the feature here.

Known Issues

Seeing missing images in Enable/Disable section

2
Heading (talkcontribs)
TheDJ (talkcontribs)

Fixed, someone messed with the spelling of the filenames

Reply to "Seeing missing images in Enable/Disable section"

Many images missing in preview after upgrade to MW 1.35

2
Summary by 2003:C2:3F22:8200:D1CD:FA3A:8FEF:9D5D

chown -R www-data:www-data ....../mediawiki/images

2003:C2:3F22:8200:C1BD:F620:4468:F03 (talkcontribs)

Howdy,

we are using PageImages/TextExtracts/Popups for some years now and are more than just pleased. It always worked fine and I cannot imagine how to get along without it. Recently I upgraded our test wiki from MW 1.31.15 to 1.35.4. Unfortunately, as a result there are several images missing now in the page preview, while others are still there.

I am confused: When looking into the page props, the images are there in either case, whether the page preview does show an image or doesn't. So, if the page prop image is set, what could be the reason that an image is missing in the preview?

I found many examples where the image is not being displayed in the test wiki but (for the same articles) it is always displayed in our live wiki. Also, I have already run the rebuildLinks script, but as mentioned above the page prop images are correct anyway, with or without the script.

I should tell ... there is one low trick we exploit. We use links belonging to a separate namespace, which are simple redirects to the main namespace. But, again, the page prop images are all set, in every single case I examined. Nonetheless, some of them appear in the preview, some not.

2003:C2:3F22:8200:D1CD:FA3A:8FEF:9D5D (talkcontribs)

Found and solved! There was a problem with the user rights. Owner of all image files was "root"; changed to "www-data" (just like in the live wiki) and now the page previews work as expected.

(On the other hand: now I don't understand why several page previews _did_ work ... but honestly ... it's totally irrelevant now.)

Reply to "Many images missing in preview after upgrade to MW 1.35"

Need a magic word to change default image

7
Bilorv (talkcontribs)

I've had two conversations on enwiki in the last few months where it has been desirable to change the image shown in a page preview to something that is not what the tool identifies as the first image in an article. For simplicity: imagine that we don't have an image of Actor X, but midway down their article we talk about their comedy duo work with Actor Y (pictured) and so Actor Y is shown in the Page Preview, clearly misleading as the person doesn't match the name. The only solutions are getting a picture of Actor X (could be literally impossible) or removing all images from the article (could be very undesirable). At least, those are the only solutions I'm aware of.

To me the obvious solution would be a magic word or something that we can encapsulate in a template so that I can write {{PagePreview|None}} to have no image in the page preview, and ideally I can also write {{PagePreview|Image.jpg}} to override the first image as preview and instead use Image.jpg.

It is hugely undesirable for the only solution to be changing the primary rendered article layout in order to accommodate for a secondary layout feature like Page Previews.

I'd be delighted, of course, if there is any other solution and I'm just not aware of it, so please correct me if I'm mistaken.

(Please ping me or do something that gives me a cross-wiki notification so I'll notice replies to this.)

FMM-1992 (talkcontribs)

@Bilorv: another solution is only use the infobox image

Alsee (talkcontribs)

@Bilorv, you said imagine that we don't have an image of Actor X, but midway down their article we talk about their comedy duo work with Actor Y (pictured) and so Actor Y is shown in the Page Preview. Please clarify whether you have actually seen this happen recently?

I discussed this exact issue with the developers, and I believe it was fixed abut five years ago. PageImage should only be grabbing images from the lead section. Ah... I found the Phab tasks to fix this. See task T87336 on the issue, and fix-deployment in task T152115.

Bilorv (talkcontribs)

Ah sorry @Alsee, I didn't know it only grabs images from the lead. This was the reason I didn't want to add an image to an article but I didn't actually test it out and check. I guess that reduces the number of uses of this but there is still a more complex case on en:Pornhub where consensus is changing but there was a suggestion at one point that might reasonably have been the one with consensus where an infobox image identified as the first in the page (a screenshot of the website) would have been kept in the article, but suppressed from the Page Previews (so that no image would be shown, or possibly a custom-specified image). Possibly less contrived is en:Talk:2020 Labour Party leadership election (UK)#Main image where we would have liked to omit an image to avoid seeming to give preference to one candidate in a current election.

These each seem like a concrete use case which is impossible to implement at the moment. Or am I wrong on this too?

Alsee (talkcontribs)

Yes, displaying one candidate in election articles (and other cases) is a serious problem. It makes Wikipedia appear grossly biased, it affects a fairly significant number of articles, and it creates a severe dilemma for editors. I raised that issue around he same time (about 5 years ago), but it never got traction with the devs.

We definitely need some way to control, override, or exclude image selection, or to ensure images are not displayed unless the required multiple images are displayed side-by-side. In particular I'd say it needs to be some kind of fix or option we can add in a template, to address all new and open election articles at once.

I don't know if staff are still watching this page and active on this project. If someone from the Foundation doesn't pick up on this task soon, it might help to organized a community call to get this fixed.

Jason Quinn (talkcontribs)

Here's an example how page preview can lead to problems: the article "Beg bugs" has a hyperlink in the lead for "Skin rashes" and if you hover over it with page preview on, it shows the image in the lead there. BUT that image of a skin rash looks nothing like the skin rash that bed bugs produce. So a person hovering over the link and scanning quickly might end up misinformed about bed bugs by assuming the image is apropos when it is not.

I do not know how this could be solved. Some possible avenues would be to extended the wikilink syntax to include other parameters (perhaps the best but would be a big change) or to wrap the link in a template that controls the page preview behavior (ugly solution).

FMM-1992 (talkcontribs)

@Jason Quinn also yesterday I was reading w:en:The Ultimate Gift and hovered over "Ali Hillis" on its infobox, the only things you can see in the preview image is her chest and half of her face.

Reply to "Need a magic word to change default image"

Works when not signed in, but not when signed in

3
2601:600:9D80:3F80:18F:D3A1:1D70:1F0 (talkcontribs)

Took me forever to figure out why Previews worked at times, an other time not. Turns out that when I'm not signed in, Page Preview works. When I notice I'm not signed in, an do so, the Page Previews no longer work.

No changes in browser settings, extensions, etc.

Nihiltres (talkcontribs)

Check your preferences. Are page previews enabled there?

TheDJ (talkcontribs)

Page previews were never mass enabled for pre existing users. So if you never manually enabled it, then you still need to enable in your Preferences. They are in the appearance section and then: Enable page previews.

Another reason can be that you have some sort of competing gadget or user script installed. Navigation popups for instance disables Page Previews.

Reply to "Works when not signed in, but not when signed in"
Mrspagehttiwe2019 (talkcontribs)

Which image do you see in a page preview?

Reply to "Images"
2600:1008:B150:2F09:E0B5:7116:DB1C:3DF0 (talkcontribs)

I'm sure this has been mentioned before, but what about article titles which contain parentheses that actually are part of the name of the subject? The page preview seems to work with chemical elements that have parentheses in the title, but looking at the preview for Brandy (You're a Fine Girl) leaves out the remainder of the song title which is in parentheses.

Niedzielski (talkcontribs)

I think this has been discussed previously but I'm not sure what the current thoughts are on it. I've opened a ticket for discussion with the maintainers: T226323.

W.andrea (talkcontribs)

Currently anything in parentheses is hidden in the preview, but I think anything in bold should be shown.

Sparkie82 (talkcontribs)

This could be implemented generally as a LocalSettings variable containing a list of terms, which when found within the text of a page, cause the parenthetical stripping to be disabled. Another solution is to have a LocalSettings variable containing a RegEx for parenthetical text that should be included in Page Preview. ~~~~

Another user case where this is a major problem is with Bios. The subject's DOB and DD are usually within parentheses immediately following their name. e.g., John Doe (26 BCE - January 1, 1955). When I come across an unfamiliar name while reading WP, I almost always need to know the time period when the person lived (and most of time that's all I need to know about them), however, Page Preview doesn't show the dates. Maybe when fixing the other parentheses issues you could fix this too (or make sure the fix addresses this user case. ~~~~

Reply to "Parentheses as part of title"

Help - Cannot enable Page Previews on my wiki

2
178.235.2.148 (talkcontribs)

I just updated my mediawiki from 1.30 to 1.34 (including database upgrade and PHP version upgrade) specially for this extension. I did check if the dependencies mentioned on the extension's page are enabled and installed (one was commented out). Checked Preferences - no option to turn it on/off. I've added lines proposed on the extension's page to LocalSettings.php (not sure if in the correct place as I know nothing about php):

wfLoadExtensions([

   'TextExtracts',

   'PageImages',

   'Popups'

]);

$wgPopupsHideOptInOnPreferencesPage = true;

$wgPopupsOptInDefaultState = '1';

$wgPopupsReferencePreviewsBetaFeature = false;


Page Previews do not appear. What to do?

Here's the wiki - wiki.mrowki dot ovh

178.235.2.148 (talkcontribs)

Somehow it started working on its own. This is probably the only translated Extension name on my Specia:Version list... (I can't ask "why?" enough).


The next problem is, popups do not display images (its a white rectangle space instead of an image). Most of my pages have images put in infoboxes made of HTML code, not sure if this does break things. Is there a way to hide images?

Reply to "Help - Cannot enable Page Previews on my wiki"

Page preview for institutionalized racism

2
174.82.109.48 (talkcontribs)

I was browsing and noticed the page preview for institutionalized racism is currently fairly offensive and racist but I don't know how to go about editing it.

Niedzielski (talkcontribs)

Page previews are derived from the opening content of the pages they point to. I have seen, but been unable to track down, caching issues where the preview shown is for an older page revision. This is especially problematic for vandalized revisions. These caching issues are usually resolvable by manually purging the cache for the given page. E.g., https://en.wikipedia.org/w/index.php?title=Institutional_racism&action=purge

Reply to "Page preview for institutionalized racism"

Preview shows template code

3
JamesLucas (talkcontribs)

I noticed that the preview card for w:en:Bohol displays the markup of the infobox template rather than the first sentence(s) of the article proper. Aside from the infobox contents including a relatively large number of sub-templates, I'm not immediately seeing anything too far out of the ordinary. I didn't want to try troubleshooting by testing on the live article, and I thought I'd check for answers here before taking this to a sandbox. Anyone have a sense of what's broken? Cheers.

Quiddity (WMF) (talkcontribs)
Niedzielski (talkcontribs)

The template is in the page previews summary endpoint response, no surprise. It's my understanding that the summary endpoint uses Parsoid and it's in that too. I manually bisected the article's diffs (being mindful of possible caching and purging concerns) to see when it occurred and was able to narrow it down some, I think. My guess is T197523 which I've left a comment on. If you think it's a priority and you agree with the assessment, please consider awarding the task a token.

Reply to "Preview shows template code"

Preview text too short (user feedback from en-wp Help Desk)

1
Tigraan (talkcontribs)

[https://en.wikipedia.org/w/index.php?title=Wikipedia:Help_desk&oldid=945998562#New_page_preview_system Original post]. The complaint says (in summary) that the preview text will often look like "Foo is a game published in YEAR_I_DONT_CARE by COMPANY_I_DONT_CARE on PLATFORMS_I_DONT_CARE (...)" and so the information they want (summary of game story, etc.) is below the fold. There is not much we can do on the Wikipedia side unless we change radically how the lead is written, but maybe the settings (which currently contain only a activate/disable switch) could include a "max length of preview" setting. (I am not saying it is easy especially across various displays, I am just saying that some could find it useful, at the very least the person who complained.)

Reply to "Preview text too short (user feedback from en-wp Help Desk)"