In T9438#191146, @MikeV wrote:

In T9438#191100, @Universal_Omega wrote:

Core removed all functionality providing numbered headings functionality. The extension documentation on MediaWiki.org is now marked as incompatible. I just did that now.

I noticed that. Thanks. And you also indicated that it is not actively maintained. Does that mean the authors and maintainers are definitely out? It would be good to know the likelyhood of a fix (if anyone knows) before planning work-arounds.

I have manually created the directories. They should have been created automatically when you enabled the extension, but for some reason this didn't happen.

somehow the file directories for SocialProfile didn't exist

In T9438#191100, @Universal_Omega wrote:

Solution: remove Timeless from the Skip Skins ($wgSkipSkins) list

In T9436#191116, @Universal_Omega wrote:

I'm guessing the overall cause is wgSkipSkins being set, but that is intended to support most skins being set there, so not sure why it would happen.

In T9436#191114, @Soukupmi wrote:

it was (that was my original idea as well btw.)
now as it said "Timeless" I thought - this would do.
changed it to "Vector-2022" now, same error
Cosmos (just now added with the manage-wiki) also throws that error

fixed it - we had "Timeless" on our skip list
and there was apparently no way to get the page to accept a different skin than that.

it was (that was my original idea as well btw.)
now as it said "Timeless" I thought - this would do.
changed it to "Vector-2022" now, same error
Cosmos (just now added with the manage-wiki) also throws that error

I think I have an idea on issue. Please try changing the default skin in ManageWiki, then back again to reset skin, since I'm assuming the default skin before was Pivot? If so then three isn't a skin preference anymore, which from what I can see from core now makes skin not appear at all, and with 1.38 that seems to fatal.

I (or one of you) can disable all the extensions at will - the site is private anyway and with the removed Pivot skin needs a major revamp.

Ok. Well thank you for your time

In T9438#191086, @MikeV wrote:

There must be more guidance than what is on the Extension pages. The NumberedHeadings page has the 1.38 incompatibility notice, but the MagicNumberedHeadings page does not. Moving the task to Short Term sounds like expediting it. Thanks. I'll follow it, but right now I don't see it there.

Is the only thing that might work in this case. But there are a couple issues with this.

There must be more guidance than what is on the Extension pages. The NumberedHeadings page has the 1.38 incompatibility notice, but the MagicNumberedHeadings page does not. Moving the task to Short Term sounds like expediting it. Thanks. I'll follow it, but right now I don't see it there.

In T9422#191065, @SolidBlock wrote:

However, this page claims that the replacement table is generated for that. It is weird.

MagicNumberedHeadings was actually the extension removed with 1.38, as it is also incompatible.

HTMLForm::getField: no field named skin
from /srv/mediawiki/w/includes/htmlform/HTMLForm.php(441)
#0 /srv/mediawiki/w/includes/htmlform/HTMLFormField.php(145): HTMLForm->getField(string)
#1 /srv/mediawiki/w/includes/htmlform/HTMLFormField.php(160): HTMLFormField->getNearestField(string, boolean)
#2 /srv/mediawiki/w/includes/htmlform/HTMLFormField.php(277): HTMLFormField->getNearestFieldValue(array, string, boolean, boolean)
#3 /srv/mediawiki/w/includes/htmlform/HTMLFormField.php(347): HTMLFormField->checkStateRecurse(array, array)
#4 /srv/mediawiki/w/includes/htmlform/HTMLFormField.php(362): HTMLFormField->isHidden(array)
#5 /srv/mediawiki/w/includes/htmlform/HTMLForm.php(2033): HTMLFormField->isDisabled(array)
#6 /srv/mediawiki/w/includes/htmlform/HTMLForm.php(578): HTMLForm->loadData()
#7 /srv/mediawiki/w/includes/htmlform/HTMLForm.php(630): HTMLForm->prepareForm()
#8 /srv/mediawiki/w/includes/specials/SpecialPreferences.php(122): HTMLForm->show()
#9 /srv/mediawiki/w/includes/specialpage/SpecialPage.php(671): SpecialPreferences->execute(NULL)
#10 /srv/mediawiki/w/includes/specialpage/SpecialPageFactory.php(1378): SpecialPage->run(NULL)
#11 /srv/mediawiki/w/includes/MediaWiki.php(315): MediaWiki\SpecialPage\SpecialPageFactory->executePath(string, RequestContext)
#12 /srv/mediawiki/w/includes/MediaWiki.php(910): MediaWiki->performRequest()
#13 /srv/mediawiki/w/includes/MediaWiki.php(564): MediaWiki->main()
#14 /srv/mediawiki/w/index.php(53): MediaWiki->run()
#15 /srv/mediawiki/w/index.php(46): wfIndexMain()
#16 {main}

However, this page claims that the replacement table is generated for that. It is weird.

Still occurring.

In T9437#191062, @Max20091 wrote:

