In T280798#7205364, @dom_walden wrote:

In T280798#7205193, @Antigng wrote:

@STran The patch introduced a regression that causes the Special:Block form never to include "main space" for anyone partially blocked against ns0.

I can confirm this on beta. I am guessing it is because $this->getLanguage()->getFormattedNsText() returns '' for NS_MAIN.

@STran The patch introduced a regression that causes the Special:Block form never to include "main space" for anyone partially blocked against ns0.

In T274605#6832642, @JAllemandou wrote:

Hi @Shizhao and @cooltey, thanks for reporting.
I have done some deeper analysis and my finding is that the hits to the 中華電信MOD articles are made by products developed by the company (it seems to be mostly TV boxes).
I assume that the boxes ping the article to check that their internet connection is working, as the article is only one queried by the boxes.
I'll talk to the the team about strategies to move this traffic to the automated one (it doesn't go there naturally as the number of hits per IP/user-agent doesn't reach the threshold.

Just to mention that apache httpd does a camel casing by default when proxying back from an http2-talking backend to an http1.x-talking frontend:

Thanks for notification. The problem is what I'm running is not a single task, but ten individual tasks instead. To minimize common mode failures, they were designed to run as individual processes, each being able to do its own task by itself, from login to querying to editing, without relying on sessions/tokens from other processes. On finishing, they logout and exit. A batch file is created to run all of them every 10 mins.

In T228876#5493016, @Aklapper wrote:

Nobody can fix it if you do not provide clear steps that allow other people to see and reproduce a problem...
I've asked for clear steps several times here, but my requests are ignored in this task. https://www.mediawiki.org/wiki/How_to_report_a_bug

In T228876#5407026, @Sunny00217 wrote:

In T228876#5401982, @Shizhao wrote:

Test Results:

• Normal page ( nstab-main display as "条目" ): x-powered-by: PHP/7.2.16-1+0~20190307202415.17+stretch~1.gbpa7be82+wmf1
• Anomalous page ( nstab-main display as "页面" ): x-powered-by: HHVM/3.18.6-dev

This mean we using HHVM and having this error? BTW,some time Tags php7 (PHP7) will show in Tags,but some time it didn't work,like https://zh.wikipedia.org/w/index.php?title=Wikipedia:沙盒&action=history

Codes or scripts should only edit via api.php rather that index.php, and the former does provide the choice between "bot" and "nonbot". Thus I would suggest close this as invalid.

BTW, all pages listed above contain T228876-like issues, indicating they are probably caused by the same bug.

Based on these observation, I would suspect that this is a message/message-cache only issue. I've noticed that recently serveral changes were made to Message.php and MessageCache.php (T228555). Could one of them have the potential to cause these problems?

1. Cookies. Given that my code for fetching these pages send no cookies, except the one that enforces php7, to the server, cookie is not the necessary condition to get such errors. This also implies that switching the default language (which cannot be done unless by using cookies) is not necessary for reproducing errors.
2. Client-side 304 issues, given that my code doesn't implement client-side caching at all.
3. HHVM/PHP7 preference. All above requests were served by php7, thus the claim "PHP7.x instances are correctly configured" is not true.
4. Varnish cache, as all above requests encountered a cache miss.

It seems that only requests coming through Varnish frontends at eqiad are affected.

Also, ATS doesn't change the via header as Varnish does.

The cause of this problem has been identified. Given that

> Anyway, anyone with a real use case is very much invited to re-open this task and explain their case.

This seems to be a side effect of this commit.

In T171813#3609253, @Aklapper wrote:

The supplied ParserOptions are not safe to cache. Fix the options or set $forceParse = true.

@Antigng: So did you fix your options? What was $forceParse set to? If it was not true, did setting it to true fix this?

The problem seems to be a side effect of this.

The patch works for me.

Yeah. Someone reported this on zhWP's village pump.

Well, it has something to do with zhwiki. zhwiki uses the language converter, which converts "Category:XXX" to simplified Chinese "分类:XXX" or traditional Chinese "分類:XXX" for logged-out users, based on the location of their IP address. In your patch, this->getPrettyPageNameHtml() is called to get the subheading, and you might expect that expression

Do you mean in preview mode?

It didn't change anything on the edit page. However, it did change the subheading on the submit page, which had been "Pages in category 'Test'" before your patch was applied.

This change completely breaks our category subheading displaying mechanism. https://en.wikipedia.org/w/index.php?title=Category:Test&action=submit gives "Pages in category 'Editing Category:Test'", and https://zh.wikipedia.org/zh-cn/Category:2016%E5%B9%B4%E8%8B%B1%E5%9C%8B%E9%AB%94%E8%82%B2 gives "分类'分类:2016年英国体育'中的页面".

I was getting the same error on Chinese wikipedia when I tried to change my password.

https://github.com/fastily/jwiki/blob/master/src/jwiki/core/Auth.java#L37 Jwiki doesn't handle the token properly.

In T124252#1979688, @Lsj wrote:

Login works well enough now, but bot sessions are much less stable than they used to be. Far too often, the bot either gets logged out or starts receiving error messages in the middle of a run. The most frequent error is "Invalid token", but I have also seen messages saying that "Wikipedia is in read-only mode". If I break the run and start over, everything works fine again.

User:Qsx753698

Also, User:Markmingjie failed to restore his flow archive today.