Hello everyone,
Some of might know that the parsing team has been porting Parsoid from
Javascript to PHP this year [1]. Over the last couple months, we have
done intensive testing in various modes (parser tests, round trip
testing, HTML string diff testing) to verify correctness of Parsoid/PHP
relative to Parsoid/JS and continued to fix bugs (both Parsoid/PHP &
Parsoid/JS). We have also had some client testing and QA on beta cluster
via host headers.
With all that behind us, we believe it is time to do a bit more
intensive live QA. So, we have switched over the beta cluster to use
Parsoid/PHP (instead of Parsoid/JS). We have also switched the
production test.wikipedia.org and test2.wikipedia.org to use Parsoid/PHP
instead of Parsoid/JS. With this change, VisualEditor, Content
Translation, and Mobile Content Translation will use Parsoid/PHP on
these wikis. Flow / StructuredDiscussions will need a separate config
change and will continue to use Parsoid/JS in all these places till that
change is written and deployed.
If you are able to, please test visual editing and content translation
on test and test2 wikis and file phabricator tasks. Bug reports [2] are
greatly appreciated. :-)
Incident-free switchover from Parsoid/JS to Parsoid/PHP has been our
goal and this testing is the next step along that way. You can follow
along progress and changes via the tracking phab task [3].
Thanks,
Subbu.
(on behalf of the parsing team).
1. https://www.mediawiki.org/wiki/Parsing#Current_projects
2. https://phabricator.wikimedia.org/tag/parsoid-php/
3. https://phabricator.wikimedia.org/T229015
Hi there,
Hope I've found the correct list for asking this question.
I was setting up a CI test case for my MediaWiki Client Library to run a bot that will upload a file to https://en.wikipedia.beta.wmflabs.org in chunked stash mode. For most of the time, when I perform the final upload with filekey parameter, I will receive a fileexists-no-change error from the MW API server. This is expected, as there is already a same file with the same title on the site. However, today I received backend-fail-alreadyexists. The error message looks like
backend-fail-alreadyexists: The file "mwstore://local-swift-eqiad/local-public/archive/9/95/20191116051316!Test_image.jpg" already exists.
Does this error usually occurs when user tries to upload the same file? What's the difference between fileexists-no-change and backend-fail-alreadyexists?
Thanks,
Xinyan
Hello,
We have requested a 30 minutes read-only window for s6 wikis (T235475) for
the 19th Nov from 05:00-05:30 AM UTC to switchover that section primary
database master (T235469)
db1061 is an old host and out of warranty that will be decommissioned
(T217396). The new master will be db1131.
We are going to do this on Tuesday 19th Nov from 05:00 to 05:30 AM UTC (we
do not expect to use the 30 minutes window, if everything goes as expected).
Impact: Writes will be blocked on the following wikis
frwiki
jawiki
ruwiki
Reads will remain unaffected.
Communication will happen at #wikimedia-operations
If you are around at that time and want to help with the monitoring, please
join us!
Thanks
When running `composer update` MediaWiki injects a mediawiki/mediawiki package, so extensions can declare a dependency on a particular MW version range.
However, when doing a `composer update --dry-run` this package gets not injected causing the dry run to fail.
Does anybody know a solution/workaround?
Stephan
To enable extensions to declare a version constraint on MW, so an incompatible version of an extension is not installed in the first place instead of crashing MW later on.
Stephan
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, November 15, 2019 4:27 PM, Florian Schmidt <florian.schmidt.welzow(a)t-online.de> wrote:
> Extensions can express a dependency to mediawiki core in their extension.json. not sure where, how and why a non-existing composer package should be injected to a composer run.
>
> Am 15.11.2019 10:15 schrieb David Barratt <dbarratt(a)wikimedia.org>:
>
>> as far as I know, extensions shouldn't be declaring a dependency on
>> MediaWiki in composer.json and if one is, it should probably be fixed.
>>
>> On Fri, Nov 15, 2019 at 9:50 AM Stephan Gambke via Wikitech-l <
>> wikitech-l(a)lists.wikimedia.org> wrote:
>>
>>>
>>> When running `composer update` MediaWiki injects a mediawiki/mediawiki
>>> package, so extensions can declare a dependency on a particular MW version
>>> range.
>>> However, when doing a `composer update --dry-run` this package gets not
>>> injected causing the dry run to fail.
>>>
>>> Does anybody know a solution/workaround?
>>>
>>> Stephan
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Wikitech-l mailing list
>>> Wikitech-l(a)lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>> _______________________________________________
>> Wikitech-l mailing list
>> Wikitech-l(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
