Why alecexposed.org is complaining about No available desktop renderer.?

[benoit74]

Zimfarm recipe: https://farm.openzim.org/recipes/alec_exposed

The last task (ran with dev right now, see close to a 1.14) fails with No available desktop renderer..

I don't get why, because all prerequisites are ok:

• Mediawiki version is 1.30 (see https://www.alecexposed.org/wiki/Special:Version)
• ActionParse API seems to be working

Working: https://www.alecexposed.org/w/api.php?action=parse&format=json&prop=text|modules|jsconfigvars|headhtml&formatversion=2&page=ALEC_Bills

Working with warning Unrecognized parameter: parsoid: https://www.alecexposed.org/w/api.php?action=parse&format=json&prop=text|modules|jsconfigvars|headhtml&formatversion=2&page=ALEC_Bills&parsoid=1

[audiodude]

I added some logging and I'm getting the following:

====== Error checking API availability: https://www.alecexposed.org/api/rest_v1/page/html/ALEC_Exposed
====== Error checking API availability: https://www.alecexposed.org/api/rest_v1/page/mobile-html/ALEC_Exposed
====== Error checking API availability: https://www.alecexposed.org/w/rest.php/v1/page/ALEC_Exposed/html

In fact all of those URLs are 404s.

So I'm not sure if the site is misconfigured and the endpoints are not enabled, or if mwoffliner is misconfigured and we're not looking for them in the right places.

As far as "ActionParse API", I don't see any references to that in the mwoffliner code and I'm not sure it's an API we work with.

[benoit74]

Regarding "ActionParse API", I was refering to the name listed here.

REST API is indeed not available on this website, so it is normal these calls are returning 404.

But why none of the logs you get are referring to something like https://www.alecexposed.org/w/api.php?action=parse&format=json&...? Is there another place in the codebase to check?

[audiodude]

Okay I added more logging. By default, mwoffliner uses the "desktop" renderer for the main page of the ZIM, and the "mobile" renderer for everything else. This is what I have in the logs:

Checking for WikimediaDesktopApi at https://www.alecexposed.org/api/rest_v1/page/html/ALEC_Exposed
Checking for WikimediaMobileApi at https://www.alecexposed.org/api/rest_v1/page/mobile-html/ALEC_Exposed
Checking for VisualEditorApi at https://www.alecexposed.org/w/api.php?action=visualeditor&mobileformat=html&format=json&paction=parse&formatversion=2&page=ALEC_Exposed

I also noticed that none of these URLs work for other pages that exist on the site:

https://www.alecexposed.org/wiki/Alabama

https://www.alecexposed.org/api/rest_v1/page/html/Alabama
https://www.alecexposed.org/api/rest_v1/page/mobile-html/Alabama
https://www.alecexposed.org/w/api.php?action=visualeditor&mobileformat=html&format=json&paction=parse&formatversion=2&page=Alabama

This is not a problem with mwoffliner, the source wiki is misconfigured.

[kelson42]

Okay I added more logging. By default, mwoffliner uses the "desktop" renderer for the main page of the ZIM, and the "mobile" renderer for everything else.

I confirm this, reason is that (Wikipedia) main page used to look so ugly in mobile view... maybe this could/should be reconsidered because:

• this software design decision is old
• it complexifies significantly MWoffliner

[benoit74]

I still don't get it sorry. The logs you're pushing are speaking only about REST API and VisualEditor API. This website has none of them, so it is not a surprise those calls are failing.

This website however has an ActionParse activated and this does not seems to be tested at all given the logs you're pushing here. Why? Is the documentation wrong/outdated? I.e. on a non-wikimedia instance, you need either REST API or VisualEditor?

[audiodude]

I've updated the logs, and I'm interested in checking in the messages, because it makes it more clear the URL that was checked so that when a failure like this occurs, we can easily manually check:

Checking for WikimediaDesktopApi at https://www.alecexposed.org/api/rest_v1/page/html/ALEC_Exposed , result is:  false
Checking for WikimediaMobileApi at https://www.alecexposed.org/api/rest_v1/page/mobile-html/ALEC_Exposed , result is:  false
Checking for RestApi at https://www.alecexposed.org/w/rest.php/v1/page/ALEC_Exposed/html , result is:  false
Checking for VisualEditorApi at https://www.alecexposed.org/w/api.php?action=visualeditor&mobileformat=html&format=json&paction=parse&formatversion=2&page=ALEC_Exposed , result is:  false

I believe that the docs are, in fact, out of date, because these are the only APIs that mwoffliner 1.14-dev is able to use (along with the names that they're referred to as in the code).

[benoit74]

Cool, I will update the doc then

[kelson42]

I believe that the docs are, in fact, out of date, because these are the only APIs that mwoffliner 1.14-dev is able to use (along with the names that they're referred to as in the code).

It is probably not that simple, see #1899. Would probably great to have an update on this Pabricator ticket (from us). It's pity I don't have open an issue our side for more clarity... I feel a bit lost.

[audiodude]

I believe that the docs are, in fact, out of date, because these are the only APIs that mwoffliner 1.14-dev is able to use (along with the names that they're referred to as in the code).

It is probably not that simple, see #1899. Would probably great to have an update on this Pabricator ticket (from us). It's pity I don't have open an issue our side for more clarity... I feel a bit lost.

Why can't we update the docs with the actual APIs that are used by the code? Why does it depend on an old PR that adds parsoid support?

[kelson42]

I believe that the docs are, in fact, out of date, because these are the only APIs that mwoffliner 1.14-dev is able to use (along with the names that they're referred to as in the code).

It is probably not that simple, see #1899. Would probably great to have an update on this Pabricator ticket (from us). It's pity I don't have open an issue our side for more clarity... I feel a bit lost.

Why can't we update the docs with the actual APIs that are used by the code? Why does it depend on an old PR that adds parsoid support?

I have no problem with updating the doc. I just say that we migh still or will still rely on the action=parse API... and that actually the phabricator issue linked in that PR is a serious concern for the WMF.

[audiodude]

If you look at the logs I pasted, we use paction=parse in our attempt to hit the visual editor API.

[audiodude]

I have no problem with updating the doc. I just say that we migh still or will still rely on the action=parse API... and that actually the phabricator issue linked in that PR is a serious concern for the WMF.

Based on a quick grep, the only place we use action=parse is here: https://github.com/openzim/mwoffliner/blob/main/src/util/builders/url/api.director.ts#L58

But that method itself doesn't seem to be called from anywhere. So from what I can tell, when we release 1.14, that phabricator ticket will be resolved. Though, when I looked through the code for 1.13, it seemed that action=parse was only used for getting module dependencies.