Hey everybody,
This was already posted to Mediawiki-api-announce, x-posting here for
increased visibility as this change should be in production this week.
With the merge of Icb674095,[1] use of API action=logout will require
a CSRF token. This was considered a security issue, so the usual
deprecation process was not followed. See T25227[2] for details.
Clients that do not use a CSRF token with action=logout will receive a
badtoken error message ***and will not be logged out***.
This change should be deployed to Wikimedia wikis with 1.34.0-wmf.3.
See https://www.mediawiki.org/wiki/MediaWiki_1.34/Roadmap for a
schedule.
Overall client impact is expected to be relatively low, as gathered
statistics indicate there are relatively few users of this API call.
None the less, maintainers should check their code for use of
action=logout and update as necessary to maintain expected operation.
[1]: https://gerrit.wikimedia.org/r/c/mediawiki/core/+/504565
[2]: https://phabricator.wikimedia.orgdo not use /T25227
<https://phabricator.wikimedia.org/T25227>
[3]: https://phabricator.wikimedia.org/T25227#4902709
--
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
Hi, what would you like to see in gerrit or improved? I've been working been working on developing a plugin that pull's in zuul's status into PolyGerrit. See the running demo at https://imgur.com/a/uBk2oxQ . Im also planning on adding "recheck" and "check experimental" as buttons to PolyGerrit's ui to improve CI. This will help new users who can recheck (and existing users that either forgot they can type this or haven't learned yet).
Note that i cannot promise that anything suggested in this thread will be worked on, but i can try my best.
See tasks https://phabricator.wikimedia.org/T214068 and https://phabricator.wikimedia.org/T214631 .
Hello,
Over night I have added a new Jenkins instance to the stack but
unfortunately it came with a broken Docker daemon. Thus any CI job
running on that instance would fail to download any image.
The symptom looked like:
Unable to find image 'docker-registry.wikimedia.org/releng/castor:0.2.0'
locally
0.2.0: Pulling from releng/castor
docker: open /var/lib/docker/tmp/GetImageBlob682696395: no such file or
directory.
Build step 'Execute shell' marked build as failure
The root cause is that I have pointed Docker to a new disk partition but
forgot to restart the Docker daemon :-\
https://phabricator.wikimedia.org/T222131
If one one of your change got affected, simply commenting 'recheck'
should get the job running again as usual.
--
Antoine "hashar" Musso
Reminder: Technical Advice IRC meeting this week **Wednesday 3-4 pm UTC**
on #wikimedia-tech.
Question can be asked in English & Hebrew!
The Technical Advice IRC Meeting is a weekly support event for volunteer
developers. Every Wednesday, two full-time developers are available to help
you with all your questions about Mediawiki, gadgets, tools and more! This
can be anything from "how to get started" over "who would be the best
contact for X" to specific questions on your project.
If you know already what you would like to discuss or ask, please add your
topic to the next meeting:
https://www.mediawiki.org/wiki/Technical_Advice_IRC_Meeting
Hope to see you there!
Michi (for the Technical Advice IRC Meeting crew)
--
Michael F. Schönitzer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
https://wikimedia.de
Unsere Vision ist eine Welt, in der alle Menschen am Wissens der Menschheit
teilhaben, es nutzen und mehren können. Helfen Sie uns dabei!
https://spenden.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
Hi all,
Is there an API call that would allow you to retrieve the edit notice for a
page?
Huji
PS: I would ask it on Discourse, except
https://phabricator.wikimedia.org/T222045
Hi all,
We are doing an edit-a-thon and some participants are using the content
translator with some complicated issues.
The main one is that the content translator is now integrating Google
translator but when a participant publishes the translation, the AbuseFIlter
says that it is an automatic translation from Google even if the participant
has modified the text.
This happens specifically in the Chinese Wikipedia. Is that normal?
We have seen that modifying the wiki links and the external references it
solves the problem, but in other linguistic versions the Content Translator
does it automatically.
In addition it doesnt work for tables and for infoboxes.
May someone confirm that these issues are connected with some bugs and that
we are not doing some mistakes?
Kind regards
-------------------
Ilario Valdelli
Education Program manager and community liaison
Wikimedia CH
Verein zur Förderung Freien Wissens
Association pour lavancement des connaissances libre
Associazione per il sostegno alla conoscenza libera
Switzerland - 8008 Zürich
Wikipedia: <https://meta.wikimedia.org/wiki/User:Ilario> Ilario
<http://www.wikimedia.ch/> http://www.wikimedia.ch
Hi, I am voluntarily working with CIS to conduct various MediaWiki Traning
programmes in Indian Universities.[1] We have already conducted two
training programmes. Now the third iteration of the MediaWiki Traning
programme is planned for 21 May 2019 at Christ University.[2] But due to
being Developer account creation temporarily disabled[3], New contributor
will not able to create the account. So what should be way forward? Should
we postpone the event or account creation will available before the 21 May
Account creation rights may be an option? But I am not sure it works on
Wikitech.
Thanks & Regards
[1] https://meta.wikimedia.org/wiki/CIS-A2K
[2] https://en.wikipedia.org/wiki/Christ_University
[3] https://wikitech.wikimedia.org/wiki/Special:CreateAccount
User:Jayprakash12345
Lead Member, Indic-TechCom
For one of our custom wikis we have a Special Page that creates new pages based on form input. This used to work in MW1.23 but in the long overdue update to MW1.31 it stopped working.
The Special Page is supposed to write a record to a shared external database and then use the autoincremented row number to set the name of the page that will be created. I’m using $dbw->insert to do this. In 1.31 the autoincrement index gets bumped but the row doesn’t get written. If I do the same insert from a maintenance script, it works, so I’m assuming it doesn’t have anything to do with general configurations or other extensions (which I’ve inactivated).
After it gets a value for the lastInsertID it tries to make a page from a template. That page is never created and I see this in the error logs:
PHP Fatal error: Uncaught Wikimedia\\Rdbms\\DBUnexpectedError:
Wikimedia\\Rdbms\\Database::close: mass commit/rollback of peer transaction required (DBO_TRX set). in
/Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/database/Database.php:916\nStack trace:\n#0
/Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1217):
Wikimedia\\Rdbms\\Database->close()\n#1
[internal function]: Wikimedia\\Rdbms\\LoadBalancer->Wikimedia\\Rdbms\\{closure}(Object(Wikimedia\\Rdbms\\DatabaseMysqli))\n#2 /Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1640):
call_user_func_array(Object(Closure), Array)\n#3
/Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1218):
Wikimedia\\Rdbms\\LoadBalancer->forEachOpenConnection(Object(Closure))\n#4
/Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1208):
Wikimedia\\Rdbms\\LoadBalancer->closeAll()\n#5
/Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/loadbalancer/LoadBal in
/Library/WebServer/Documents/omp/wiki/includes/libs/rdbms/database/Database.php on line 916,
referer: http://localhost/omp/wiki/index.php/Special:StrainNewPage
This happens even if comment out the code that accesses the external database completely and hard code the ID.
Other Special Page extensions we have that create new pages seem to work on 1.31.1. I’m wondering if this is related to the method that now fails being a callback from HTMLforms for processing form submission.
Any insight, help in debugging this would be much appreciated. Apologies if I’m using some terminology incorrectly (I’m a biologist more than a coder).
Jim Hu