We should remove support for interwikis when creating or editing a registration, but still make it possible to display the event page's full title on wikis other than the one where the event page is located. Testing instructions: T307358#7957782
Detailed description
Event registrations are global, and our goal is to make it possible to view, create, and edit them from any wiki, with the event page possibly being on another wiki than the one you're currently on. This requires a decent level of support for external pages within MediaWiki, which isn't quite there. In particular, we have the following use cases:
- When you create a registration, you can enter a page title, potentially being on another wiki
- Same when you edit a registration; additionally, in this case we should also format the page title (à la getPrefixedText) for the default value of the field
- When you query the details of a registration (using this endpoint), one of the elements in the response is the formatted page title
- In the "Your events" page, we should provide links to event pages potentially being on another domain; there should also be the formatted page title
- Same for the event calendar/agenda that we will build in a future version
Let's start from the places where users can input page titles: these are the CreateEventRegistration and EditEventRegistration special pages. We have two ways to allow external pages there: a single title input field with interwiki support, or two separate fields -- one for the wiki name, and one for the page title as relative to that wiki (without interwiki support). For more details, see T307108. The first solution is not recommended because of limitations with interwiki links (chiefly T306713, and also T307107, since interwikis can point to non-local, non-MediaWiki sites). The second solution is much better, and in the first implementation we could omit the wiki field altogether, hence forcing all pages to be local to the wiki where the registration is created. This would address use case (1.) (CreateEventRegistration).
Now onto the other input, EditEventRegistration. If you're editing the registration from a wiki other than the one where the event page is located, we don't have a way to format the page title. The details of this will be discussed for item (3.), but here the main issue is that we do need both form fields (title and wiki), and we chose to omit the second one for now. We have two options here: a) Display an error message and send the user to the right wiki; b) do implement the wiki field. Option a) is easier to implement and would address this use case; option b) is more ideal, but harder to implement, plus there would be additional limitations outlined below. So let's say that we choose option a) for now. This, together with the same validation implemented for the CreateEventRegistration page, would be enough for (2.).
Now, let's talk about the API for event details. The issue here is that we may have to format the title of a page located on another wiki, having the namespace ID, the page's own name and the wiki it belongs to as our only information. Unfortunately, this doesn't seem to be possible: a wiki cannot reliably access the namespaces of another wiki (T226667). MediaWiki does have something (Site::normalizePageName()) that formats the name of a foreign page by making an HTTP request to the other wiki; however, to use that you need to already know the namespace name + page title, which is exactly the information that we need and don't have. More broadly, IIUC, clients have no way to map a namespace ID to a namespace name via the public API -- this information only exists within MediaWiki. Thus, we cannot format a page title by having only the namespace ID and the page's own name. Once again, we have two options: a) if the page is external, redirect the client to the correct wiki with a 3xx status code; b) store the formatted title in the database when a registration is created or updated. Option (a) is easier but it only shifts the problem to the next use case. Option (b) would possibly work, but it's hacky and less clean. Moreover, if we do (b), we would be able to format the page name in other places, like the EditEventRegistration use case (after the "wiki" field is implemented).
As for the "Your events" page: we do need to show external page here; I think this is pretty much not negotiable: no errors or redirects here. I think the only way to get a formatted page title is option (b) proposed for item (3.): storing it in the database. The same considerations above apply here. Additionally, we need a link. This should be easy to do via Site::getPageUrl, assuming that we have the full page name (and we do, if it's stored in the DB).
Finally, for the event calendar/agenda: it should be 100% the same as "Your events".
Conclusion: storing the full page name in the database seems pretty much necessary and the only option we have. It's a bit hacky, but perhaps acceptable. This would be enough for use cases (3.), (4.), and (5.). It would also be necessary (but not sufficient) for (1.) and (2.), but for those we would additionally need a wiki input field.
Please let me know if I missed any use case and what you think of the above. Thanks!
