Page MenuHomePhabricator

Should protection status indicators be handled by MediaWiki core (vs. templates)?
Open, LowestPublic

Description

Description:

The current practice for protecting a page is to:

  1. change the status to protected via the protection form
  2. add a protection template to the page

The purpose of this task is to discuss and decide if MediaWiki should automatically add some similar/equivalent notice to the page (rather than an editor adding a protection template to the page manually).

Indicators already present

  • Wikibase displays an indicator today on pages with structured data (Q, P, L spaces on Wikidata, all images on Commons with/including SDC)
  • "View source" rather than "Edit" for other pages
Tradeoffs

Downsides of editors adding templates manually:

  • Requires extra editor attention
    • Either an editor needs to add/remove or the project needs to spin up a bot; neither scale
    • Without attention, protection status of the page is not accurately reflected in an obvious way (besides the current indication, see "already present" above)
  • Adds two extra edits to a page's history (one when the page is protected to add the template, and a second one, after the protection expires, to remove it) in addition to the protection revision history lines
  • When added to a template, requires all transclusions to update
  • Clutters source
  • Inconsistent behavior across wikis causes confusion
  • A common pattern for admins on English Wikipedia: a page is protected with Twinkle, automatically adding the template, but the page needs to be further reverted to remove vandalism, requiring another edit to re-add the template again

[➕ please feel free to add more here]

Downsides of MediaWiki adding notices automatically:
[➕ please feel free to add more here]


See Also:

Details

Reference
bz10347

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes

(In reply to comment #10)

What about wikis with different protection types? On one of my wiki's we had
protection for other actions as well. Supporting just edit and move makes it
unusuable by customised wikis.

For that case, it will just say (This page is protected), which is what it did pre-commit.

Not to mention, raw canonical rights were being inputted into to wfMsg(), which is funky anyway. And I don't want this getting to messy.

Getting it to list each restricted 'right' and who can do it would be a bit of a mess. The message would end up in some [x=a,b:y=c] format or worse, and rights for actions/custom actions may not have corresponding UI messages. e.g. 'protect' or 'emailthispage' will show up as 'protect' or 'emailthispage', even in non-English langauges.

I suppose the 'this page is protected' could like to the action=protect URL so the user can see the levels.

I'm worried this is UI clutter at the moment. For a move-protected page this spits out *to every reader* the unnecessary details that:

(This page is protected. Some users (anyone) can still edit it while others (Sysops) can move it.)

It's not a very attractive message, and the information's going to be pretty useless for most people. If you have move permissions, you'll already be able to see that you can't move it, while if you don't you probably don't care.

I'd recommend taking this back out for the time being and thinking a bit more about how this kind of information should be presented, when, and where.

cannon.danielc wrote:

(In reply to comment #13)

I'm worried this is UI clutter at the moment. For a move-protected page this
spits out *to every reader* the unnecessary details that:

(This page is protected. Some users (anyone) can still edit it while others
(Sysops) can move it.)

It's not a very attractive message, and the information's going to be pretty
useless for most people. If you have move permissions, you'll already be able
to see that you can't move it, while if you don't you probably don't care.

I'd recommend taking this back out for the time being and thinking a bit more
about how this kind of information should be presented, when, and where.

I agree entirely. I think a far more subtle message needs to be used. With my initial commit I indicated that it could use a bit more subtlety, and it's now become even more in-your-face :). My suggestions would be either that the message be a) blank, but taking the two params, such that wikis can choose to customize the message as the need, b) a simple and small icon of some kind, displayed in a logical place that won't break local layouts, or c) a different display of the edit tab for users who can edit the article -- something to the effect of "edit (protected)" -- while users who can't edit/move the article will just see the standard "view source" tab. In any case, please don't sync this up on Wikimedia until it's a bit more figured out :)

Maybe it should just be conveying info about edit rights?

Still, we does use huge ass ugly move-protect templates sometimes ;)

Reverted a bunch of stuff in r25210. I'd recommend fiddling with this in a branch or patch for the moment.

Could we have classes "editprotected", "moveprotected", "editsemiprotected" and "movesemiprotected" added to <body>'s list of classes?

That would allow marking of (semi)protected pages on CSS basis as well.

