So since March people are unable to update from old MW versions?

Fixed with Chrome 59.0.3071.86

Fixed with Chrome 59.0.3071.86

Fixed with Chrome 59.0.3071.86

MW Sandbox:

• logged in: yes
• logged in & safemode=1: yes
• logged out: yes
• logged out & safemode=1: yes

• Go to https://www.mediawiki.org/wiki/Project:Sandbox?action=edit&veswitched=1&oldid=2466865
• Quickly add 5 extra rows
• Click some tag button

Still. Chrome 58.0.3029.96 (64-bit)

Yes and every page.

So the problem still exists in MW 1.28?

the status quo is using JS, srcset is not working with current browsers

Sure, we could also just skip that and wait for a much better solution in 5 years :P

No. I remain unable to update since August now because of 1.27 complications.

I figured out I had not set $wgFlowContentFormat which defaults to "html" which requires Parsoid (T147712).

How can MW 1.27.1 be stable with a broken hook?

CharInsert.body.php

5 years later and it's still not possible to create a one word button for multi-line code. E.g.

This ticket can be closed.

I ment it in this way:

Yep. I always had $wgJobRunRate = 0, so misunderstanding $wgRunJobsAsync didn't break anything :)

And back to the topic: Users complain that they need to see category changes immediatly. Therefor it cannot be delayed in jobs (of whatever kind).

https://www.mediawiki.org/wiki/Manual:$wgRunJobsAsync

When the execution of jobs during normal page requests is enabled (by setting $wgJobRunRate to a number greater than 0; it defaults to 1), then this variable controls whether to execute them asynchronously or not.

@aaron: Thanks. I have this setup

• $wgJobRunRate = 0;
• $wgRunJobsAsync = true;
• restInPeace() > DeferredUpdates::doUpdates( 'run' );
• maintenance/runJobs.php > via cronjob (minutely)

In includes/MediaWiki.php > function restInPeace() > I changed
DeferredUpdates::doUpdates( 'enqueue' ); back to
DeferredUpdates::doUpdates( 'commit' ); (as it was in MW 1.25.1)

Your pasted text block replies are of less help than my bug reports ;)

Why was categorization outsourced to the job queue then if not for performance?

We have $wgJobTypesExcludedFromDefaultQueue but that only excludes jobs from runJobs.php

Categorization via the job queue enhances the performance?

With $wgRunJobsAsync = true; new pages don't appear in a cat after saving. On mediawiki.org the delay in ~20 seconds.

• Add this file https://www.mediawiki.org/wiki/File:Test_2016-09-09.jpg to [[Category:Test cat]]
• Click on the link to check the cat > The image is not there.
• Be an advanced user and use the non existent action=purge tab > The image is not there.

In T145206#2625366, @Aklapper wrote:

In T145206#2625302, @Subfader wrote:

I edited the top post.

I don't see a list of steps to see and reproduce the problem. :(

I edited the top post.

Update: MW 1.27 destroyed the usage of all these hooks since categorization is fired after onPageContentSaveComplete.

I use the hook PageContentSaveComplete to flush some memcached stuff based on category changes.

MW 1.27 and this crap is still core code.

Not sure why there is a "forceHTTPS" cookie. I don't use HTTPS and have not enabled such variables.

Extended log as suggested: https://phabricator.wikimedia.org/P3994

I shot too fast. $wgAuthenticationTokenVersion = "1"; logged me in again. But in fact I cannot log out until I delete all cookies. Now I can't log in again like before.
Super annoying bug so far.

<strike>I think I found it.</strike> I raised $wgAuthenticationTokenVersion to "2" right after the installation. Later while trying to debug I raised it even more.

jQuery 3.1.0 was released in July.

A show stopper like this is not a blocker?

Also, $wgDisableAuthManager does not work.

My test instance is on a subdomain, but I cleared all cookies, disabled JS, checked console. nothing.

I have the same problem on a fresh installation on

• MW 1.27.1
• PHP 5.5.9-1ubuntu4.14 (cli)
• Apache/2.4.7 (Ubuntu)
• http://subdomain.myrealwiki.com

Feedback: In ConfirmEdit I only use $wgCaptchaQuestions > for registration which gives edit rights. Works rock solid for me and I hope it will be supported in the future.

Not in the internal API (MW 1.25) it seems.

When will this be fixed? I installed MW 1.27 and Special:Preferences is still broken.

On search I want to watch the file results in MediaViewer.

For the record: The biggest performance boost is to additionally create webp thumbs :)

This is even more important when you additionally create webp thumbs (up to 30-50% less file size).

Thanks, I'll check that on the next update.