Perhaps this should be closed since support for Redis queue is deprecated since at the very least 1.38?

Tangentially related: when $wgUploadBaseUrl/$wgUploadPath are set to an HTTPS location, MediaWiki emits HTTP CONNECT requests to CdnServers for uploaded files' URLs (thumbnails as an example) when a File: page's cache is purged.

I have been running MediaWiki on PHP 8.0 since 1.38 was released, with CirrusSearch+Elastica and a number of other extensions. Using PostgreSQL back-end, to boot.

I feel like array_shift() is out of place here: even if the assignment is replaced by a simple call, dropping the first element completely, it obviously makes the supposed later test

switch ( true ) {
                        case count( $propertyDescription ) > 1:
                                // There are multiple page props with the name 'description' present
                                // This shouldn't happen, but we'll try to clean it here
                                $db->delete(
                                        'page_props',
                                        [
                                                'pp_page' => $this->title->getArticleID(),
                                                'pp_propname' => 'description',
                                        ]
                                );
                        // Intentional fall-through, as deleting all 'description' props requires inserting a new row
                        case empty( $propertyDescription ):
                                $shouldInsert = true;
                                break;

Note: the addition of this class to the navigation widget results in this shift on MediaWiki 1.38.1 with Vector 2022:

@Aklapper, my apologies, I completely forgot to comment on this. The updated extension requires 1.38 and does not work with 1.37.1.

In T248925#7723615, @JeroenDeDauw wrote:

What about PHP 8.1 for MediaWiki 38? Can we expect it to work as well as MW 37 on PHP 8.0?

I am planning an upgrade to 1.37.x (still on 1.36.x at the moment) within a few days and this will be a good way to test these changes; will report here on the outcome.

I assumed HTCP is no longer used by WMF?

I think this is at least related to T267524.

If it is possible to move the current functionality into an extension without losing performance, it would be rather useful since it would be a nice example in ‘how to make a purge client extension’. I wanted to implement a small purge proxy in Rust but got stuck in MW's purge client code and then kind of forgot about it.

For a quick fix with a local installation, simply ALTER the schema for transcode and use TIMESTAMPTZ.

The rationale laid out in this blog post makes sense but I am not sure it is feasible to stay on cURL 7.61 and below forever or backport changes from newer versions.

Thank you, the patches seem to fix the issue: the Active Users page is now working as intended on all my MediaWiki instances.

Apologies for the delay, I somehow missed the e-mail notification completely. The 14-character fields are definitely not working as the format of the timestamps being inserted is full YYYY-MM-DD HH:MM:SS+TZ; TIMESTAMPTZ seems to work fine.

Patch (removes EOR flag and uses PHP constants instead of hard-coded ones):

By the way, I have another bug to report. This one I have not yet traced in the source (it is very hard to get it to actually happen and thus get a stack trace): unquoted column identifier for _pageID, once again.

Update: this seems to trigger DB server overload. Deadlock detection has timeouts and this leads to PostgreSQL reaching its connection limit (my max_connections is set to 1024 and it gets exhausted during massive user influx).
These hanging connections seem to lead to ResourceLoader actually failing to load CSS and JavaScript.

https://www.mediawiki.org/wiki/Special:ExtensionDistributor is broken again.

Note: this is still not fixed in 1.32.

Pruning is broken for PostgreSQL:

Perhaps there's a better way to detect these platform-specific constants?

@Ivor your patch fails in the first 4 chunks for REL_1.31 so I tried adapting it. Notably there is now an $ignore check which adds DO NOTHING to the query; I added a check for $set to avoid it if we already have an ON CONFLICT UPDATE added.

PostgreSQL user here, anything I could help with here? I have TMH installed and with the table/indexes added File pages seem to work so far.

It most likely is a duplicate, my apologies — should have searched better prior to creating this one.

Oops, missed T130634, please ignore.

Re: the first issue, I checked the documentation and seems like changing in page/WikiPage.php:

Further testing:

File moving is still broken in 1.29.1:

@Ivor, I applied your patch 2 days ago and no errors so far, thank you. Benchmarks show database query time improvements of around 5% (probably thanks to no error logging going on any more, along with a better query plan).

In T167942#3656191, @Ivor wrote:

this revealed the missing unique index in the mediawiki.redirect table over rd_from (this is a foreign key, but we don't want a page to be redirected to two or more other pages -- this never actually happened, I assume it's handled in the code, but the unique index is required in the ON CONFLICT clause). After creating the unique index, all error messages seem to be gone now.

Side note: technically there are no problems that could lead to any kind of data loss or corruption (this happens inside a transaction), but I am not sure it is good practice to issue statements that lead to messages flooding the database server's error log.

I would like to reiterate that this error appears in PostgreSQL error log with a severity of ERROR. Debug log is off at least in my case.

Thank you. I guess this won't ever be fixed, then.