robchur wrote:

This is intentional; checking cascade protection status is quite an expensive operation, so we avoid doing it when it's not needed, i.e. on page views - when the edit operation commences, we do a full check.

Not sure whether use of object caching would be considered effective enough to make this happen for Wikimedia sites; per default, it'd be too expensive for quite a few sites.

This is deliberate, and is done for performance reasons.

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

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

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

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

There is something about this bug that was not mentioned. If not changing the "Edit" to "View source" were the only consideration, then I can see why this resulted in WONTFIX. Another result of this bug is that the protected pages become categorized incorrectly. Here is an example:

http://en.wikipedia.org/w/index.php?title=Template:CN&redirect=no

That template shortcut should have been categorized into the "Protected redirects" category. Instead it was categorized into the "Wikipedia pages with incorrect protection templates" category. If many pages have been thusly miscategorized, then the need for a solution cannot be ignored under any circumstances.

I have a question: The following is printed in the pink warning box that tells editors that the page is protected *after* they click on "Edit"...

"This page is currently protected from editing because it is transcluded in the following page, which is protected with the "cascading" option:

• Wikipedia:Cascade-protected items (http://en.wikipedia.org/wiki/Wikipedia:Cascade-protected_items)

To suggest an edit to this page, submit an edit request on the talk page.

That warning accompanies the "CN" REDIRECT to the "Citation needed" template.

My question is... what about the "Cn" REDIRECT? (Note the lowercase "n") That redirect is also transcluded to the WP:Cascade-protected items page, but when you check the Cn REDIRECT, you find the "Source" instead of the "Edit" tab, and that REDIRECT is placed into the "Protected redirects" category, i.e., the CORRECT category. So why does the Cn REDIRECT work correctly, but the CN REDIRECT does not?

My question is... what about the "Cn" REDIRECT? (Note the lowercase "n") That
redirect is also transcluded to the WP:Cascade-protected items page, but when
you check the Cn REDIRECT, you find the "Source" instead of the "Edit" tab, and
that REDIRECT is placed into the "Protected redirects" category, i.e., the
CORRECT category. So why does the Cn REDIRECT work correctly, but the CN
REDIRECT does not?

Anomie explained to me how this happens. I still wonder, though, how this can be fixed, so that 1) the "Source" takes the place of the "Edit" tab, and 2) the redirect gets placed into the correct category, "Protected redirects", instead of being placed into a category that indicates that the redirect has been miscategorized?

So, initially I was told that this had to be fixed at the "software level":

http://en.wikipedia.org/wiki/Template_talk:Citation_needed#Protected_shortcut_redirects

Is the previous "WONTFIX" actually a wontfix, a cantfix or what? Is the only solution for a WP admin to go in and "doubly" protect a page that is already cascade protected? The following redirect:

http://en.wikipedia.org/w/index.php?title=Template:CN&redirect=no

... is still miscategorized and still shows "Edit" where it should show "View source". Is there or is there not a solution to this problem?

I see where the CN shortcut no longer shows "Edit" where "View source" should be, and it is now correctly categorized. Is this because this bug has been fixed? or because someone went ahead and doubly protected the shortcut?

(In reply to comment #11)

I see where the CN shortcut no longer shows "Edit" where "View source" should
be, and it is now correctly categorized. Is this because this bug has been
fixed? or because someone went ahead and doubly protected the shortcut?

Never mind, as I see it's been doubly protected, both manually and by cascade.

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

See "edit" tab on https://commons.wikimedia.org/wiki/Template:Delete/layout

Is this task still relevant? Has anything changed since T13700#160255 ?

This issue was just reported at https://commons.wikimedia.org/wiki/Commons:Village_pump/Technical#appearently_the_featured_pictures_are_protected_but_appearently_still_have_the_%22edit%22_tab. 13 years after 1st report.

I'm not very much into the PHP source of mediawiki, but maybe it is possible to change the logic of those inherited protections work. Maybe it can be done in that way that just system will be automatically protecting pages contained on page with this kind of protection. The same protection operation as user does but done automatically. With creating registry record. By doing this the normal fast rights check will be suitable as is happening with rest pages. System will be just copying settings for the most restrictive protection in a chain into all daughter pages while embedding edit is made and roll baking to previous settings while removed. There are not many pages with his kind of protection, so, this mechanism shouldn't cause performance issues. This is followup to discussion from T342508. Thank you for merge @Umherirrender.
Registry could look like this with automatic user rights: