I understand this code better now (didn't notice there are 2 ways of generating the PNG: default using ploticus only, and "svg2png").

Rather than reading the entire PNG to get its dimensions, maybe we could store them in a sidecar file? (something like {$pathPrefix}.dimensions)

After numerous tries, it was a permission issue indeed.
Uploaded to a separate changeset, so you can at least see my patch: 690771.

Using the Gerrit Patch Uploader, even after proper rebasing of my patch, I'm encountering this error:

Rather than the getimagesize( $url ) in above patch, a better code could be:

• Without anchor, location.hash is an empty string; with "#" anchor, location.hash is still an empty string; then with "#x" anchor, location.hash becomes #x. Therefore, location.hash is never #.
• jQuery constructor can work without argument, or null, undefined, empty string, empty array… all these return an empty collection. (reference)

So, with https://gerrit.wikimedia.org/r/664228 the simple EventSingletonManager utility gets a dependency on the heavy and unrelated OOUI…

Agree with Krinkle.

No problem at all!
And the fix seems to be significantly more complex than I thought, so thank you for your work on it!

Firefox shows this warning:

Thanks, though I think it's still a bit too emphasized. How about the Base50 #a2a9b1, or at very least Base40 #8a9097?

Useful addition, though, may I suggest making these numbers lighter? They add a lot of visual distraction, yet they are needed only in a few situations.

Despite the above patch, the problem is still present on frwiki…

Refs discussion on French Wikipedia

Hi, using the "Download as PDF" feature on French Wikipedia, I noticed that the sidebar is included in the generated PDF, contrarily to a PDF generated on e.g. English Wikipedia.

Following up to my above comment, there is no longer a linebreak between the "From date" and "To date" inputs since the form has been converted to OOUI, refs T117736 :)

Though personally I don't understand the need for this feature, it seems a lot of users requested it and find it useful. So that's fine :)

Could you please provide a user setting for disabling this feature?

For your information, here is a script of mine, that I had developed to give full horizontal space to the content:

I would like to clarify, are you (the devs) going to keep or revert the switch to monospace?

Look just above, the font <del>has been</del> <ins>is going to be</ins> restored to sans-serif.

Just as a reminder, the changeset has been reverted

Personally, after some initial reluctance, I tend to prefer the monospace, but I had to tweak the font in my user CSS.
The font really has to be fine-tuned, and it certainly varies a lot depending on the OS/browser/etc.

Just found T176636 already.

Some "Git blame" led me here ;)

Closing, as it was a mistake on the wiki actually. Refs the discussion, and the fix I have applied (removal of the inappropriately used mw-editsection class).

Could anyone think of any issues, to have categories but without their code in the final wikitext?

I have added a code comment on the Gerrit patch.

T155347 is ready and awaiting for more than two years 😭

Following-up to this commit,

We had a related issue on frwiki (see talk, involving template Liste éléments):

@thiemowmde Your benchmarks are above :)

1. Volunteer developer at frwiki.
2. For me the main issue is that some scripts are just maintenance nightmares.
   • Examples:
     • In Lua: Module:Wikidata
     • For perspective, scripts that are smaller but are already hard to maintain: Module:Date, Module:Unité
     • In JavaScript: LiveRC.js
   • The issues are, more precisely:
     • Very few people are able to work on these codes (or are willing to spend dozens of hours to understand the whole script and to investigate the interactions with the other scripts).
     • We are close to a bus factor 1. When the creator of a script leaves the project, there's no one else crazy enough to carry on such script.
     • It's nearly impossible to make any change without breaking something (in the script, or in interacting scripts), also without making the code even more complicated. Making a "clean" change requires a lot of skills and time.
   • Thoughts about improving this:
     • Anything that would improve modularity and decoupling would be good to take. Slicing these monolithic monstruosities into smaller codes that could be worked on separately, sanely.
     • Same with things like unit testing, automated reports, and such. Anything that would help spotting any regressions immediately, or at least before they become difficult to fix.

$text = str_repeat( 'lorem ipsum dolor sit amet', 1000 );
$space = '&#160;';

@cscott I see you have improved it even further :)

The code could be optimized as so:

frwiki has been updated:

• MediaWiki:Gadget-CommonEdit.js (+ MediaWiki:Gadgets-definition)
• MediaWiki:Gadget-ExternalSearch.js
• Also Utilisateur:Gratus/superVis.js (see talk)

