A draft/first implementation attempt of Parsoid support in PortableInfobox has been started and mostly working in this PR. It's not perfect and still needs some refining, but it mostly works at present. I'm not entirely sure if its the recommended way to do it (with most of the processing being in the wtPostProcess function, however this appears to be the earliest that we can access the parameters passed to the template - I did try to do most of the processing initially in the sourceToDom function, however it does not appear that Parsoid allows us to access the parameters passed to the template until that function has returned, so I relied on grabbing them from the data-mw attribute.

Nevermind; looks like we're running a behind version and the field actually does provide a default value!

In T371156#10080814, @abi_ wrote:

@OriginalAuthority: Please provide access to https://gitlab.com/translatewiki for the repo so that the bot can push changes to it.

Ah, that worked!

In T364261#9778148, @Catrope wrote:

In T364261#9776355, @OriginalAuthority wrote:

The error seems to be the missing codex.js file, Cannot require undefined file codex.js is printed to the console. Is it required to also load Codex in a skin as well as the extension? The documentation say nothing about that.

In T364261#9777709, @AnneT wrote:

Hey @OriginalAuthority, how are you including the styles for your module on the page?

After a little bit of digging, it seems that this is not isolated using CSS only versions. Loading the Codex example extension works perfectly on Vector-2022, but when using Vector, it doesn't load, instead falling back to regular html buttons.

Aside from the fact that some people just generally don't like it, Miraheze is at the point where Special:CentralAuth is taking a considerably long time to load due to the number of attached accounts. For some users, even if they haven't edited that wiki.

Can confirm the above also happens using 8.1, when also using the same extension.

Looks like shutting down the server and booting it back up again fixed the issue. But yes, it probably is the issue above, taavi.

In T339880#8947712, @Reedy wrote:

It's helpful if you post the actual error.

To debug this, I've composer depends php | grep 8.1 and it yields, phpspec/prophecy v1.17.0 requires php (^7.2 || 8.0.* || 8.1.* || 8.2.*), which seems to be the package causing the issue—I think. I can't figure out how to remove this and require a version of this dependency that works with 7.4.

^7.2 would include 7.4, upto anything less than 8.0. So I imagine that what you actually thing is the error, probably isn't the error.

See https://getcomposer.org/doc/articles/versions.md#caret-version-range-

Is composer actually running on PHP 7.4?

And do you actually need phpspec/prophecy? It's a dev dependancy...

In T338559#8918955, @Tgr wrote:

Can you verify that your vendor/leage/oauth2-server directory has some files? Does vendor/league/oauth2-server/src/Exception/OAuthServerException.php exist? What's the version of the library you are using (you can check in composer.lock)?

In T338559#8917725, @Tgr wrote:

In the first approximation, this sounds like a bug in the REST API error logging code. A HTTP 500 should always be logged.

In T337886#8893551, @gerritbot wrote:

Change 925006 had a related patch set uploaded (by Umherirrender; author: Umherirrender):

[mediawiki/extensions/CentralAuth@master] Fix hook runner for CentralAuthSilentLoginRedirect

https://gerrit.wikimedia.org/r/925006

Is there any update on when this is going to be fixed? Not having this documentation severly hinders extension development for those not familiar with OOUI and the documentation on mw.org isn't really exhaustive.

Swinging back around to this; I brought it up on the mailing list but didn't recieve any feedback.

@Aklapper Thanks, I've "brought it up" on the mailing list.

In T318196#8458150, @Aklapper wrote:

@OriginalAuthority: Could you please answer the last comment? Thanks in advance!

In T325830#8488479, @ashley wrote:

You should be able to find the git hashes for things downloaded using git on Special:Version, and of course you can always run git log in the appropriate directory to see that (and a lot of other info).

Interestingly, I just downloaded that version of the extension that you linked above and I get the same error.

In T325443#8476067, @Legoktm wrote:

Do you have $wgAllowSiteCSSOnRestrictedPages enabled? That allows Common.css to get through safemode.

In T325443#8475892, @Umherirrender wrote:

In T325443#8475879, @OriginalAuthority wrote:

In T325443#8475862, @Umherirrender wrote:

Docs says:

- safemode: Only register modules that have ORIGIN_CORE as their origin.
  This disables ORIGIN_USER modules and mw.loader.store. (T185303, T145498)
  See also: OutputPage::disallowUserJs()

It does not disable all JS and CSS, it disables all user provided JS and CSS (for example scripts from user pages 'User:<User>/common.js', but also from mediawiki namespace like 'MediaWiki:Common.js' or Gadgets)
Scripts provide by mediawiki itself are still working.

It doesn't work, though, from what you're saying, Common.css should also not be loaded, correct? If correct, then my original comment is correct because Common.css is still loaded.

Yes, it includes Common.css.
Works for me with the current master and the latest REL1_39 from git

Steps to reproduce:

• Login as interface admin
• Go to MediaWiki:Common.css and include the content: #firstHeading { background-color: orange; }
• Go to Main Page and the heading should be orange
• Load the Main Page with safemode=1 and the heading is no longer orange

In T325443#8475862, @Umherirrender wrote:

Docs says:

- safemode: Only register modules that have ORIGIN_CORE as their origin.
  This disables ORIGIN_USER modules and mw.loader.store. (T185303, T145498)
  See also: OutputPage::disallowUserJs()

It does not disable all JS and CSS, it disables all user provided JS and CSS (for example scripts from user pages 'User:<User>/common.js', but also from mediawiki namespace like 'MediaWiki:Common.js' or Gadgets)
Scripts provide by mediawiki itself are still working.

Ah, perfect! I figured as much. Looks like I had some errors with Resources.php, all fixed now. Thank you!

I don't see why all of the icons are different sizes? And why is there such a big gap between the alerts and notices icon?