TL;DR: Google Images is able to pick up source images with an invisible anchor tag linked to the source image URL.

In T54647#9311769, @TheDJ wrote:

In T54647#9311456, @alistair3149 wrote:

Our wiki has a significant amount of images and a decent amount of organic traffic, but the original resolution images and file description pages are almost never indexed.
URLs with index.php can be indexed properly by Google Images.

Well in that case... you could just try adapting the image linker.php class and swap links to images from the shortened form to using the index.php form ?
If they only filter out urls pre-accessing them (which I suspect is what they are doing), then that might just be enough.

In T54647#1586766, @Ciencia_Al_Poder wrote:

This issue has been brought up again in support desk: Images only indexed as thumbnails by search engines

Well, something needs to be done here, so I'll start proposing an idea at least. An RFC may be needed

• Default link for embedded images should be the original version (high res)
• Use the [[ http://www.w3.org/TR/html-longdesc/ | longdesc ]] attribute to point to the file description page
• With JavaScript, place a small icon over the image (only visible when hovering over the image), that clicking on the icon would open the file description page. Clicking on the image will open the original image.
• Next to the image add a link (hidden by default, only visible for text browsers) to the file description page. On images embedded using frame or thumb options it won't be rendered (maybe add the normal link on frame same as on thumb, on the container box)

Our wiki has a significant amount of images and a decent amount of organic traffic, but the original resolution images and file description pages are almost never indexed.

Hoping to bring this to attention for more people and continue the discussion.

Not within a few weeks unfortunately, I don't have a setup that can test it at the moment.

It shouldn't affect any styling since the <picture> element do not contain any styles. We tested with VE on the wiki that is linked above, no regression has been found with it. As for MobileFrontend, it would require some additional testing.

Would it work if RelatedArticlesUseCirrusSearchApiUrl is default to null?

Would this be backported to 1.39 since it is arguably a regression with the ToC?

In T282500#8532625, @Tinss wrote:

@alistair3149, thanks for the patch. Will there be a way to disable the default PWA behavior ?

All patches are now merged.

Thank you for the invitation! I'll think about it but I'm unsure since I am not as active in WMF projects and it's pretty far.

In T282500#8471899, @Jdlrobson wrote:

@alistair3149 would you be interested on working on this ticket to move the API to core with me reviewing your patches? I am going to be taking a break over Christmas, but would be happy to work with you towards that in January if you feel inclined.

In T321708#8461912, @Saklad5 wrote:

In T321708#8461868, @alistair3149 wrote:

Just to confirm, Passkey as 2FA works fine on desktop right?

It did in October, yes.

I switched my account to TOTP upon encountering the issue. Let me know if you want me to switch it back temporarily to see if it still works.

As far as I know, all versions of Safari share the same functional implementation. My best guess is that MediaWiki is violating the specification somewhere, and it only works on macOS due to undefined behavior.

I have a working theory that WebAuthn does not work on MobileFrontend because the ResourceLoader module is not loaded at all.
WebAuthn requires Javascript to complete the verification process.

In T321708#8355310, @Saklad5 wrote:

OK, I've tested WebAuthn 2FA with Wikipedia, and found an unusual issue: I can successfully create and use a passkey on macOS 13.0 and Safari 16.1. However, when attempting to use it to login on iOS 16.1 and Safari 16.1, Wikipedia's login flow doesn't seem to prompt for a passkey at all.

Instead, it simply says "Please touch your verification device or follow the instructions from the browser". It has a single button, "Continue login", which causes the verification process to fail when pressed. My iPhone definitely has the WebAuthn/passkey credential I registered on my Mac: it just isn't getting asked for it like the latter is.

Is it possible that there is some sort of mobile-specific bug with the WebAuthn implementation?

I can work on a patch to merge hCaptcha and reCaptcha in its current state, but I wanted to gather some feedbacks on the topic before I proceed.

In T270437#8399835, @Lectrician1 wrote:

Shouldn't a Dockerfile be modified to run chmod o+rwx cache/sqlite so the user doesn't run into this error every time and then be required to run it?

I have fixed up the lingering issues on the patch above. Is there anything else that is needed to move this forward?

I think it makes sense to move the manifest API from MobileFrontend to core, it'll reduce maintenance and benefit other configurations.

• While getting the author is reasonably straightforward (although Commons lacks machine-readable markup in some edge cases, like T68606: Media viewer fails to give credit to all people in specific circumstances or T89692: CommonsMetadata cannot differentiate between license of the image and other licenses ), schema.org wants the value to be a structured object (an Organization or a Person), not text. I guess we could produce the name and sometimes the url fields at least.

Currently my workaround was just asking people to load the skin last since it will ensure the hook to run at the end :-/
I tried to avoid tempering with HTML in PHP as much as possible. Hopefully T315015 will address the problem down the line, and it also makes much more sense that way for other uses.

Thanks for the reply.

As a skin developer, I agree with @matmarex here that making it a config would make it less friendly to third parties, at the very least for skin developers. The menu registration from @Jdlrobson is a much better approach.

I ran into the same issue recently with a skin that I am working on.

Wikiapiary had been down for me since yesterday.
The error below is reproducible on all pages I tried.

Sorry! This site is experiencing technical difficulties.
Try waiting a few minutes and reloading.

Just want to chime in some information for community use cases outside of WMF.

Would it be possible to have a separate high contrast mode with legacy link colors (maybe through prefers-contrast media query)? That might address both the contrast and the technical debt issue.

For the active tab style, there might be accessibility issue since the only visual difference is the text color and the border color. I would suggest adding an inset box shadow on the active tab so the border would be thicker without causing any wrapping.

Would it be possible to add some kind of short description associated with the menu item?
It will be useful for providing additional context as secondary text or tooltip.

Adding to what @Soda mentioned above:

To add to the suggestions, some of the existing features in other WMF extensions might be useful and they can be reused:

Separating namespace and base page name in HTML is an awesome addition. I am commenting here instead of T236215 since this is tagged for MediaWiki-Core-Skin-Architecture.

Thanks for the quick reply.

@Krinkle Thanks for the through insights, it's very helpful!

The issue stemmed from how NativeSvgHandler build the thumbnail originally. It is mitigated in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/NativeSvgHandler/+/699969

I can reproduce the same issue on the current master branch (1.39) with the local docker setup documented in DEVELOPER.md, which is also using SQLite as database.

Please let me apologize for replying to an old comment, as I just stumbled upon this task no long ago.
I have been reading the related tasks and have caught up with the conversation.

I can also confirm that it has been the issue regularly for the last week. The main page and some of the extension and skin pages are resulting in a 504.

It is intentional to use the same description since the ShortDescription is duplicating the feature from Wikibase.