Under the old PopularPages bot, when a new report was created, it would be created with a header, a list, and categories. When the report was updated, only the list itself would be updated, with the header and categories untouched. This allowed editors to customize the header and categories without worrying about them being overwritten each month. Let's try to match this behavior in the new bot, i.e. if a report is being created from scratch, build the whole page, but if the report already exists and already has a list, just update the list.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • TBolliger | T141154 [Epic] Fix and improve Mr.Z's popular pages report | |||
| Resolved | Niharika | T160683 Have PopularPages bot only overwrite the list section of the report |
Event Timeline
Comment Actions
BTW, the list detection should probably not be based on a specific header, like "List", as this will be different for different languages once we have multilingual support.
Comment Actions
That's a pretty good solution. You could just overwrite anything after the first section header and leave the top part alone.
Comment Actions
Let's add something like this to the report:
==List== <!-- Changes made below this line will be overwritten on the next update. -->
I'm not too worried about the categories. I actually haven't seen any report pages with custom categories, but if someone really wants to put the page in a special category, they can just include it above the List header.
Comment Actions
Looks like this is still throwing fatal errors, specifically when a page exists, but doesn't have a section 1:
PHP Fatal error: Uncaught exception 'Mediawiki\Api\UsageException' with message 'There is no section 1 in Wikipedia:WikiProject Gambia/Popular pages.' in /mnt/nfs/labstore-secondary-tools-project/popularpages-dev/public_html/vendor/addwiki/mediawiki-api-base/src/MediawikiApi.php:273 Stack trace: #0 /mnt/nfs/labstore-secondary-tools-project/popularpages-dev/public_html/vendor/addwiki/mediawiki-api-base/src/MediawikiApi.php(218): Mediawiki\Api\MediawikiApi->throwUsageExceptions(Array) #1 /mnt/nfs/labstore-secondary-tools-project/popularpages-dev/public_html/vendor/addwiki/mediawiki-api-base/src/MediawikiApi.php(188): Mediawiki\Api\MediawikiApi->decodeResponse(Object(GuzzleHttp\Psr7\Response)) #2 /mnt/nfs/labstore-secondary-tools-project/popularpages-dev/public_html/ApiHelper.php(337): Mediawiki\Api\MediawikiApi->getRequest(Object(Mediawiki\Api\FluentRequest)) #3 /mnt/nfs/labstore-secondary-tools-project/popularpages-dev/public_html/ApiHelper.php(76): ApiHelper->apiQuery(Array, 'parse') #4 /mnt/nfs/labstore-secondary-tools-proje in /mnt/nfs/labstore-secondary-tools-project/popularpages-dev/public_html/vendor/addwiki/mediawiki-api-base/src/MediawikiApi.php on line 273
Comment Actions
Okay. I see now. We're trying to 'parse' a non-existent section. In case of page we 'query' it. There's gotta be a workaround...
Comment Actions
Okay, even if I do a 'query' it still gives a Fatal. https://en.wikipedia.org/w/api.php?action=query&prop=revisions&rvprop=content&rvsection=7&format=jsonfm&titles=Wikipedia:WikiProject%20Adelaide/Popular%20pages
I am wondering if this should be handled in the mediawiki-api-base library. I can probably still do some sort of workaround.
Comment Actions
@Niharika: That sucks. I guess the best thing to do would be to file a bug against mediawiki-api-base and do a work-around for now. Maybe you could fetch the page and do a regex for a header :P
Comment Actions
Okay, a kind soul on IRC helped! https://en.wikipedia.org/w/api.php?action=parse&page=Wikipedia:WikiProject%20Medicine/Popular%20pages&prop=sections
Comment Actions
I was gonna file an issue but it seems like this in the intended behavior and I could have handled it by using a try/catch: http://addwiki.readthedocs.io/projects/mediawiki-api-base/en/latest/quickstart.html#sending-requests
Sticking with current solution though.