In case you're noticing now, @Paladox/@Redmin/@MacFan4000: UO did upgrade ACP after all, two weeks ago. About time this finally got bumped up on Miraheze--and if it doesn't quite work yet, then I'll remind you or be otherwise informed. Take care--and happy Thanksgiving week!

Perhaps you could look into Moderation and see if that has any effect? If it works for the AVID Logos team, anything might...

Same thing happened more than half an hour ago when I was trying to save a slight update to the Adanson Jukebox track listing for Seal's 1991 hit "Crazy" through Page Forms. (Maybe still just about the right word at the right time.) Same message above editbox; nothing has been deleted; accessing the page itself currently results in a blank slate with "Error" as its title and the no-text message below. (Although the two edits are recorded in RecentChanges--but the history tab shows just one.)

To give @Redmin a heads-up: As I found out yesterday afternoon, removing ACP's {{#createpageifnotex}} tag from the affected template--or better off, hiding them via HTML commenting--actually does a favour to the pages using it (along with their semantic data and WhatLinksHere lists). This is ultimately an issue on the part of ACP which has still lingered on since MW 1.39, not Page Forms.

If you're still keeping track, Platel, Miraheze already has SimpleChanges in Special:ManageWiki/extensions, which you may want to try out/experiment with.

In T11098#227029, @Redmin wrote:

@Paladox/@Routhwick, did the update fix this?

At this writing, though, typing in betaheze.org leads to a blank-slate homepage parker courtesy of IONOS; that much I noted at the Community noticeboard last month (along with the current status of @MirahezeStatus on X/Twitter). Did the departed volunteers abandon it back in June as well, or did someone forget to pay the bills?

...Pssst, @Paladox: You might as well look into bumping up PF at this moment (the sooner the better), because the default values can't return soon enough. Please remind me if/when you've gotten to it. (GitHub memo for convenience's sake.)

In T11250#226099, @NotHansCYDIa wrote:

How many days does an SRE respond?

And this morning, I've discovered that this ailment affects another namespace: Any new Track listings created with the accompanying Page Form (at this writing) won't be listed in other pages' WhatLinksHere, nor display semantic info, nor list templates and other tags transcluded within their code when editing traditionally. Example provided for the listing for "Forever Sky", an open-source instrumental by Australian composer Scott Buckley. Funnily enough, a barebones, off-Form comeback demo (no pun intended) for The Psalters' "Magnificat" (2011) ended up working properly. (And just as I was starting to get the Adanson Jukebox up and running again; the Jukebox is a music-based adjunct to the development of my forthcoming Unspooled books.)

Wikipedia--and many Wikimedia sites--have a feature called HotCat that you can install through the Gadgets extension (if you already have the latter tool enabled on your site). I'll leave it up to the MH team to suggest a more superior alternative.

Seconded; my Tovasala/RFM conlang project might be likely to benefit from it. (Brings me back to a few years ago when I tried out TTS [text-to-speech] samples of my work on third-party sites...)

Now I know what happened all along in this case (as I just related in my latest FTA). Semantic support for Maps is already disabled on Miraheze per this GitHub snippet:

To save space on their servers, Miraheze switched over to $wgCompressRevisions = true + MassEditRegex early this year. Details at T10185, T10227, and T10240.

Can confirm the same thing's happening on my wiki. To give an example: Save a page with free text via form, and the free text just up-and-disappears. For the time being, any existing pages may have to be edited the traditional editbox way.

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

SMW? Sure thing.

Developer Skizzerz, who only pops by at MW.org/Wikimedia once every few months these days, 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.)