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.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Jul 15 2021
Jul 15 2021
Antigng added a comment to T280798: Fix namespace blocks of removed extension namespaces (and actions).
Jul 12 2021
Jul 12 2021
Antigng reopened T280798: Fix namespace blocks of removed extension namespaces (and actions) as "Open".
Antigng added a comment to T280798: Fix namespace blocks of removed extension namespaces (and actions).
@STran The patch introduced a regression that causes the Special:Block form never to include "main space" for anyone partially blocked against ns0.
Feb 16 2021
Feb 16 2021
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.
Jul 26 2020
Jul 26 2020
Jul 8 2020
Jul 8 2020
Antigng added a comment to T249680: Clients failing API login due to dependence on "Set-Cookie" header name casing.
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:
Jun 27 2020
Jun 27 2020
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.
Sep 16 2019
Sep 16 2019
Antigng added a comment to T228876: Some interface messages are default messages instead of local overrides for language variants on Chinese Wikivoyage.
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
Aug 19 2019
Aug 19 2019
Aug 10 2019
Aug 10 2019
Antigng added a comment to T228876: Some interface messages are default messages instead of local overrides for language variants on Chinese Wikivoyage.
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.
Aug 8 2019
Aug 8 2019
Antigng added a comment to T229379: On zh.wikipedia.org, MediaWiki wrongly interprets an article about main pages as the wiki's main page.
BTW, all pages listed above contain T228876-like issues, indicating they are probably caused by the same bug.
Antigng added a comment to T229379: On zh.wikipedia.org, MediaWiki wrongly interprets an article about main pages as the wiki's main page.
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?
Antigng added a comment to T229379: On zh.wikipedia.org, MediaWiki wrongly interprets an article about main pages as the wiki's main page.
pages.zip1 MBDownload
Collected a few problematic responses. It seems that this issue has nothing todo with the following:
- 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.
- Client-side 304 issues, given that my code doesn't implement client-side caching at all.
- HHVM/PHP7 preference. All above requests were served by php7, thus the claim "PHP7.x instances are correctly configured" is not true.
- Varnish cache, as all above requests encountered a cache miss.
Jun 27 2019
Jun 27 2019
It seems that only requests coming through Varnish frontends at eqiad are affected.
Jun 16 2019
Jun 16 2019
May 28 2019
May 28 2019
The cause of this problem has been identified. Given that
May 25 2019
May 25 2019
Mar 22 2018
Mar 22 2018
Antigng added a comment to T161595: Allow users who can remove but not add a right to shorten userrights expiry.
> Anyway, anyone with a real use case is very much invited to re-open this task and explain their case.
Feb 22 2018
Feb 22 2018
Antigng updated the task description for T187975: Abuse logs not moved under the new username after user renaming.
Antigng updated the task description for T187975: Abuse logs not moved under the new username after user renaming.
Nov 21 2017
Nov 21 2017
This seems to be a side effect of this commit.
Sep 18 2017
Sep 18 2017
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?
Sep 8 2017
Sep 8 2017
Antigng added a comment to T175338: Fatal: Wikimedia\Rdbms\DBQueryError on Special:AbuseFilter/examine: "Error: 1054 Unknown column 'rev_id' in 'field list' (10.64.16.191)".
The problem seems to be a side effect of this.
Aug 26 2017
Aug 26 2017
Antigng updated the task description for T171813: Error occured when viewing difference on conversiontable page.
Antigng updated the task description for T171813: Error occured when viewing difference on conversiontable page.
Jul 27 2017
Jul 27 2017
Jun 20 2017
Jun 20 2017
Sep 14 2016
Sep 14 2016
The patch works for me.
Aug 18 2016
Aug 18 2016
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
Aug 8 2016
Aug 8 2016
Aug 7 2016
Aug 7 2016
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年英国体育'中的页面".
Feb 27 2016
Feb 27 2016
I was getting the same error on Chinese wikipedia when I tried to change my password.
Feb 12 2016
Feb 12 2016
https://github.com/fastily/jwiki/blob/master/src/jwiki/core/Auth.java#L37 Jwiki doesn't handle the token properly.
Jan 29 2016
Jan 29 2016
Antigng added a comment to T124252: NEED_TOKEN error spike when 1.27-wmf.11 SessionManager was deployed to group1.
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.
Nov 20 2015
Nov 20 2015
Nov 17 2015
Nov 17 2015
Also, User:Markmingjie failed to restore his flow archive today.
Nov 14 2015
Nov 14 2015
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL