Page MenuHomePhabricator

[Request] Standardize editor URls so that different editors should have unique URLs
Open, Needs TriagePublicFeature


Feature summary (what you would like to be able to do and where):

It's proposed that

  • A query string parameter is added to all edit URLs which captures which editor is used.
  • when a wiki has multiple editors enabled ?action=edit would redirect to the appropriate URL. (with action=edit&editor=<name>)
  • There is a single preference that captures the "default" editor.
  • The link rendered by skins would always point to the appropriate editor
  • The VisualEditor two tabs would still work as currently, only one of those links would be to the default editor.

We seem to have unique URLs for some of the editors, but there's no standardisation across them.

Use case(s) (list the steps that you performed to discover that problem, and describe the actual underlying problem which you want to solve. Do not describe only a solution):

  • Would save time debugging bug reports (it's not always clear /which/ editor a bug reporter is reporting for if they don't include a screenshot)
  • Would make it easier to QA/test different URLs - currently to test the Wikitext editor for example, I have to update multiple preferences just to see it
  • Would allow skins to identify editors based on URLs and have special treatments for them (as needed for T307725)
  • We could add visual regression tests to

Benefits (why should this be implemented?):

Without this, we'll continue to add significant technical debt as we work around this.

For example, in Vector we have a max-width that is configurable only by page URL. Because editors do not have unique URLs we can't use the existing code, and would instead have to write some VisualEditor specific code (see

Event Timeline

Can you explain how this would resolve the Vector-2022 challenges when we load an editor without reloading the page, e.g. when you launch VisualEditor? We could update the URL using the history API (we already do it with the current URLs), but that won't run all of the server-side PHP code that currently decides to do things based on the URL.

We have a check on the server-side inside Vector which checks the URL and Title object to inform the template how to render against configuration ( It then modifies the page accordingly e.g. enables sticky header/max-width/other features that are namespace specific. We need to do this on the server to avoid layout reflows so history APi wouldn't help here. I was imagining we could use a 302 status code here to do the redirect.

In the case of the editor, when we want editor-specific behavior it doesn't seem like we can use the Title or URL to work out the type of editor. So if we want a different treatment of VisualEditor compared to Wikitext 2010 editor like in the case in T307725 we can't do it.

Open to other solutions to this problem - one thing that has proved challenging in T307725 is having to modify multiple preferences to test it. I now have a dedicated account to test, but wish I could just use a URL to do that. Having a URL would also allow us to add test cases to which is purely URL based.

There are always going to be links to action=edit that we can't control (add an editor preference to):

  • Red links (especially cached content which can't be varied by user preference)
  • Other generated links on wiki and elsewhere

In these cases we will have no hint about the desired editor, but we should still respect the user preference. As such this task will not completely solve the issue of knowing which editor to load based purely on the URL.

Also worth considering that (in general) we'd like it if, when a link to an edit page is sent, the person following that link sees their own preferred editor rather than whichever editor was being used by the person who sent the link. Making more links which are editor-specific and don't respect the viewer's preferences seems like it'll decrease people getting their preferences respected.

This comment was removed by DLynch.

Making more links which are editor-specific and don't respect the viewer's preferences seems like it'll decrease people getting their preferences respected.

I was thinking that ?action=edit would be an HTTP redirect to the editor that respected the user preferences. We do this on mobile for various pages e.g. Special:MobileHistory. Is there a reason we could not do this in the editor? Personally as an editor, there are some pages that I cannot edit with VE and some pages that I cannot edit without, so I imagine from a user perspective having dedicated URLs would be useful (I'm often jumping into preferences or disabling JavaScript to switch to the old school editor for certain complex template pages for example)

I think it can be helpful and unhelpful depending on the scenario. There are times when you want to specify an editor, but also times when you don't, and if we always put the current editor in the address bar people will naturally copy and paste it. This is similar to the issue with people pasting links to the mobile site.

True. The history API could be used (call to replaceState) to reset the URL to action=edit if that's a concern.