Last modified: 2008-04-12 12:26:55 UTC
Wikis where the entire wiki is protected, such as
wikimediafoundation.org, should treat every page like a
protected page, to simplify the code and prevent problems
like a lack of a "view source" feature.
*** Bug 2822 has been marked as a duplicate of this bug. ***
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.
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.
*** Bug 5391 has been marked as a duplicate of this bug. ***
The bug 5391 has a suggested code change that nobody has commented on.
*** Bug 5615 has been marked as a duplicate of this bug. ***
I'm now creating a patch for this bug.
Created attachment 1562 [details]
This patch does many things. Generally (in the user interface), it does the
* 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.
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
* 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…
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.
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]]
(In reply to comment #11)
> 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.
*** Bug 7331 has been marked as a duplicate of this bug. ***
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.
This bug was fixed long ago.