Thanks to your comments regarding which extensions & skins that are installed on the wiki(s).

In T389464#10833511, @A_smart_kitten wrote:

@S0ring, to confirm if I'm understanding you correctly, is the issue here that — there's a template with the following contents:

<div>
{| class="cmbox"  style="border: 2px; border-style: solid; border-color: #8E2043; width: 100%; vertical-align: middle;"
|-
| class="cmbox-image" style="vertical-align: middle; width: 70px"|[[Datei:mb-achtung.png|none|link=]]
| class="cmbox-text"|{{{1}}}
|}
</div>

On MediaWiki 1.39, that template displays the image (mb-achtung.png). However, after upgrading to MediaWiki 1.43, the image is no longer displayed.
Is that correct, or am I misunderstanding something? (/genuine question)

@Aklapper: I just wanted to get your attention to this issue which it blocks our migration on 3 wikis. But meanwhile the priority has been changed from High to Needs Triage.

The images are missing in all templates upgrade to 1.43, not only on Special:UncategorizedTemplates. We have 3 wiki's where this issue occured.

I've downloaded the version for 1.43 using the ExtensionDistributor [1] and thus I got PageForms v.5.8.1.

Purposed solution: replace the line 64 of PageForms/includes/PF_ValuesUtils.php

		$db = wfGetDB( DB_REPLICA );

with

		$loadBalancer = MediaWikiServices::getInstance()->getDBLoadBalancer();
		$db = $loadBalancer->getConnection( DB_REPLICA );

The warning has disappeared in the newer master version MsCalendar 3.1
https://github.com/wikimedia/mediawiki-extensions-MsCalendar

This is about PHP 8.1.32 (MW 1.39 and MW 1.43)

Sharing the 'actor' table only was sufficient to fix the error, thank you!

It is not clear how this duplicate entry during time occured, please explain what you meant by "some bad data stayed longer".
pl_from_namespace was not always a primary key on table pagelinks, could be this the case here?
By adding a clean up step, do you mean the update.php can for example starting automatically the rebuildall.php maintenance script instead of failing?

Due to this error, the update.php script was interrupted, the database was corrupted and the upgrade was compromised. We had to downgrade back to MW 1.39 and restore the backup.

Indeed, my mediawiki container runs unexpected with the older Page Forms version 5.6.3 (without the fix) instead of 5.8.1 (with the fix).
It seems this has occured because of the Semantic Bundle 6.1.0 (supported for MW 1.35-1.41) which overwrites any separate Page Forms version. Waiting for 6.2.0...

As mentioned before, the workaround has helped, no issue anymore. Sorry, I should have closed the ticket a while ago.

In the meantime similar issues were reported:
https://serverfault.com/questions/1134001/memcached-support-requires-libmemcached
https://stackoverflow.com/questions/76490445/problem-adding-memcached-support-in-docker-for-php8-1-using-bookworm

Yes, it is the latest debian stable. How to install memcached without errors?

No dependant image, I am open to any working solution. and the big question still, why is the image build with bookworm?

After installing the newer version using git, the error has disappeared.
git clone https://github.com/wikimedia/mediawiki-extensions-DrawioEditor DrawioEditor

The extension is working fine with SVG only (which is set by default and recommended), but not with PNG (which is supported).
Here the documentation: https://github.com/wikimedia/mediawiki-extensions-DrawioEditor#file-type

Adding the #drawio tag without type is working

This error occured because the pivot directory is in MW1.39 case sensitive (in MW1.35 wasn't).
The solution was to change 'pivot' to 'Pivot' and of course wfLoadSkin( 'Pivot' ); instead of wfLoadSkin( 'pivot' );

Hi @Aklapper, sorry for the misunderstanding. The author is looking for a solution to be able to show the creation date of an article within citations.
There is no technical description how could exactly be solved, but we suggested if possible to be implemented with the MW variables (aka magic words).

Hi @Aklapper, thanks for mention it, I filled out the use case(s) as requested.

In T34207#5521765, @Ciencia_Al_Poder wrote:

There are reports of it not even working for ASCII characters due to a bad lowercase conversion on a varbinary column

See this topic where a workaround is provided and is actually very popupar, given the amount of thank comments received by the author of the workaround: Topic:Pwjch65m0lbr7n8e.

The error Could not locate the bindings file... is due to a bad installation of librsvg2, i.e. the directory node_modules/librsvg/build doesn't exist.
For a proper installation use --unsafe-perm option for npm install command: