Last modified: 2012-07-24 07:25:39 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 13847 - Edit attempt which forces login, does not retain current page
Edit attempt which forces login, does not retain current page
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
1.6.x
All All
: Low major (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-26 05:09 UTC by Brian Latimer
Modified: 2012-07-24 07:25 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Brian Latimer 2008-04-26 05:09:01 UTC
My MW implementation requires a login to edit pages, but not to view.  If the user visits a given page, then would like to update that data, they must login to the wiki before the edit is allowed - which works as expected.

However, this behavior is problematic since the page they were on is not maintained.  They must login, then re-navigate to the page they were interested in, before being able to edit.  It would be much more user-friendly to return them to the same page they were trying to edit before the login request.

* STEPS TO REPRODUCE
0) MW configured to require login to edit (i.e.  LocalSettings.php entry of "$wgGroupPermissions['*']['edit'] = false;" )
1) Access any page beyond the Main Page
2) Click 'edit' in main toolbar
 - "Login required to edit" page displayed - with no reference to the page you were just on
3) Click 'login'
 - "Log in / create account" page displayed - with no reference to the page you came from
4) Log in successfully

* RESULTS
"Return to Main Page" is displayed - although we actually wanted to return to where we came from.

* WORKAROUND
Instead of clicking "edit", the user may click "log in / create account" in main toolbar - which presents the same login request, but returns you to the page you were on when complete.  User must then click "edit" again to actually edit the page, however.

Note that upon this attempt, the URL changes to provide a "returnto={pagename}" indication, unlike the direct "edit" attempt.

In other words:
1) Start at:
   http://mycoolwiki.hostname.tld/wiki/index.php/Page_I_want_to_edit

2a) Click "log in / create account", and the URL is:
   http://mycoolwiki.hostname.tld/wiki/index.php?title=Special:Userlogin&returnto=Page_I_want_to_edit
…which is perfect; it says that when your done logging in, to return to that specific page

vs. 
2b) Instead, from that same initial page, click "edit", and the URL is:
   http://mycoolwiki.hostname.tld/wiki/index.php?title=Page_I_want_to_edit&action=edit
(which merely indicates a return to "Main Page")
…and if you click "login" from there, it takes you to:
   http://mycoolwiki.hostname.tld/wiki/index.php/Special:Userlogin
…which contains no reference to the page you just came from.  Completing the login, therefore, merely returns you to the Main Page.


Very frustrating, as my users want to encounter as few hurdles as possible in completing edits to pages.  There should be a method of allowing a non-authenticated user's direct "edit" request to retain the "returnto" indication for the page, allowing them direct access once they have logged in.
Comment 1 Roan Kattouw 2008-04-26 13:20:23 UTC
This was fixed ages ago. If possible, you should upgrade.
Comment 2 Brian Latimer 2008-05-24 03:15:42 UTC
Understood - thank you for the insights.

However, once upgrading to MW 1.12, it appears this issue may not be resolved - as I cannot repeat the same behavior at all.

I'm now confronted with a different issue: Although I still have:

  $wgGroupPermissions['*'    ]['edit']            = false;

…set in LocalSettings.php, the "edit" tab at the top has now changed to "view source".

Clicking on this now reports:

   You do not have permission to do that, for the following reason:
   The action you have requested is limited to users in the group user.

…which is very confusing for new users.  What happened to the previous behavior?

* Edit link remained an "edit" link
* Clicking on it resulted in:

   Login required to edit
   You have to login to edit pages.

…with a link to the login page itself.  This seems to be vastly superior from a usability standpoint.

How do I regain the older behavior of the edit button remaining an "edit" button, and the clear instructions to the user on why they cannot edit the page?
Comment 3 Brian Latimer 2008-05-24 04:10:11 UTC
Reopening, as I cannot verify this behavior "works as expected", due to the change in the edit flow for MW 1.12.  There appears to be no way to attempt an edit, be transferred to the login page, then be returned to the original page - since the "edit" option no longer appears at all.  Any and all insights would be welcome.
Comment 4 Brian Latimer 2008-05-24 04:39:58 UTC
Another insight: The problem occurs when I click on a tab marked "view source", and am immediately confronted with a page indicating "You do not have permission to do that".