These categories are fluid; there may be more or fewer available protection levels on any given wiki. There's no hard-and-fast rule as to what "semi-protected" means, for instance; that's what's informally used to refer to a page which has protection set at the autoconfirmed level on Wikimedia wikis, where the available levels are for all, autoconfirmed, and sysop.

How about adding it in more general way then, such as edit-<protectionlevel> and move-<protectionlevel> where protectionlevel would be the keyword such as autoconfirmed, sysop etc.?

I'd recommend it just say "this page is protected". And 'protected' would be a blue link to &action=protect (which all users can see).

cannon.danielc wrote:

(In reply to comment #20)

I'd recommend it just say "this page is protected". And 'protected' would be a
blue link to &action=protect (which all users can see).

What if we simply it a step further and simply provide an alternative to MediaWiki:Edit and MediaWiki:Move for when the page is edit- and move-protected, respectively. For instance, if the page is semi-protected or full protected, a user or sysop viewing the page would just see "edit (protected)" in place of the normal text on the edit tab, or "move (protected)" on the move tab. Let me tinker a bit ...

cannon.danielc wrote:

Add edit-protected and move-protected messages.

Perhaps something along these lines?

Attached:

cannon.danielc wrote:

Add edit-protected and move-protected messages.

Perhaps something along these lines?

Attached:

Longer tab names = bad, we already have enough ;)

The subtitle is just annoying and disruptive, IMHO. It doesn't seem worth it... I'm reverting in r42664 and marking this bug WONTFIX. If somebody comes up with some good UI models we might reconsider it.

herd wrote:

*** Bug 16649 has been marked as a duplicate of this bug. ***

Given the introduction of [[mw:Help:Page status indicators]], I believe this can now be implemented, deprecating scripts such as these