Ok, I got the point of, basically, not duplicating the API documentation into the page ResourceLoader/Core modules, and just making the latter link to the former. Entirely agree with this.

@Krinkle:

• If I documented something private/internal that should be by mistake, as it's something I would like to avoid too. Maybe you found an example of this?
• Indeed I have noticed your maintenance work on this page (amongst all the rest of course). That's very appreciated.

Great explanation by Krinkle above, in particular the following:

Just to mention the "de facto" documentation hadn't been updated.

Just as a kind reminder, ResourceLoader/Core modules documentation would need updating.

For the record, on frwiki I have changed the classname back to the regular name (refs Cite references link one, Cite references link many), as I think it's the only proper way to handle this. The classname just shouldn't had been allowed to be renamed in the first place. Triggered by the custom name, these subsequent JavaScript workarounds were in turn causing some bug in gadget ReferenceTooltips...

For the record, on frwiki I have changed the classname back to the regular name (refs Cite references link one, Cite references link many), as I think it's the only proper way to handle this. The classname just shouldn't had been allowed to be renamed in the first place. Triggered by the custom name, these subsequent JavaScript workarounds were in turn causing some bug in gadget ReferenceTooltips...

For the record, on frwiki I have changed the classname back to the regular name (refs Cite references link one, Cite references link many), as I think it's the only proper way to handle this. The classname just shouldn't had been allowed to be renamed in the first place. Triggered by the custom name, these subsequent JavaScript workarounds were in turn causing some bug in gadget ReferenceTooltips...

In T228604#5352013, @Iniquity wrote:

Do not forget that to use TemplateStyles in Editnotices (messages that display while editing) you need to add <div class="mw-parser-output"> wrapper :)

Note that previously the preferences had been fixed, by using in the message a nbsp character (instead of a html entity), and it was working fine.

On the other hand, there is for sure a bug in the parser...
So even if this one resulting issue may be ignored, we have here an open gate for other issues.

Same for docblock of [[ https://github.com/wikimedia/oojs-ui/blob/master/src/Window.js | Window::open ]], which should be updated according to [[ https://github.com/wikimedia/oojs-ui/blob/master/src/WindowManager.js | WindowManager::openWindow ]].

Return value in docblock of [[ https://github.com/wikimedia/oojs-ui/blob/master/src/Window.js | Window::close ]] should be updated accordingly, copying the return value from docblock of [[ https://github.com/wikimedia/oojs-ui/blob/master/src/WindowManager.js | WindowManager::closeWindow ]].

How about using a bot to move {{Infobox/Titre en italique}} bricks into the infoboxes, i.e. above the closing brick {{Modèle:Infobox/Fin}}? Then documenting this so that editors don't reintroduce back the issue.

Closing, per the explanation above :)

For the deduplicated styles, do we really need the <link> tags? Couldn't we completely remove the tag?

Just to clarify, I was precisely concerned about TemplateStyles in small templates invoked many times. More precisely:

• Server-side: all processing time for parsing, deduplicating, etc. (CPU/RAM usage)
• Client-side (which I'm more worried about): cost of markup bloat with the numerous added <link> tags (page size, also CPU/RAM usage)

This makes sense. I am just uncomfortable with removing the "nowiki" from the sub (and main) template {{Titre en italique}}. That one "nowiki" fixes many cases of empty <p>.

The output HTML are two properly distinct elements, a div followed by a p, and the p is clearly outside of the template transclusion. Thus I maintain the issue is at the visual editor level.

Though it's quite clear these <nowiki /> are tricky, I'd say the issue discussed here is rather in the visual editor, which should properly handle the case.

Wow, that's quite an impressive reply! Thank you. Pinned.

I'll just also mention toolbar customization, which has been modified several times, and has become a real pain for users.

Not strictly deprecation/removal, but off the very top of my head:

I just found it was cumbersome to manage different versions of scripts, depending on MediaWiki version, swimming on short intervals like 6 months.
Moving to forward-compatbility implying to break backward-compatibility even for recent and supported MediaWiki versions.

I think the legacy "mediawiki.api.*" modules should be removed later than in MediaWiki 1.33.

So, there is still Modern to fix.

Looks like it's solved, the patch having been merged.

Indeed, duplicate.
Apparently the whole thing was just broken, and the fix is to be deployed soon.