| TheresNoTime | |
| Aug 23 2022, 1:24 PM |
| F35530546: missing_file.gif | |
| Sep 23 2022, 9:10 AM |
| F35530527: missing_file.png | |
| Sep 23 2022, 9:10 AM |
If between the point where an article is saved & cached, and when a user loads and parses the article the IPA audio file has been deleted, we need to handle how to display this error to the user and regenerate the audio file.
One suggestion is to have a link to purge the article in the error message.
Note: interaction between purging and Live Preview or Real Time Preview needs to be investigated.
| Project | Branch | Lines +/- | Subject | |
|---|---|---|---|---|
| mediawiki/extensions/Phonos | master | +65 -28 | PhonosButton: show error with link to purge/reload when file is missing |
On the surface, I'm not sure how this can even happen. After https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Phonos/+/825393, the code path says if a file doesn't exist on parse, it gets recreated -- always. But, it is possible someone could run the maintenance script to delete old files, and someone views the cached version of an effected page. In that case, no re-parsing is done and there will be a missing file. I think showing a link to re-parse the page would suffice (perhaps doing it via JS, so you don't have to view the confirmation screen at action=parse). I was also thinking of keeping metadata that would track which pages use which files, so that the maintenance script can do the re-parsing for us, but I feel like that would be overly complex. Overall I suspect the situation of a missing file to be pretty rare. Pages regularly get re-parsed anyway so things will eventually fix themselves.
🤦♀️ okay, that makes this even more of an edge-case — is this worth doing any work on at all? Or should we just rely on the fact that this will be incredibly rare, plus as you said, pages get reparsed periodically?
I think it's worthwhile to show an error message with a link to re-parse, if we want to. That's easy enough to code and to test. I wouldn't go much further than that right now, unless we have any belief this scenario is something we should be worried about.
The front-end will have to check if the file is found or not (currently it just sets the <audio> src attribute and assumes this makes it play. On error, it'll show a message e.g. "Unable to play. Click to try again." and clicking that popup could then send a POST request to action=parse (thus avoiding the confirmation page). That'd get the user back at the same place (although we'd maybe want to scroll the page down to the current position?) and with a hopefully now-existing audio file.
Change 830697 had a related patch set uploaded (by MusikAnimal; author: MusikAnimal):
[mediawiki/extensions/Phonos@master] PhonosButton: show error with link to purge/reload when file is missing
Change 830697 merged by jenkins-bot:
[mediawiki/extensions/Phonos@master] PhonosButton: show error with link to purge/reload when file is missing
Test wiki created on Patch demo by GMikesell-WMF using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/659c2d5bfa/w
Error when the file is missing:
Clicking the "Refresh the page and try again" reloads the page (and in the background makes an API request to purge the page). Purging the page should regenerate the missing IPA file.
It should be noted that the icon only displays the error condition after you click on it:
Pinging @JFernandez-WMF to confirm that they are OK with the way the error looks and is worded.