mysql cannot refer to the same temporary table twice in the same query apparently, which this definetly does.

I'm guessing this is because php 8.4 introduces a HTMLDocument of their own ?

Page uses https://en.wikipedia.org/wiki/Template:Infobox_official_post
This infobox uses imagecaption= for the image, flagcaption= for a flag-image and insigniacaption for an insignia-image.

This was reported on mediawiki.org support desk, when someone attempted to upgrade to 1.45. https://www.mediawiki.org/wiki/Project:Support_desk#1.45.0_update.php_can't_find_Parsoid

unblocked myself by running them in a clean docker setup... still curious what is causing this however. will investigate more tomorrow.

In T406023#11436033, @A_smart_kitten wrote:

In T406023#11417321, @TheDJ wrote:

Can a site requester take care of this one ? https://gerrit.wikimedia.org/r/1192528
I don't have the time to schedule config changes and be present during weekdays.

Sure thing :)
Just to check so that I know what to test for during the backport window (ie., what this config change shouldn't be doing), am I right in thinking that - if $wgSVGNativeRendering was set to true on Wikimedia wikis - a page like https://commons.wikimedia.org/wiki/File:Wikimedia-logo_black.svg would directly embed an SVG file from the <img> tag, rather than a .svg.png file (e.g. https://upload.wikimedia.org/wikipedia/commons/thumb/8/8b/Wikimedia-logo_black.svg/960px-Wikimedia-logo_black.svg.png)?

I would also recommend a setting to let people expire their history.

Noticed this user story on mastodon. Might wanna improve the messaging, and give people some more control.

@Nardog this is pretty disruptive as it breaks the link trail of gerrit, deploy references and release notes. It is perfectly fine for more specific or followup tasks to branch off from this task, but what you did is the opposite of that.
This could even have been done before any work was committed to the ticket but to do it afterwards is really not how we do this generally.

I did some Googling, and apparently this is still an issue.
https://support.google.com/webmasters/thread/262476869/problem-with-urls-including-commas?hl=en
https://support.google.com/webmasters/thread/229593884/comma-and-dot-in-the-url?hl=en

All WMF wikis now list a Sitemap after T400023: Deploy sitemaps API for Commons

k. so i verified that by NOT assuming that the component should always be opened on mobile, this fixes the problem, but this reintroduces the problem of inputbox opening up the window.

ah. !important bites people again:

The TypeaheadSearchWrapper of core is mounted in opened state for minerva, whereas in vector it is display:non'ed...

<templatestyles src="Mapframe/styles.css" />
<mapframe align="right" height="420" image="" latitude="-28.6221" longitude="153.0016" show="mask,around,buy,city,do,event,drink,eat,go,listing,other,see,sleep,vicinity,view,black,blue,brown,chocolate,forestgreen,gold,gray,grey,lime,magenta,maroon,mediumaquamarine,navy,red,royalblue,orange,silver,steelblue,teal,fuchsia,route1,route2,route3,route4,route5"
text="&lt;div class=&quot;magnify&quot; title=&quot;Enlarge map&quot;&gt;&lt;maplink class=&quot;no-icon&quot; image=&quot;&quot; latitude=&quot;-28.6221&quot; longitude=&quot;153.0016&quot; show=&quot;mask,around,buy,city,do,event,drink,eat,go,listing,other,see,sleep,vicinity,view,black,blue,brown,chocolate,forestgreen,gold,gray,grey,lime,magenta,maroon,mediumaquamarine,navy,red,royalblue,orange,silver,steelblue,teal,fuchsia,route1,route2,route3,route4,route5&quot; title=&quot;&quot; url=&quot;&quot; zoom=&quot;15&quot;&gt;&lt;/maplink&gt;&lt;/div&gt;Map of Kyogle"
title="" url="" width="420" zoom="14"></mapframe>[[Category:Has mapframe]]

Can a site requester take care of this one ? https://gerrit.wikimedia.org/r/1192528
I don't have the time to schedule config changes.

it's difficult to say what the exact problem is. Maybe they also encountered a cross domain login problem ? Could be anything really.

new user's are not allowed to use this functionality by decree of Commons. They have an abusefilter on it. I suspect that is what the user fell into. In that case the error handling should be improved to deal with encountering an abusefilter error.

This is because minerva assumes that the input it is finding goes with the form that it wants to infuse...

To reiterate:

Right.. this is ok, it's just doing it for BOTH searchinputs now, and one of them will always have focus of course...

In T411125#11413305, @Ladsgroup wrote:

Wouldn't browsers been able to do it on the fly? I'd be surprised if FF can't upscale a svg. I can try in beta cluster but it's down.

ehm. does this account for upsizing of vectorized images ?

As this is Commons only so far, and our infra robots.txt is shared across all, we could add it via https://commons.wikimedia.org/wiki/MediaWiki:Robots.txt

It seems worthwhile to let the test continue running for a second week

Shall we make a new subtickets for the JSON-LD part of this, so that this ticket can be closed ?

@Cparle do you know if we have access to bing webmaster tools btw ?

In T408875#11407005, @Jdlrobson-WMF wrote:

Is this the same issue (I can't reliably replicate it)?
https://en.wikivoyage.org/wiki/San_Carlos_de_Bariloche

Calling this fixed, even if it's not perfect. Good enought for now.

Created a new task for this as T411005: Show webM/Matroska comments with unknown comment keys in File page's Metadata section

To read the metadata, I was just looking at the metadata section of the file page.

Well, that has sent everyone on a wild goose chase... A good reminder to always be specific about WHAT you are doing when filling a bug report.

I'm also getting people on mediawiki.org support complaining about this btw.

has

div.ref { font-size: 90%; background-color: #f5f5f5; }

I'd suggest something like:

div.ref {
 font-size: 90%;
 background-color: var(--background-color-neutral-subtle,#f8f9fa);
 color: var(--color-emphasized,#101418);
}

Lets be honest, not happening. We have tempaccounts for a reason now.

Related: T410711

In T408592#11394649, @Jdrewniak wrote:

User interaction is essentially limited to loading and scrolling, so I don’t see any meaningful security risk stemming from the NPM dependencies, but I could be missing something. @TheDJ could you expand on the specific domain-related risks you’re concerned about?

it is mentioned right above there right ?

strange...
includes/SetupDynamicConfig.php has the following, so that means we are not hitting that code ??

It's not only a warning: thumbnails aren't stored on disk.

Who will be responsible for security review, when this is sharing important top level domains ?

I'm not entirely sure why there is no factory/hydration method for the module, and instead we are reimplementing half the property extraction logic for the app inside the skins.. this seems like a lot of code duplication. ? A common method could take a form element reference and the input element reference and determine half the properties without each skin having to figure it out on its own.

I have put in a request with our product team to see if this is something we can improve on in a future update containing all of the details you have shared.

Thank you for taking the time to suggest ways in which we can improve 1Password, please let us know if there is anything else we can help with at all.

Validated on test.wp.org
https://test.wikipedia.org/wiki/Special:MediaSearch?type=image&search=Lock+icon

In T400023#11379392, @Cparle wrote:

Will adding the the Commons sitemap to robots.txt mean that other search engines will also pick it up? duckduckgo seems not to have many File pages indexed, for example - commons site image search for "dog" on duckduckgo compared to google

In T408715#11332556, @AntiCompositeNumber wrote:

It's historically been easy for applications to generate their own thumb URLs, and fairly common given how slow the imageinfo API can be.

autofocusInput on mount.. but the reason for mounting the app is not necessarily correlated with providing focus to the element on which it mounts... So this autofocusInput logic should be fixed...

That's not a full url. The full url is https://upload.wikimedia.org/wikipedia/commons/thumb/f/f3/Morena_leopardo_%28Gymnothorax_favagineus%29%2C_islas_Ad_Dimaniyat%2C_Omán%2C_2024-08-13%2C_DD_84.jpg/4890px-Morena_leopardo_%28Gymnothorax_favagineus%29%2C_islas_Ad_Dimaniyat%2C_Omán%2C_2024-08-13%2C_DD_84.jpg

The choice of Sorting order should be remembered and offered as the default on subsequent visits.

@Jdlrobson-WMF not sure if this is the best approach, but it's bed time now :)

This is mostly because urlgenerator module is not intialized with the SearchPageTitle, unlike the App itself. This will have to be made possible and then fixed in all callers of of these components (Minerva and Vector ?)

I've just tested this, and 1password still happily offers to create and save a new webauthn key even though the public-credential hint is set..
So we should probably file a bug for that ?

Why are we giving endusers a non-alt code in that case? This shouldn’t be up to a user to have to figure out. User press button, user get link, link always work, is the only valid path here I think…

If this worked in the past, then it not working any longer is a NEW problem and thus needs a new ticket, which i have now created.

Line height normal is typically a browser default of 1.2 but can vary based on the font family.

This zoom level is simply very busy with streets for a city of this density, so it has to drop a LOT of names, even though all streets at this level are likely eligible to show a name at this zoomlevel (and possibly will show for much less dense areas).

There's quite some trickery going on here with overriding sizing for minerva, to make the dimensions of the images limited by max-width of the parent viewport. However in this solution, we mainly want to be height limited, which flips those assumptions around.. As the previous developer leaving their comments in the code, I'm not entirely happy with the solution... but there are many different factors at play and this seems the safest solution for now.

It would be good to know if this is recent or not. Having confirmation about that could say a lot about where to start looking for the cause of this problem.

In T408884#11333833, @Pppery wrote:

Kartographer and SVG thumbnails are handled by two completely different software stacks.

Not sure if this font issue T408884 is related, but it was reported around the switch to the new services, so might be worth double checking if the k8s images have the full font stack that we usually use on media servers.

hmm. this doesn't seem fixed yet...

Apparently LastPass has something called Never URLs to disable itself on certain pages. If this thing really gets in your way, you may be able to use that to disable it specifically in certain locations as a temporary workaround.

Yeah i think we can close this.

Do we want to make the ticket public now, considering the change did ride the train in public ?