Last modified: 2008-04-12 12:26:55 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T3859, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 1859 - No "view source" if the entire wiki is "protected" (e.g.
No "view source" if the entire wiki is "protected" (e.g. wikimediafoundation....
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
All All
: Normal enhancement with 4 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
: 2822 5391 5615 (view as bug list)
Depends on:
  Show dependency treegraph
Reported: 2005-04-10 06:09 UTC by Brian Jason Drake
Modified: 2008-04-12 12:26 UTC (History)
4 users (show)

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

Patch (15.97 KB, patch)
2006-04-17 19:46 UTC, Rotem Liss
fix not displaying "view source" if page is protected (548 bytes, patch)
2007-03-22 18:50 UTC, Gunter Schmidt

Description Brian Jason Drake 2005-04-10 06:09:26 UTC
Wikis where the entire wiki is protected, such as, should treat every page like a 
protected page, to simplify the code and prevent problems 
like a lack of a "view source" feature.
Comment 1 Brion Vibber 2005-07-12 17:39:43 UTC
*** Bug 2822 has been marked as a duplicate of this bug. ***
Comment 2 Rob Church 2005-12-14 23:18:07 UTC
Well, the entire wiki isn't protected in that case; but it's locked to anonymous
editors. Edit tabs already include a "(requires login)" 'disclaimer' which
indicates that the wiki is a little different from normal. 
Comment 3 Brian Jason Drake 2005-12-20 05:13:13 UTC
It's not protected in the sense that only one class of user can edit, but there 
are restrictions on editing that are not specific to particular users.

I was not logged in when I noticed these:

Caption: "Edit (requires login)"
Tooltip: "You can edit this page. Please use the preview button before saving."

They don't seem relevant somehow. We should just see a "view source" link, which 
points to a page with an explanation of why we can't edit.
Comment 4 Brion Vibber 2006-03-29 20:01:58 UTC
*** Bug 5391 has been marked as a duplicate of this bug. ***
Comment 5 Brian Jason Drake 2006-03-31 01:14:46 UTC
The bug 5391 has a suggested code change that nobody has commented on.
Comment 6 Brion Vibber 2006-04-17 08:31:38 UTC
*** Bug 5615 has been marked as a duplicate of this bug. ***
Comment 7 Rotem Liss 2006-04-17 16:54:25 UTC
I'm now creating a patch for this bug.
Comment 8 Rotem Liss 2006-04-17 19:46:54 UTC
Created attachment 1562 [details]

This patch does many things. Generally (in the user interface), it does the
following things:
* Always shows "view source" if the user cannot edit the page.
* If viewing source, always views the source (including the comment "you can
view the source" etc.) if the page exists (or if it is a MediaWiki system
message which was not created yet, but exists), and hides the text area and the
comment if the page does not exist.
* Makes the messages in pages you cannot edit exact, specific and uniform.
(Nowadays, for example, if we set:
$wgGroupPermissions["*"]["edit"] = false;
$wgGroupPermissions["user"]["edit"] = false;
in LocalSettings.php and a registered user tries to edit a page, he gets the
non-exact, non-specific and non-unfiorm message about "protected page". But
nobody has protected it ever. Now he gets the message "you are not allowed to
edit pages in this site", because there is nothing you can do about that (well,
he can e-mail the bureaucrat and ask a sysop authority…). However, an
anonymous user will get the message "you have to log in to edit pages", like
* Messages.php and MessagesHe.php are updated with the new messages. All of the
new messages in the other languages will appear in English, unless they update
their language file.

The technical subjects will appear in the next comment, because I'm not sure if
there is a length restriction for these comments.
Comment 9 Rotem Liss 2006-04-17 20:21:54 UTC
I forgot to mention that the patch is for the trunk, of course. I won't try to
create one for the branch. However, of course, Wikimedia sites will be updated,
because they use the trunk.

First, I want to define for this comment "read-only page" as "a page you cannot
edit him but not because the database is locked". In the messages, read-only
page is the second one (a page you cannot edit because the database is locked),
but I don't refer it here, so treat it as what I've said.

Technically, the patch does the following things (read while reading the patch
and the files I specify):
* Creates a parameter named $message to OutputPage::readOnlyPage
(includes/OutputPage.php). If the page is read-only, this parameter gets the
specified message name, instead of "protectedtext" (which is also shown if needed).
* Adds a message ("viewsourcetext") includes the second part of "protectedtext"
("you can view the source" etc.). This message becomes general (for all the
read-only pages), but it is shown only if we need it (i.e., if the source code
is shown, see the next item).
* The source code is shown (in OutputPage::readOnlyPage,
includes/OutputPage.php) only if the page is exist (or it is a MediaWiki message
which is exist): if the page is not exist, there is no need to show the message
"noarticletext" in the text area.
* Creates a new section ("read-only pages") in the messages, and moves to there
all the messages which are related to this kind of page. ("viewsource",
"viewsourcefor" and "protectedtext" were in "general errors", among errors in
the database! And other messages were in the reasonable place of "editing
page".) Most messages appear in pairs – one message for registered users (with
no suffix), one for anonymous users (with the suffix "anon"). The messages for
the anonymous suggest they will log in (except "protectedtextanon", which just
copies "protectedtext").
* The function Title::userCan (includes/Title.php) now returns false if the user
CANNOT edit by his permissions, not only by "protected page" or "protected
MediaWiki pages", etc.
* The same function now returns false if a confirmed e-mail address is needed to
edit, and the user doesn't have one.
* A new function named Title:userCanCreate (includes/Title.php) was created, to
match userCanEdit and Title:userCanMove. (Title::userCan is private, after all).
* The function EditPage::edit (includes/EditPage.php) now calls the improved
OutputPage::readOnlyPage function with the proper $message parameter, instead of
its private function (which doesn't show the source code, and "view source"
isn't shown), or even worse – OutputPage::readOnlyPage without the $message
parameter, says the page is protected.
* All of these checks in the same function (does the user have the "edit"
permission, and does he have a confirmed e-mail address if there is a need) were
moved into the "if" check of the return value of EditPage::userCanEdit().
* The check if it is a new page and the user has permissions to create it is now
using the new EditPage::userCanCreate() for checking, and the improved
OutputPage::readOnlyPage with the proper message.
To be continued…
Comment 10 Rotem Liss 2006-04-17 20:37:38 UTC
Some more things the patch does:
* Moves the "global $wgEmailConfirmToEdit" in the same function to its proper
page – just above the check if that is the problem.
* Removes late and redundant checks of the same things in EditPage::attemptSave
(includes/EditPage.php) – permissions, read-only pages because the database is
read only, etc. – because they were already done.
* Removes the private functions in the class EditPage (includes/EditPage.php),
which were replaced by OutputPage::readOnlyPage.
* Also checks if the user has the permission to create the page (if the page
isn't exist) in SkinTemplate::buildContentActionUrls
(includes/SkinTemplate.php), to decide whether to show "edit" or "view source".
Now it shows "view source" if the user tries to create  a page he has no
permission to create. Also, it shows the "view source" if the user doesn't have
the permission "edit" or didn't confirm his e-mail while it is mandatory,
because of the improvements in EditPage::userCan. (And by the way, thanks to the
reporter of Bug 5391, who suggested some of the improvements there.)
* Removes old messages, replaced with newer ones.

By the way, please note the title of the pages which tell us that we don't have
the permissions, or we have to confirm our e-mail address, was "login required
to edit" or something like that. However, nowadays it is "view source"
everywhere, because it DOES view the source, and only tells us briefly why we
cannot edit the page.

Finished the documentation! Please review and check in, thanks.
Comment 11 lɛʁi לערי ריינהארט 2006-05-08 13:16:28 UTC

If you go to
and change in the url's 'wikipedia' by 'wikimedia'
you can find various "restricted" Wikimedia Foundation wikies as.

There you can "build" url's with known parameters (some people call this hacking):

I do not know if this is an *nonissue* or not. Have no clue what to show on an
arbirary hacked url.

best regards reinhardt [[user:gangleri]]
Comment 12 Rob Church 2006-05-08 14:49:21 UTC
(In reply to comment #11)
> *note*
> If you go to
> and change in the url's 'wikipedia' by 'wikimedia'
> you can find various "restricted" Wikimedia Foundation wikies as.
> There you can "build" url's with known parameters (some people call this hacking):

I wouldn't consider it as critical, because that method still doesn't permit
creation of a user account. The interface could be tidied up a little and bounce
the user back to a page explaining that they can't create an account, but it's
not a serious security issue.

Comment 13 Brion Vibber 2006-09-15 07:38:46 UTC
*** Bug 7331 has been marked as a duplicate of this bug. ***
Comment 14 Gunter Schmidt 2007-03-22 18:50:03 UTC
Created attachment 3379 [details]
fix not displaying "view source" if page is protected

I think the user:isAllowed should be checked here, I provided a patch.
Comment 15 Rotem Liss 2008-04-12 12:26:55 UTC
This bug was fixed long ago.

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