Thanks for the reply. We also have not encountered it on a 1.43 wiki, but I'll update this issue if we do (but hopefully it is fixed). It is scary that it is entirely unknown why this happens though :(

This happens for us on MediaWiki 1.39.13 with PHP 8.1.2 (Ubuntu 22.04 with Apache).

We still regularly run into this issue on numerous wiki's. The only remedy we have found so far is to periodically touch the file using a crontab, as mentioned before. It would be great if this could be looked at again!

Thank you for your detailed report and the provided patch. I’ll check this out in detail coming Tuesday.

The cookie-consent-tags-processed event is fired after consent has been processed.

The lifetime has been increased to 1 year.

The user can now control the maximum length of pipelines through $wgArrayFunctionsMaxPipelineLength.

I have patched this in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ArrayFunctions/+/1153328.

ArrayFunctions compatibility policy is to keep support as long as possible.

This helped me realize the e-mail I had assigned in Phabricator is very old, and no longer works :)

See: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ArrayFunctions/+/1151213

The possibly problematic functions are:

MediaWiki already restricts the total output size of the arrays through $wgMaxArticleSize, therefore we should only consider internal computations that take a very long time (e.g. computing a very large range). For these functions, specialized restrictions can be put in place.

This has been done :)

Thanks!

Done in https://gerrit.wikimedia.org/r/1017059.

While adding the proposed trim function, I realised there were already a number of functions that implicitly trim whitespace. While I like the idea that whitespace handling is always explicit, this is not possible with the way the MediaWiki parser is designed (whitespace is trimmed before being passed to templates or parser functions).

This is the expected behaviour, as the string A is different from the string A. I will add a trim-like function to make dealing with this easier though.

Thinking about it, the root cause might also be the communication from PHP to Lua happening after calling mw.text.jsonDecode, in which case closing this as a duplicate makes sense.

@Izno, that task is about communication from PHP to Lua, while this task is about communication from Lua to PHP. Is this really a duplicate?

Thank you for the suggestion. I have implemented this in version 1.7.0.

Hi @Westgrass, I have implemented this. :)

Have you tried using a template to wrap the three parser function calls?

Hi Sebastian, you must use WSOAuth 9.0.0 for PluggableAuth 7.0.0, as documented in the compatibility matrix on the extension page. I agree that the version constraint in the extension.json is too loose, so I will see if I can make it stricter.

@valerio.bozzolan Have you had time to look at this yet?

Hi @valerio.bozzolan! I have implemented this. Please take a look to see if it meets your requirements: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WSOAuth/+/912282.

Done!

This has been implemented. See patch above.

I believe this can now be closed. Feel free to re-open it if any additional work is required.

I have also noticed that even when an invalid display title is set in a slot other than main (which is not taken into account), the tracking category restricted-displaytitle-ignored is still added to the page.

I have created a pull request that implements this feature: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WSOAuth/+/810922.

This is a duplicate of T305623.

Because of this bug, Structured Discussion does not work in conjunction with PluggableAuth.