Are there anyway to handle that automatically with mediawiki?
The wikitext I used was

[[File:Who killed Cock Robin? 5 Stars.png|200px]]

Are there anyway to handle that automatically with mediawiki?
The wikitext I used was

[[File:Who killed Cock Robin? 5 Stars.png|200px]]

You have to use the URL https://houkai2nd.miraheze.org/w/thumb_handler.php/1/12/Who_killed_Cock_Robin%3F_5_Stars.png/200px-Who_killed_Cock_Robin%3F_5_Stars.png, encoding the question mark with %3F, which it is done in second instance, but not first here.

In T9419#191050, @Max20091 wrote:

I checked around and noticed that pages that never got edited after imported (or after updated MW) seems to have this kind of issue.

I checked around and noticed that pages that never got edited after imported (or after updated MW) seems to have this kind of issue.
Edit: Alright, I can fix the issue myself since there are very few pages needs to be fixed.

This is UnusedFiles, not WantedFiles.
The file https://houkai2nd.miraheze.org/wiki/File:Infinite_ammo_during_combat.png is used in https://houkai2nd.miraheze.org/wiki/Category:Infinite_ammo but was listed as unused which is kind of weird.

In T9419#191035, @Max20091 wrote:

Definitely not infobox bug, checked another file that got the same issue
https://houkai2nd.miraheze.org/wiki/File:Infinite_ammo_during_combat.png
https://houkai2nd.miraheze.org/wiki/Category:Infinite_ammo

Definitely not infobox bug, checked another file that got the same issue
https://houkai2nd.miraheze.org/wiki/File:Infinite_ammo_during_combat.png
https://houkai2nd.miraheze.org/wiki/Category:Infinite_ammo

I modified the XML file directly, hopefully made it compatible with recent MediaWiki, but some things with it will be messed up, a ton of special characters for example likely won't be decoded from HTML entities properly. If it works at all, that's the best we'll be able to do. Apologies for the inconvenience. I opened https://meta.miraheze.org/wiki/Special:RequestImportDumpQueue/3 for this task, using our new system for this. So because of that I'm going to close this task as invalid since no action taken on this task itself any longer. Thank you! Hopefully we can get this done for you.

Does this still happen?

It does looks like the Tweeki skin works now, or at least using it doesn't break the wiki. There still seem to be display issues, like the fixed footer not being fixed anymore and CSS styles not working the way they did before the update. I guess my wiki will just stick to the Chameleon skin, though it's good to know if something else happens with that skin then we'll have a backup skin.

Well if that's the case, I wish they would have made it optional for audio files to either open in a new window as before or play inline, because now the only way to make the player fit in my sortable tables is to gut the controls and put it in a div with overlap hidden.

Great!

Both are fixed since the MediaWiki 1.38 update!

I see. So, it means that there's nothing to do from Miraheze side, right? For the feedback so we can force a certain image to be selected, maybe I should post it on Wikimedia Phabricator instead. What do you think?

Thank you for providing the links for converting from HTML, I don't have any expertise in doing this or working with scripts. Would it be possible to have someone help me convert this?

As stated before, all namespaces MW and SMW ship with, plus (for now) the custom "Entry", "Morpheme", and "Character". (Phasing in another five in the coming weeks.)

Closing this task as resolved, since it is only dependent on upstream now, no further action for us to take until upstream merges that in. Once it is I will update the extension. Thank you for the report!

I have tested the patch, and it works, so this should be fixed once upstream merges that in. Just waiting on that now.

Closing since no response to @dross above. It can be re-opened if it is still occurring.

https://tile.openstreetmap.org/img/.,13,55.751938888889,37.609719444444,310x180.png?lang=en&domain=gratisdata.miraheze.org&title=Special%3ABlankPage&groups=_c3c2129a6b07252bd5bd2048e13c51105f7f7abf returning 404 is an issue with OpenStreetMap or the way you are using it, not anything to do with Miraheze, so due to that I am going to go ahead and close this as invalid, since no action taken by us.

https://github.com/miraheze/puppet/pull/2681

This is caused by CollapsibleVector extension, which has broken with 1.38. I plan to at least attempt a patch to fix it at some point.

This is caused by the Display Title extension I think.

Closing as resolved, Tweeki should now work on your wiki again, so long as you don't set $wgTweekiSkinUseIconWatch in ManageWiki again. I am still waiting on my upstream patch to be merged to fix that config.

What value would you like $smwgNamespacesWithSemanticLinks set to? It looks like we will have to do it directly from our config.

I am not sure I understand the issue. The change was made upstream, likely intentionally, to make audio files play inline, and it still works for video files to play in the popup dialog. I do not believe there is anything we can do about this.

The issue is because there is in fact no replacement table existing at all. The same issue would occur at https://rs.miraheze.org/wiki/Special:CargoTables/LevelData?_replacement for example, and any other cargo table using ?_replacement if no replacement table actually exists.