thank you yaron. your fix works fine.

MW 1.39.6
PHP 8.1.27

hi yaron, thanks for your comment. no worries :) i just added the patch for visibility reasons. i build-patch my docker image that way until you fix it upstream, so the deprecation errors disappear.

Thanks for coming back to this. I do like the black/whitelist approach. I fully agree with you to keep the number of settings low. However, some time passed and of course my use case changed a little. Clients needed different restrictions per namespace. So after forking I ended up with the config below. I find it odd, because it drifts away from the original use case. But it works for me as I don't use the exclude config at all. For this use case it seems difficult to use black/whitelists while retaining backwards compatibility (in the sense that it bloats the codebase) .

Hej Yaron, thanks. Unfortunately, this does not fix the issue in our case. I set all methods in the CargoBacklinks class to null to patch the deadlock issue for us. So the cargo_backlinks table does exist in our system but it never gets written to. This was the least complicated approach for me, as the table would be created again when running update.php.

i agree. we face the same issue w/ our clients' wikis.

that is not really an option for us, as we have dozens of MediaWiki instances that we provide w deployments and also run update.php for. i think the deleted cargo_backlinks table would be recreated after update.php was run?

well... next to maintenance scripts, the change affects actual requests that parse wikitext with cargo queries in them, such as: saving a templates, accessing Special:FormEdit, ...

In T306597#7872315, @Yaron_Koren wrote:

Shouldn't the contents within the comments also get removed/replaced?

if you agree that html comments are useful in this case, i would propose such a fix.

i get these on every page load, also while running maintenance scripts

i am facing the same problem. an issue seems to be the order of the files present in the zip archive (see https://stackoverflow.com/questions/7274030/detect-excel-xlsx-file-mimetype-via-php).

ok i used a different hook; see below;

yes i did. i didn't recognize anything wrong with the image file. i used gnome's image viewer.

ubtuntu 16.04
imagemagick: Version: ImageMagick 6.8.9-9 Q16 x86_64 2018-09-28
ghostscript: 9.26

Are there any updates on this issue?

there you go; i think using a parsing algorithm rather than regexes could be more robust in the long-run... i could check if i find some code portions in the PageForms extension/somewhere else; let me know what you think

sure you're welcome; i replaced the regex with {{(?>[^{}]|(?R))*}} and replace matches with preg_replace_callback instead. i have a running mediawiki development instance locally and tested the code successfully w/ our project's forms.

No need to be sorry. Thank you for the blitz fix! It works great!