This is quite incorrect - while I cannot "edit" (which is the tab I was actually looking for), I certainly _do_ have permission to "view source", since I'm doing it right then.

The more I investigate this, the more it appears to be a significant bug in MW, regarding the expected processing of the page.  "View source" should only come into play on protected pages, and the "edit" link should simply work as it did with previous versions of MediaWiki (telling the user they need to login to edit, if clicked).  Again, how can I regain this older behavior?
Comment 5 Roan Kattouw 2008-05-24 08:32:22 UTC
Part of this was fixed in SVN some time ago, but after the 1.12 release. In 1.13svn, clicking "view source" actually views the source, but still throws the cryptic error message. The key to this is in Title::getUserPermissionsErrors('edit', $wgUser), which discovers that $wgUser->isAllowed('edit') === false and throws the badaccess-group1 error. Maybe we should have a separate message for this special case where anons can't edit but users can?
Comment 6 Brian Latimer 2008-05-26 04:56:50 UTC
Yes, I'd say that at a minimum, the current message is simply wrong.  Again: If I've clicked on a "view source" tab, please don't tell me that I cannot perform that action - since that is all I CAN do.  Note that the current "error" behavior (system message "badaccess-group1") would almost be correct, if the tab was still labeled "edit" (i.e. "you can't edit, but you can view the source")

Your suggestion of a separate approach for the common occurrence of preventing anonymous users from editing, but allowing logged-in users to do so, would be great.  This seems that it should be the standard behavior - and was essentially the behavior which existed in previous versions of MW.

So, it appears there are several errors (or enhancements) still to be addressed:

1) Allow the admin control over what tabs are displayed.  New users are used to seeing "edit", and admins may get support requests if this tab is replaced with "view source".  The older behavior of showing "edit", but then telling the user they must login to complete the edit, was clear & direct.  I'm frustrated that this was changed.

2) Allow the admin control over the specific error pages which are displayed when clicking on each tab.  It seems that the "Login required" page, which was shown upon an "edit" request, where editing was disallowed, should still be reachable.  But, I can currently find no way of reaching the pages which display the "loginreqtitle", "whitelistedittitle" or "whitelistedittext" strings any more - are the messages and the associated pages still accessible?

3) Provide more control over whether non-authenticated users can view source or not.  Previously, "Login required to edit" meant non-logged-in users could not even see the source; now it seems that they ALWAYS can.  This is not a large concern (if they are viewing the page, they can already see the data), but could give away some aspects of "hidden" entries (categories, templates, etc.), and there appears to be no way of preventing this.


Note that it appears that I can provide a better set of instructions to the user by editing a few of the "Special:Allmessages" entries.  Among them, would be to change "Badaccess-group1" to include a reference to logging in, such as:

   The action you have requested is limited to authenticated users in the group '$1'.

   * If you want to modify a page, you must first [[Special:Userlogin|log in]].

But this still does not appear that it should be necessary - there should be some method of specifying that the "edit" tab (and it's associated "you must login to edit pages" page) be displayed to users.


Can these updates be included within 1.13?  What is the expected schedule for this upcoming release?
Comment 7 Sumana Harihareswara 2011-10-01 02:16:49 UTC
"What is the expected schedule for this upcoming release?"

Sorry that you didn't get an answer to this when you asked, Brian.  MediaWiki 1.17.0 is currently out, and we expect to release 1.18.0 within the next few months.  But I'm not sure whether the current behavior provides a workflow you'd find suitable... could you check?
Comment 8 matanya 2012-07-24 07:25:39 UTC
I have installed  MW 1.19 and tested it. This seems to no longer be the behavior. When trying to edit a page I was requested to log-in, and returned to the appropriate page I came from. log-out again and tried to saw the view source tab. log-in again and saw the the edit tab. I hope I configured it the same as brian. closing as works for me.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links