(In reply to Helder from comment #28)

Given the introduction of [[mw:Help:Page status indicators]], I believe this
can now be implemented, deprecating scripts such as these

Yes, but the concept is that these will be done per-wiki (or perhaps per farm), and not in MediaWiki itself. Consequently should this be tracked here?

Is the way forward then to create a separate extension that does this and enable it on Wikimedia wikis?

He7d3r added a project: JavaScript.
He7d3r set Security to None.

Is the way forward then to create a separate extension that does this and enable it on Wikimedia wikis?

I suppose this is what this task is about. Then JavaScript would not apply.

Is there a way we could implement this by default, and still allow the wiki to override ?
I actually find it a bit of a shame that we don't use indicators unless implemented by a wiki. I mean if you download the software, I expect that to just work, without any interference from a template author..

We could add a switch to render some by default, enabled by default in core and disable on wmf properties perhaps ?

We could. If we use the indicator system from T25796 for this, and use an indicator name that is also valid in <indicator> (I don't think we disallow any :P), and add our indicator with OutputPage::setIndicators() before the ParserOutput is added – then the indicator could naturally be overridden/hidden from wikitext.

This task was proposed in the Community-Wishlist-Survey-2016 and in its current state needs owner. Wikimedia is participating in Google Summer of Code 2017 and Outreachy Round 14. To the subscribers -- would this task or a portion of it be a good fit for either of these programs? If so, would you be willing to help mentor this project? Remember, each outreach project requires a minimum of one primary mentor, and co-mentor.
Jdlrobson added a subscriber: Jdlrobson.

@TheDJ or @matmarex do you know the current state of this one? Will see what I can do if still open since we're about to look at indicators in the desktop improvements project.

It seems free for taking to me. I suggested earlier using the indicator system:

We could. If we use the indicator system from T25796 for this, and use an indicator name that is also valid in <indicator> (I don't think we disallow any :P), and add our indicator with OutputPage::setIndicators() before the ParserOutput is added – then the indicator could naturally be overridden/hidden from wikitext.

It seems free for taking to me. I suggested earlier using the indicator system:

We could. If we use the indicator system from T25796 for this, and use an indicator name that is also valid in <indicator> (I don't think we disallow any :P), and add our indicator with OutputPage::setIndicators() before the ParserOutput is added – then the indicator could naturally be overridden/hidden from wikitext.

Given we show a locked icon next to edit on mobile that would perhaps be a little confusing when we finally render indicators on mobile.
Paging @alexhollender - how do we plan to visually tell somebody a page is protected on desktop?

Given we show a locked icon next to edit on mobile that would perhaps be a little confusing when we finally render indicators on mobile.
Paging @alexhollender - how do we plan to visually tell somebody a page is protected on desktop?

As far as I know we're not planning any changes regarding page indicators aside from moving them slightly. People currently can see that a page is protected from the icons editors place on the page. cc @ovasileva

just remembering that we did have an aspirational idea early on that we would communicate whether or not a page is locked/protected within the Edit button (similar to what we do in Minerva)

I feel like communicating that within the edit button makes more sense than adding an additional indicator for it

just remembering that we did have an aspirational idea early on that we would communicate whether or not a page is locked/protected within the Edit button (similar to what we do in Minerva)

I feel like communicating that within the edit button makes more sense than adding an additional indicator for it

That unfortunately wouldn't work for the entity pages on Wikidata since they don't have a global edit button but instead a lot of edit links for each statement, etc.

Can someone please clarify what the purpose/proposal of this task is? Otherwise I think we should close it given it was filed in 2007 and there has been little discussion on it since then.

  • The title of this task is Add page indicator to show that the page being viewed is protected. As far as I am aware we already do this, and have no planned changes.
  • Some comments mention adding text / additional elements to indicate the page is protected. Why is this necessary? I agree with T12347#150059

Can someone please clarify what the purpose/proposal of this task is? Otherwise I think we should close it given it was filed in 2007 and there has been little discussion on it since then.

  • The title of this task is Add page indicator to show that the page being viewed is protected. As far as I am aware we already do this, and have no planned changes.

MediaWiki core has not and does not indicate protection status visibly besides the subtle lack of an edit button, or "view source" rather than "edit". Subsequently, many/most wikis have templates and modules providing that classic lock icon for what is seen to be as a deficiency.

I suspect the reason it has not been commented on is because fixing it is taken to be a given. I'm sure I can go onwiki and ask users to leave feedback, but I expect that would be a bunch of +1s rather than meaningful feedback. Your conclusion that it means something that the task hasn't seen a comment and thus it should be closed is unsupported.

It is not reader-friendly to be lacking the less-subtle cue, or i18n friendly for every wiki to implement this on its own, or external MediaWiki users to require the same as each editor, and can lead to "non-standard" appearance and editor/MediaWiki user annoyance that to provide this icon they may need to do it themselves or via a bot, changing the page content to emit a lock. (Which is dumb.) Which you seem to understand is what happens. The point of the task is ultimately to make it appear automatically as a result of the protection itself rather than require editor or bot workaround.

@Izno thanks for the clarification. If I am understanding your comment correctly it seems like the main issue here is the technical method with which indicators/notices appear on pages, rather than the visual presentation of those indicators/notices. Is that correct? If so, would you be willing to update the task title and description to clarify that this is about making a technical change, rather than a visual change? It might also be appropriate to open a related task regarding the visual appearance (ie I think it would be better to discuss in a separate task).

@Izno thanks for the clarification. If I am understanding your comment correctly it seems like the main issue here is the technical method with which indicators/notices appear on pages, rather than the visual presentation of those indicators/notices. Is that correct? If so, would you be willing to update the task title and description to clarify that this is about making a technical change, rather than a visual change? It might also be appropriate to open a related task regarding the visual appearance (ie I think it would be better to discuss in a separate task).

Well, as you can pointed out, the change was previously reverted for aesthetic reasons, so I don't think this task will close before the aesthetics are sorted. If you want the related task to block, I can reorganize stuff, but that seems like just enough effort to decline on my part until then. :^)

alexhollender renamed this task from Add page indicator to show that the page being viewed is protected to Should porotection status be handled by MediaWiki core (vs. templates)?.Tue, Mar 30, 2:43 PM
alexhollender renamed this task from Should porotection status be handled by MediaWiki core (vs. templates)? to Should protection status indicators be handled by MediaWiki core (vs. templates)?.
alexhollender updated the task description. (Show Details)
Dinoguy1000 added a subscriber: Dinoguy1000.

I boldly added a couple downsides for the manual approach; please remove if that was inappropriate, since I don't know if there's some extra etiquette here or anything.

Earwig updated the task description. (Show Details)