Page MenuHomePhabricator

[RFC] Method for bare page retrieval (e.g. render only / no skin)
Closed, DeclinedPublic


Apps and API-driven skins will need access to existing MediaWiki functionality like special pages. Currently, there is no clean API that

  • covers both wiki content and special pages,
  • allows interaction with special pages the same way regular, fully skinned access do, and finally
  • provides page component metadata to allow loading of appropriate RL modules, and more generally composition (see T105845).

Implementation options

  1. API:
    1. Extend action=render to cover special pages, as proposed in T106894.
    2. Extend action=parse to cover special pages.
    3. Create a new API entry point altogether.
  2. Skin: Create a "null" skin that only returns the content area & metadata, and select it with a header.


  • URL compatibility: The "null" skin has the advantage of interfering least with current interaction patterns by using the same URL layout as regular page views. Forms posting back to a special page should work as-is, although we'd need to be careful to make sure that the skin selection header is consistently applied. Preserving URL compatibility in API end points would be difficult.
  • Caching: Compared to query strings, the Skin tends to provide more deterministic URLs, which is good for caching. We'd need to set up a vary on the skin header. Purging would continue to work as-is.
  • Discoverability: The API options shine here by integrating with existing API documentation.
  • Alternative skin selection methods:
    • A cookie is easy to set, but slightly harder to work with in caches (vary) and other proxies. It is also reliably added to redirected requests.
    • A custom header is easy to set in proxies like ServiceWorkers or services, and has good vary support. On redirect, custom headers might be dropped.
    • Adding a query string requires URL parsing, and might be dropped on redirect.

Tentative conclusion

The "null" skin option looks like the most attractive option overall. For the skin selection, a custom header seems to be slightly easier to use than a cookie.

Event Timeline

GWicke raised the priority of this task from to Needs Triage.
GWicke updated the task description. (Show Details)
GWicke added a project: Services.
GWicke added subscribers: GWicke, cscott, dr0ptp4kt and 4 others.

This is a nitpick, but I think it would help to say "HTTP header" if that's what you mean, instead of just header.

The task description also sort of suggests that action=render is part of api.php, but it's only part of index.php, as far as I know. Looking at T106894, it seems like it may make sense to re-evaluate what the render action is and whether it's still needed.

In general, I'm not sure I understand the problem statement here. This task jumps into implementation options pretty quickly. If the goal is "access to existing MediaWiki functionality like special pages," which Special pages are we talking about specifically? Special:UserLogin and Special:Preferences and similar pages already have api.php modules, of course (action=login, action=options). We also have an api.php module for Special pages such as Special:MostCategories (list=querypages). What functionality is missing here that apps and API-driven skins need?

This comment was removed by GWicke.
GWicke edited projects, added Services (later); removed Services.

Create a "null" skin that only returns the content area

Something like useskin=apioutput? Example:

Create a "null" skin that only returns the content area

Something like useskin=apioutput? Example:

Yeah, or useskin=none.

Krinkle renamed this task from [RFC] Page component retrieval & interaction API / null skin to [RFC] Method for bare page retrieval (e.g. render only / no skin).Jan 26 2019, 6:39 AM
Pchelolo added a subscriber: Pchelolo.

I don't think we this ticket is relevant anymore after 4 years of inactivity.