The dependency on the Elastica extension is declared in extension.json, not in composer.json. So this could still be a problem. I might add that I'm pulling in extensions via git, and then running composer install from the MediaWiki root after all extensions are installed.

But I understand what you're saying that it should be pulled in be Elastica, which is a dependency. I'll try to dig around and see better what is happening.

Elastica\Client is used in a number of places:

@Sophivorus can you please take a look at the attached patch. I believe you are the maintainer of this extension?

I have now proposed a third solution, by adding an inline parameter to both the parser extension tag and the parser function. With this patch:

• <mobileonly inline>
• <mobileonly inline=true>
• <mobileonly inline="true">
• <mobileonly inline=1>

will all output a <span class="mobileonly">, while:

• <mobileonly>
• <mobileonly inline=false>
• <mobileonly inline="false">
• <mobileonly inline=0>

will all output a <div class="mobileonly">. Same goes for the <nomobile> parser extension tag.

@Aklapper there is a difference between a wrong answer and a suggestion that needs to be proofed. Just because a machine generated suggestion isn't usable as is, doesn't mean it doesn't have any value. I'm not seeing you suggesting any "right" answers here? What do you think is "wrong" about the machine generated suggestion?

• it's suggesting the wrong hook?
• it's suggesting wrong parameters or method signatures?

I asked ChatGPT for advice on how to handle the caching issue, perhaps by using a hook other than onParserFirstCallInit. Here is what it suggests:

Checking this again I'm finding that when caching is enabled, the isMobile check will cache whichever state (mobile / nomobile) the browser was in when the page is saved. Since the page isn't reparsed again but simply the cache is being output, if I save the page on a mobile browser and then open it on a desktop, the mobile contents will continue to show on desktop. Likewise if I save the page on a desktop browser, then open it in a mobile browser, the nomobile contents will continue to show on mobile.

The solution proposed in patch https://gerrit.wikimedia.org/r/997955 will instead avoid any confusion between magic tags with similar names, by simply changing the behaviour of the current <mobileonly> and <nomobile> tags. Instead of outputting html markup with css classes, we simply output the contents as is or don't output anything, based on the isMobile() function condition.

One way to solve this, is by adding a new magic tag such as <onlymobile>, which will behave differently from <mobileonly>:

• <mobileonly> will only work inline (as per the current situation) by wrapping in a <span> element with class mobileonly targeted by a CSS rule that controls visibility
• <onlymobile> will work both for inline or block level elements, by not wrapping any extra html markup or using CSS rules to control visibility, but by simply outputting the contents or not based on whether the isMobile() function returns true or not

okay I found the SQL patch at the top of this page, I ran that against my central database and now everything is working again. I guess I'll add a comment about this on the extension discussion page...

On upgrading my MediaWiki instance to v1.39, I started getting this error when trying to login:

I was able to solve the error EntityId is not an interface, see https://www.mediawiki.org/wiki/Topic:X2qyoagj0mx24oey

ok thank you for the heads up, there was in fact a vendor folder under the WikibaseImport extension. After removing that, I no longer get the above Fatal error.

When trying to upgrade my Mediawiki instance from v1_36 to v1_38, I am getting an error from SerializableEntityId:

I am getting new errors along these lines, when trying to upgrade to Mediawiki 1.38:

@hyperreview did you try this?

For the time being, I have found that setting the web player to the Kaltura player will work in all situations:

My guess now is that TimedMediaHandler looks for a file with an article in the File namespace, but the Score extension is using a path such as

/w/images/lilypond/5/3/53m5hz6lsx5goei3o98b86w8bb3cr33/53m5hz6l.mp3

which is not in the File namespace?

I think it's more of an issue on the server side setup, not so much with InstantCommons itself. I fixed the issue in my nginx setup. But it would probably be better for all image files to have lower case extensions, for greater compatibility.

I see that the error is no longer occurring on the first page referred to in the Description (https://hu.wikipedia.org/wiki/Bevettek_husz%C3%A1rnak). How was this fixed?

I'm guessing it's a problem with the Score extension, because in the generated HTML markup, I'm seeing an anchor with File:Undefined:

I am having the same problem on a wiki that I manage. I have the TimedMediaPlayer, EmbedVideo, and Score extensions installed. When trying to play the midi file generated from a <score> tag, I start to see the loading bar at the top of the page, which then disappears and no media is played. For example with this wiki markup:

<score sound="1">\relative c'' { \time 4/4 \key c \major c4 g8 g a4 g r b^> c^> r \bar "|." } \addlyrics { Shave and a hair -- cut: two bits. }</score>

I had the same error message Error from line 35 of /var/www/mediawiki/extensions/Wikibase/lib/WikibaseLib.entitytypes.php: Class 'Wikibase\DataModel\Entity\ItemId' not found when trying to run the update.php script after an upgrade of my wiki from 1.34 to 1.35. Turns out it wasn't so much a composer problem, as it was that I simply hadn't run

git submodule update --init --recursive

in the extensions/Wikibase directory. I had git cloned Wikibase from branch REL1_35, but then you need to run git submodule update in the Wikibase extension folder and then after that run composer update --no-dev.