Feedback from Skizzerz (now that I've got his last letter right this time), just this moment (bolded emphasis mine):

SMW? Sure thing.

Developer Skizzers, who's seldom on MW.org or Wikimedia anymore, has nonetheless been informed by me just this moment. If possible, I'll try to bring word of the security concerns to WM Phab the sooner I join their equivalent hub. I'll keep you posted.

<sigh/> I know... T8866, right?

In T10860#219112, @Ruchirshah wrote:

Can a system admin help with this?

A similar error has recently befallen this recent AVID logo upload re: the distribution branch of Australia's Greater Union chain, one of whose last releases was 1992's live/animated Blinky Bill movie; filing on that community's behalf in this timesaver of a thread. Error trace straight from source:

Filed on GitHub just minutes ago. As soon as I get feedback (which could take several days'/weeks' wait), I'll report back.

Tested just seconds ago; bug remains unsolved.

In T10583#214955, @Bukkit wrote:

Discus was removed because of some CSP violations iirc, so really only the custom footer will work as @OrangeStar said.

To make the pages appear on the "What links here" page (as this feature is known in English), select "Edit[ar]" and then type in "Dummy refresh" (or its Spanish equivalent) in the summary bar without typing anything above. (That's exactly what I did two or so minutes before this writing.)

In T10611#213593, @Ugochimobi wrote:

Have you tried enabling Maps from ManageWiki?

If you meant "QuickInstantCommons", then that feature's already enabled across Miraheze (in place of the original "InstantCommons").

Thanks to this WP relic from the mid-2000s I came across minutes ago (via WP:Historical archive), I've just come to realise that MW 1.39 may have hit an unintentional "stop word" in the process. Further investigation needed, upstream or otherwise.

OnlineWebFonts (already on the CSP whitelist) has you covered.

Maybe not directly on wiki pages--and sorry I skimmed past the task description in the first place--but this example CSS snippet from the related Wikipedia article might give you a pointer or two:

Maybe $wgAllowExternalImages might suit your needs more?

Not to mention it's marked as "experimental", which Miraheze understandably has jitters about.

...How was this a double post? (I only pressed "Submit" just once...)

Bit of a long story, but here goes...

Reopening thanks to feedback from earlier this week by Jeroen De Dauw (re: SRF; via Y! Mail):

• SimpleTooltip
  • All tooltips appear to work aside from Inline-Image, multiple attempts at alternate syntax were unsuccessful. (root cause was undocumented expectation of full URL path)

As I reported earlier this week at T9977#202083 (part of my own filing), R9:a07ba8ce70e1 locks away access to namespace settings, meaning you can't change or view them. (Stemming from an unsuccessful attempt to introduce Form-namespace support in ManageWiki; waiting on a revert from @TechnoMage or similar.)

Another unintended catch: R9:a07ba8ce70e1 locks away access to namespace settings, meaning you can't change or view them. Example in action after selecting the Help NS (suitably enough) minutes before press time:

Was about to finally have a go at it minutes ago, but despite R9:a07ba8ce70e1, "Form" is still not listed. Maybe we might give Mr. Koren a reminder upstream?

For a list of affected wikis (1400+ in total), see P473.

Scribunto is already globally installed on Miraheze, therefore you won't find it in Special:ManageWiki/extensions. As for the Lua issue (T9964), I'm assuming some elements missing from an apparent Wikipedia import are to blame, right? Otherwise, waiting on the staff to find out what went wrong.

• AutoCreatePage - doesn't seem to work/unmaintained since 2017

Marked as "stable" at press time, although I'm not sure whether MW 1.38.4 (the current version) can handle it with that in mind. For more information, cf. T8323.

You're not alone here. My site went through similar ordeals two months and change ago at T9699.

For more information, please see T9759. (TL/DR: Security lapse, upstream fix pending.)

To @Universal_Omega: After nearly a month's delay, I have brought the SRF issue here to the SMW team's attention at GitHub. Sitting back and waiting on further developments.

In T9753#197282, @Universal_Omega wrote:

[W]e may be able to reconsider later once I look into maybe adjusting our setup to support these type of extensions, but for now I must decline it.

In T9748#197187, @Universal_Omega wrote:

Does {{PAGESINCATEGORY:categoryname}} not work for your needs in this instance?

As for Semantic Result Formats, customising it for Miraheze seems like the only viable alternative left, I assume.

In T9287#197042, @Universal_Omega wrote:

• Semantic Result Formats does not work: Fatal error: Cannot redeclare smwfContLang() (previously declared in /srv/mediawiki/w/extensions/SemanticResultFormats/extensions/SemanticMediaWiki/includes/GlobalFunctions.php:28) in /srv/mediawiki/w/extensions/SemanticMediaWiki/includes/GlobalFunctions.php on line 27

I believe this is caused by an incompatibility with how composer is needed to be installed for the extension, which is incompatible with our setup of submodules.

A similar run-in was reported by this contributor early last month at T9515.

Do what I did last summer, and turn off $wgCapitalLinks at Special:ManageWiki/settings#mw-section-links. (To turn capitalised titles back on in a namespace, use $wgCapitalLinkOverrides at Special:ManageWiki/namespaces/#; replace # with the NS code.)

Unless they're duplicates and/or low-resolution--and I'm saying this as an actual CLG lurker from the Wikifoundry days--I think a good deal of the logo screenshots may be salvaged for the benefit of their description pages. Any word on a review or reconsideration?

Already filed as part of my maiden voyage on GitHub! (But apart from the DPL bug reports, don't expect me to show up there much in any capacity.)

In T9655#194984, @williamsp wrote:

Let me know if you guys have other alternatives for PDF printing and page analytics.

A-OK!

When sandboxed at ExpandTemplates with {{#dpl:imagecontainer=From the Author:2022/Anniversary ashcan|openreferences=true}} (itself containing several CC0 images from the Commons):

Practically ran into the same "openreferences" error while setting up the home page for my "FTA" (From the Author) feature earlier this overnight. (Even the example at Follow the Score's manual [source code provided here] throws up an error.) To UO: Once/if looked into, can you provide an ETA for an upstream fix?

Sadly, the more I think deeply about it, the more I'm realising mPDF is more or less exactly the same as the native "Printable version" feature. Either we'll deal with test-running it soon, or I'm better off withdrawing this request and trading it in for DocBookExport (which Referata once experimented with, and furthermore boasts multi-page support unlike mPDF).

Perhaps related, but the semantic "upgrade key" error suddenly came back after 10:30 tonight for whatever reason. (On my wiki, and the handful of others with SMW installed.)

Noticed that Athenaeum Spaces is also affected (h/t "Capybread" at the Community noticeboard).