Noting that if this is not done by the time MW 1.41 releases, then compatibly with scripts such as mergeMessageFileList.php will break as extension registration is now required.

I launched a new XMLRCS instance in wm-bot project.

I've managed to launch an XMLRCS instance on the main wm-bot server - no more dependence on the huggle project.

In T139371#9107594, @MacFan4000 wrote:

The specific issue mentioned in the description was resolved, as the pgsql server is now within the wm-bot project. It may be good to have xmlrcs under the wm-bot project as well.

The specific issue mentioned in the description was resolved, as the pgsql server is now within the wm-bot project. It may be good to have xmlrcs under the wm-bot project as well.

In T335507#8968849, @Stashbot wrote:

Mentioned in SAL (#wikimedia-cloud) [2023-06-27T16:48:40Z] <taavi> building initial set of bookworm based images: node18, ruby31, python311 (T335507)

Both VMs have now been migrated. I've shut down the old ones, but will keep them a bit longer just in case.

Bookworm has been released

So I believe the error I posted above means that redis on the xmlrcs server needs restarting. Xmlrcs is not fully down or else the wm-bot module would have failed to load upon a restart.

LOG [1/1/2023 5:08:52 AM] [ERROR]: ModuleRC: redis is empty for 10 seconds

Declined per my comment above.

In T320446#8306200, @MacFan4000 wrote:

Things are back up but still very unstable.

Well, after I said that things proceeded to remain stable for a day and are still stable as of right now.

Things are back up but still very unstable.

There is now an official release. (https://we.phorge.it/phame/post/view/1/going_public/)

Also https://we.phorge.it/w/installation_and_setup/update_from_phabricator/

now updated using the master branch from Gerrit. There does appear to be a deprecation warning.

I should be able to do this tomorrow. (Maybe tonight but not likely)

Fixed by updating

found the current log and error is the same

sorry was looking at old logs. Is still broken though.

I think this can be closed? The mentioned versions have been released at this point.

With the git.io service now discontinued, unless we look at using a different provider, this is no longer possible.

Fixed by @Petrb.

I went ahead and updated the patch using code from the moralize implementation. Credit goes to @Universal_Omega.

Closing as invalid, as when I look in the web console on Wikipedia as well as another wiki, and when I look at the MW code, I see that the correct autocomplete values are set.

@Florian Do you mind if I update your patch for this with some code from the working version, and get it reviewed/hopefully merged?

(The existing patch is 2 years old at this point) - Both miraheze and testwiki.wiki have v3 deployed using a custom extension (https://github.com/miraheze/MirahezeMagic/tree/master/ReCaptchaNoCaptcha), and so far it’s proved very effective, with pretty much no spambot account creations since it was deployed - it would really be nice to have v3 available as part of ConfirmEdit!

The code for the login form does seem to set autocomplete values (https://github.com/wikimedia/mediawiki/blob/51b5edd2adb5b33d6cc042df2aae5175144a0640/includes/specialpage/LoginSignupSpecialPage.php#L905) but they don’t take effect on the login form I checked the web inspector for both wikipedia, and a different wiki, and I am seeing autocomplete values that are correct.

Doing a quick search in the code (for core), it looks like we pretty much already use these values for autocomplete.

I’ve done some testing and the solution that I’ve found so far is to set autocomplete to “one-time-code”. It was set to off per T226049 and T141735, but at least in safari the problem mentioned in those tasks doesn’t happen when setting it to “one-time-code”.

In T284590#7297843, @Majavah wrote:

In T284590#7297767, @Base wrote:

Inside toolforge-php74-sssd-web image when running composer I encountered

Warning from https://repo.packagist.org: Support for Composer 1 is deprecated and some packages will not be available. You should upgrade to Composer 2. See https://blog.packagist.com/deprecating-composer-1-support/

as well as

As there is no 'unzip' command installed zip files are being unpacked using the PHP zip extension.
This may cause invalid reports of corrupted archives. Besides, any UNIX permissions (e.g. executable) defined in the archives will be lost.
Installing 'unzip' may remediate them.

Both non-critical warning, but Composer 2 for one should be a welcome thing to have as it is faster.

Can you file a separate task please? I can get those sorted.

never mind, didn't see the earlier fix.

there seems to have been an error with my commit, @MtMNC I have a fix coming soon.

In T285565#7224200, @Aklapper wrote:

Could that note not only be on the frontpage of https://wm-bot.wmflabs.org/ but also on every subpage? Because deeplinks (every page is page one).