It says Could not connect to network
Version: Alpha
Severity: normal
It says Could not connect to network
Version: Alpha
Severity: normal
I can't reproduce this on a beta build of the Android app, but then again I'm not able to edit enwiki's [[MediaWiki:Common.css]] via the app either (when logged in), even though I'm able to do that from the desktop view (as I have global editinterface rights, but the app doesn't seem to recognize those).
Does quickUserCan check for global rights? that is what the API backend that the app uses checks...
Yes it works - just checked that mobileview correctly returns that it can edit MediaWiki: NS pages from my staff account.
I just checked and I can't seem to edit MediaWiki:Common.css from the app. I just get "Could not reach the network :("
This problem exists because the API is behaving differently for MediaWiki namespace pages as compared to normal content pages. The problem is the "rvsection=0" parameter that's included in the request; this causes the request to return an error, rather than the relevant content.
Compare this:
https://en.wikipedia.org/w/api.php?action=query&prop=revisions&rvprop=content&rvlimit=1&titles=MediaWiki:Common.css&rvsection=0
to this:
https://en.wikipedia.org/w/api.php?action=query&prop=revisions&rvprop=content&rvlimit=1&titles=MediaWiki:Common.css
Here's proof that the patch actually worked, for those that don't want to edit the MediaWiki namespace: https://en.wikipedia.org/w/index.php?title=MediaWiki:Common.css&diff=prev&oldid=659249426
Section editing should work in the MediaWiki namespace... But you won't be able to do it on pages with the CSS content model. Or several other content models which aren't wikitext.
Oh, and I suggest not making edits against production site-wide CSS/JS pages just to test your client. Please use your own wiki.
eh yeah what @Krenair said. Or use a similar page that is not transcluded by a couple 10 000 people at any time and that will invalidate caches etc....
I did want this patch to be based on the page's content model, but it is not possible to retrieve the content model of a page via mobileview. The overhead of an extra network request on every edit to check the content model of a page, slowing the app down and increasing data usage, for the 0.00001% of edits that take place in the MediaWiki namespace does not seem like a worthwhile tradeoff to me.
I have filed a task for retrieving the content model of a page via mobileview: T97249
For reference, NS_MEDIAWIKI = 8:
MariaDB [enwiki_p]> select page_content_model, page_namespace, count(*) from page where page_content_model is not null and page_content_model != 'wikitext' group by page_content_model, page_namespace; +--------------------+----------------+----------+ | page_content_model | page_namespace | count(*) | +--------------------+----------------+----------+ | Scribunto | 118 | 1 | | Scribunto | 828 | 356 | | css | 2 | 2162 | | css | 8 | 12 | | flow-board | 4 | 2 | | flow-board | 5 | 1 | | flow-board | 2600 | 46 | | javascript | 2 | 2655 | | javascript | 4 | 1 | | javascript | 8 | 30 | | json | 8 | 3 | +--------------------+----------------+----------+ 11 rows in set (1 min 24.02 sec)
Also in T72835 we're trying to get rid of the (remaining) assumptions in core about JS/CSS pages only being in the MediaWiki/User namespaces...
I've abandoned the above patch in favour of using a solution based on this patch, which will be live in production around 6th May: https://gerrit.wikimedia.org/r/#/c/206651/
This isn't quite the primary use case for the app. Even if the app supported editing common.css, it doesn't actually use common.css when displaying content.
I do note that with things like deeplinking and associated domains etc, this might be something to be very careful with. If you are going to be throwing people automatically into an app, based on a url, but then not handling the url, that's not good.