Page MenuHomePhabricator

Have PopularPages bot only overwrite the list section of the report
Closed, ResolvedPublic3 Estimated Story Points


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.

Event Timeline

kaldari triaged this task as Medium priority.Mar 16 2017, 7:23 PM

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.

@kaldari How else could this be done? Update the first "section" on the page?

That's a pretty good solution. You could just overwrite anything after the first section header and leave the top part alone.

Let's add something like this to the report:

<!-- 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.

kaldari set the point value for this task to 3.Mar 20 2017, 11:24 PM

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

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...

Okay, even if I do a 'query' it still gives a Fatal.

I am wondering if this should be handled in the mediawiki-api-base library. I can probably still do some sort of workaround.

@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

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:

Sticking with current solution though.