Page MenuHomePhabricator

Funnel users with edit intention to login/signup
Open, Needs TriagePublic

Description

Currently, if an anonymous user does not have permission to edit a page, the edit tab will be relabelled to "view source", and the section edit links will be hidden. If the user clicks "view source", they see a generic error message: "You do not have permission to edit this page, for the following reason: The action you have requested is limited to users in the group: Users." This is vague and discouraging.

The relationship between edit and "view source" made more sense before VisualEditor became popular. It's questionable whether "view source" is a sufficiently important operation to justify its very prominent placement on the UI for anonymous page views, at least in the main namespace.

On pt.wikipedia.org, anonymous edits were disabled by administrator actions on the site (T261133). JavaScript rewrites the edit tab for anonymous users so that it is still labelled "edit", but clicking it takes you to the login page. The login page is customised, informing the user that creating an account is required for editing. I am proposing that this feature be reimplemented in MediaWiki.

Specifically:

  • Add a global configuration variable indicating that anonymous edit intention should be funnelled towards login. If it is enabled, anonymous page views should always show section edit links, and edit tabs should be labelled per VE configuration. Clicking the edit links would take you to the login page.
  • When the user arrives on the login page after clicking an "edit" link, a special banner is shown, and successful login automatically returns to the edit page.
  • "View source" would be available as a link from the login page banner.
  • Perhaps "View source" could also be available via a link in the tools portlet in the sidebar of the page.
  • For protected pages, and otherwise when the "users" group does not have edit permissions, the edit tab would show a visual indicator of being restricted (say by colour or a lock icon), but would otherwise function as described above.
  • Red links would retain the current behaviour (lack of permission causes a redirect to the page view).

This task reflects my personal views. I would like to invite comments.

Event Timeline

@MMiller_WMF this might be interesting for the newcomer experience pilot.

On pt.wikipedia.org, anonymous edits were disabled by administrator actions on the site (T261133). JavaScript rewrites the edit tab for anonymous users so that it is still labelled "edit", but clicking it takes you to the login page. The login page is customised, informing the user that creating an account is required for editing. I am proposing that this feature be reimplemented in MediaWiki.

@Niharika I think a user protested this idea on the Log in Required Experiment talk page. I thought to flag this for you.

@Niharika I think a user protested this idea on the Log in Required Experiment talk page. I thought to flag this for you.

For the record, personally, my comments were about doing this sort of thing client-side. I was and still am not opposed to implementing better interfaces for IP editors in wikis where IP editing is disabled. ptWP solution is not bad in that regard (even if convoluted and not intuitive in terms of what ‘Edit’ links do there).

This sounds like a clear improvement. If the ptwiki client-side hack fails (e.g. the user has disabled Javascript), the edit will be blocked by an IP block or an abuse filter, resulting in a confusing message, and the user will almost certainly give up and go away.

It might make more sense to link to signup instead of login (as long as a new user has sufficient permissions for the action, and the wiki has open signup), there are probably way more edit attempts by anonymous editors without an account than by logged-out users.

I guess this should apply to other edit-like actions (undo, restore) as well. For actions that happen via web form submit, the action handler can just redirect. Client-side editing workflows (VisualEditor, mobile wikitext editor, also DiscussionTools and Flow if we care about supporting such behavior outside the main namespace) seem more work to handle - the initiating code would have to be able to detect the relevant configuration (probably via a JS variable), redirect to the login page, and then make sure that it is loaded on return and can resume the editing workflow.

One thing to be careful about is session timeouts - if a logged-in user is e.g. doing a preview, or even just reloads a tab which browsers sometimes do for memory efficiency reasons, and their session is not valid anymore, ideally there should be a way for them to recover the content of the input window. That seems hard.

"View source" would be available as a link from the login page banner.

I'm not sure it's worth showing there. I agree the page tools menu is a more logical place for it.

It is important to remember that such a tool was applied in pt.wiki in a very controversial way, as I reported at the time. For a change, it is not the first nor is it the last controversial decision of the type that the local community applies.