@Osnard The code is available here.
There is no documentation but feel free to open an issue on the repository if you have questions.

I am currently hosting a Composer repository mirroring the MediaWiki extension directory (mostly as a proof of concept to show that installing extensions with Composer can work and can be useful).
I would of course be happy to replace it with Packagist or an official MediaWiki repository.

I confirm it now works correctly for me too :)

I confirm I can't reproduce anymore with MediaWiki 1.29.2, ConfirmEdit 1.29+6925a22 and ContactPage 1.29+d269558.

I published a patch here: https://gerrit.wikimedia.org/r/#/c/399457/

Turns out I had to run maintenance/PopulateContributorsTable.php and now Special:Contributors works correctly. (This should probably be added to the wiki page.)

The errors seem to disappear over time. My guess is that forceSearchIndex.php introduced them in the index, but page edits generate the page again without the errors.

I can still reproduce with 1.29+7005f38:

PHP Notice:  unserialize(): Error at offset 20792 of 65535 bytes in /home/vhosts/fabien/archi-mediawiki/vendor/mediawiki/core/includes/jobqueue/JobQueueDB.php on line 807
PHP Fatal error:  Unsupported operand types in /home/vhosts/fabien/archi-mediawiki/extensions/CirrusSearch/includes/Job/ElasticaWrite.php on line 44

This seems to be fixed in ReplaceText 1.29+b02d10f.

Any news on this? We have several users that created a second account when they forgot their password and now we can't merge them because of this bug.

I currently use this to get the latest comment on each page:

$dbr = wfGetDB(DB_SLAVE);
$res = $dbr->select(
    ['Comments', 'page'],
    ['Comment_Page_ID', 'Comment_Date', 'Comment_Text'],
    'page_id IS NOT NULL',
    null,
    ['ORDER BY' => 'Comment_Date DESC'],
    [
        'page' => [
            'LEFT JOIN', 'Comment_Page_ID = page_id',
        ],
    ]
);

Here is my Accept-Language header: fr-FR,en;q=0.5.
Since French is listed first, shouldn't it be picked instead of English?

That might work but I'm not sure I can wrap the form in a template as it is generated automatically (and we definitely don't want to hide it when the user is not on the results page).

Because we have a pretty big form and it takes a lot of space so we think it might look cleaner if we can remove it from the results page.

Here is my patch: https://gerrit.wikimedia.org/r/#/c/335029/

Any news on this? I can submit a patch if needed.

"install" in Composer context means downloading the PHP files. Again the proposed patch does not enable the extension with Composer.

T467 is about using Composer to load extensions, not about using Composer only to download extensions.
The proposed patch does not use Composer's autoloader and you still need to use wfLoadExtension() to load the extension. The patch only allows people to use Composer to download/update the extension (if they want to, this is entirely optional).

Relative or not, the code uses wfExpandUrl() to always give an absolute URL to getimagesize() (in order to have a consistent behavior, because $wgAppleTouchIcon can also be absolute).
So if it points to a non-existing file, the error should be:

failed to open stream: HTTP request failed

Could it be that allow_url_fopen is set to false on the server so getimagesize() can't be used with a distant file?

I can't reproduce anymore with 1.28+88234fa.

It is because the manifest is not on the same domain as the page (and the Access-Control-Allow-Origin HTTP header is not properly set).
I think the easiest way to fix this is to have a relative URL in the <link> tag.
I will submit a patch for this.

Sorry, I made a mistake and created a new change instead of updating the previous one.

As a workaround, wouldn't it be possible to have an option to automatically enable translation on all pages in a namespace, without the need for <translate> tags?
I know this would not be suitable for a lot of wiki but it can help small wikis (including mine) that want to translate all of their content.

I can still reproduce on the REL1_26 branch.

This seems to be fixed on the 1_27 branch.

As a temporary workaround, I tried 1.27+e0ad10a and the emails are sent correctly.

I am interested in this feature so I would like to work on a patch.
Is someone already working on it?

Yes, here it is: https://gerrit.wikimedia.org/r/#/c/290006/

We had a discussion on T123363 and we agreed that using Composer autoloading feature to install extension is probably not a good thing for MediaWiki but that downloading extensions with Composer is harmless.
I personnaly think that it would be pretty useful as Composer is becoming the defacto standard for installing third-party PHP code.

Any news on this? It would be pretty useful to have this extension (and others) available as a Composer package.

What I understand from T467, is that is has been decided that Composer's autoload should not be used to enable, extensions and I totally agree with that.
But Composer is still a very useful way to install extensions (and then we can enable them with wfLoadExtensions).