There is a user preference for enabling Special:Homepage, which is off by default for a fraction of users (for A/B testing purposes, and for historical reasons for older users). We probably want to get rid of that eventually (see also T269847: Automatically enable the Homepage when a logged-in user visits [[Special:Homepage]] and T292090: Research Spike: Enable Growth features for autocreated accounts (if the user already has Growth features)) but we need a quick fix for leveling up features like T322387: New post-edit dialog for non-suggested edits which send the user to the homepage.

This is slightly tricky:

• We are still running A/B tests with the homepage disabled for some users, so we can't just rip out that user preference entirely (although it's something we might want to consider in the longer term).
• We can't immediately change the user's preference since we cannot write to the DB on a GET request.
• We can't just ignore the preference when showing the homepage and change it in a background job, because the homepage schedules a number of data fetching jobs (for suggested edit tasks, user impact etc) and those jobs need the preference to be already updated.
• We could make the homepage do a GET -> POST -> GET redirection but that would be a pretty sub-par user experience: GET -> POST can only be done on the client side, we'd have to load an empty page with some javascript, it's slow and possibly at least somewhat visible to the user. That doesn't seem worth it.
• We could make the post-edit dialog update preferences via the API, but that seems fragile - it might not finish by the time the user gets sent to the homepage, it might get aborted because the user is leaving the page.

Probably the best option is to make the user visit the homepage via POST:

• Have the post-edit dialog create and submit a form via JS so the user gets sent to the homepage as a POST request, and probably an URL flag like force-enable=1.
• On the homepage, detect the flag, write the user preference, and do a POST -> GET redirect. (Not super important, but avoids some small UX issues, eg. the user trying to reload a page generated via POST will result in an "are you sure you want to submit again" popup dialog.)
• On mobile, we need an URL fragment like #/homepage/suggested-edits to show the right homepage section. In theory, the fragment is preserved by the steps above, but I wouldn't fully trust browser implementations to do it. So maybe add something like fragment=/homepage/suggested-edits to the URL, and then the GET redirect step can convert that to a real fragment.

Alternatively, we can just not show the post-edit dialog if the user does not have the homepage enabled. That's very simple (just an extra line of condition checking) but excludes users from the feature if they have first registered on another wiki. (I think from the experiment they would be excluded anyway, so maybe that's not a big deal in the short term.)