Last modified: 2011-07-24 11:41:33 UTC
Since before March 22, images on the main page for the English Wikipedia are not automatically getting protected by cascading protection. The "Did You Know" admins like myself know to protect all images, but other images on the main page have been vandalized. Discussions can be found at: http://en.wikipedia.org/wiki/Wikipedia:ERRORS#Protection http://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Archive_58#Main_page_cascading_protection_not_working
Most likely because they are on commons.
Updated summary
Commons images have always a problem, that's why a temporary local copy is downloaded from Commons. The problem is with unprotected images that reside on the English Wikipedia. Here's the deleted history from an image that was vandalized while on the main page: http://en.wikipedia.org/wiki/Special:Undelete/File:Lyon0002soft.JPG (admin powers on English Wikipedia needed to view). The vandalism happened from vandal editor The O o . For a long time, all images on the English Wikipedia were automatically protected by cascading protection. Now it's not working anymore. I've tested it myself. The typical all-pink screen for a protected image doesn't come up anymore after the image gets placed on the main page. Non-admin DYK helper Shubinator tested another image here and found no protection: http://en.wikipedia.org/wiki/Special:Undelete/File:Sloat_House,_Sloatsburg,_NY.jpg . This is a serious problem that needs to be addressed. Royalbroil
(In reply to comment #3) > Commons images have always a problem, that's why a temporary local copy is > downloaded from Commons. The problem is with unprotected images that reside on > the English Wikipedia. Here's the deleted history from an image that was > vandalized while on the main page: > http://en.wikipedia.org/wiki/Special:Undelete/File:Lyon0002soft.JPG (admin > powers on English Wikipedia needed to view). The vandalism happened from vandal > editor The O o . For a long time, all images on the English Wikipedia were > automatically protected by cascading protection. Now it's not working anymore. > I've tested it myself. The typical all-pink screen for a protected image > doesn't come up anymore after the image gets placed on the main page. Non-admin > DYK helper Shubinator tested another image here and found no protection: > http://en.wikipedia.org/wiki/Special:Undelete/File:Sloat_House,_Sloatsburg,_NY.jpg > . This is a serious problem that needs to be addressed. Royalbroil WFM at http://test.wikipedia.org/w/index.php?title=File:Testimage.png&action=edit
You have changed the description to describe a different problem than what I'm reporting. I concern is LOCAL images on the English Wikipedia that should be automatically protected by cascading protection while on the main page but are not being protected. Admins like myself are having to manually protect them so that they don't get vandalized. Protecting images on the Commons shared image repository protection is NOT the issue that I'm bringing up. That's a separate problem that would be a helpful improvement, but it's beyond the scope of the bug that I've brought up. Cascading protection worked back in January, I don't know what changed so that it doesn't work anymore.
(In reply to comment #5) > You have changed the description to describe a different problem than what I'm > reporting. I concern is LOCAL images on the English Wikipedia that should be > automatically protected by cascading protection while on the main page but are > not being protected. Admins like myself are having to manually protect them so > that they don't get vandalized. Protecting images on the Commons shared image > repository protection is NOT the issue that I'm bringing up. That's a separate > problem that would be a helpful improvement, but it's beyond the scope of the > bug that I've brought up. Cascading protection worked back in January, I don't > know what changed so that it doesn't work anymore. > That's what I'm telling you, though. Local cascading protection *is* working, and I haven't seen a scrap of evidence to the contrary. See http://en.wikipedia.org/w/index.php?title=File:Example.jpg&action=edit, an image that is clearly protected by cascading protection. See also these images on the main page, which are protected using cascading protection and it's working (but two of which have not been reuploaded to English Wikipedia, and are therefore vulnerable to vandalism: http://en.wikipedia.org/w/index.php?title=File:Niobium_crystals_1.jpg&action=edit http://en.wikipedia.org/w/index.php?title=File:Po%C5%BCar_w_Kamieniu_Pomorskim_13.04.2009_16_cropped.jpg&action=edit http://en.wikipedia.org/w/index.php?title=File:FillmoreHouse.jpg&action=edit http://en.wikipedia.org/w/index.php?title=File:Harriet_quimby.jpg&action=edit http://en.wikipedia.org/w/index.php?title=File:Darnley_stage_3.jpg&action=edit
Of those images, only File:Darnley stage 3.jpg is actually protected by cascading protection! Two of the images were manually protected. The other two images are Commons images that are not protected (SHAME - that's scary!). Otherwise, is there a delay before cascading protection takes over? Several months ago there used to be no delay. I've tested several images after I've updated the DYK template, and I've theoretically always been able to vandalize the image immediately after I've updated the Did You Know DYK template and purged the main page cache.
(In reply to comment #7) > Of those images, only File:Darnley stage 3.jpg is actually protected by > cascading protection! Two of the images were manually protected. The other two > images are Commons images that are not protected (SHAME - that's scary!). > Otherwise, is there a delay before cascading protection takes over? Several > months ago there used to be no delay. I've tested several images after I've > updated the DYK template, and I've theoretically always been able to vandalize > the image immediately after I've updated the Did You Know DYK template and > purged the main page cache. I think it's on your end. For me, I get the following: Editing File:Niobium crystals 1.jpg WARNING: This page has been protected so that only administrators can edit it because it is transcluded in the following pages (which are protected with the "cascading" option enabled). Please ensure that you are following the protection policy. * Wikipedia:Main Page/1 * Wikipedia:Main Page/2 * Wikipedia:Main Page/3 * Wikipedia:Main Page/4 * Wikipedia:Main Page/5 * Main Page * Wikipedia:Main Page/Protection Editing File:Pożar w Kamieniu Pomorskim 13.04.2009 16 cropped.jpg WARNING: This page has been protected so that only administrators can edit it because it is transcluded in the following pages (which are protected with the "cascading" option enabled). Please ensure that you are following the protection policy. * Wikipedia:Main Page/Tomorrow * Wikipedia:Main Page/1 * Wikipedia:Main Page/2 * Wikipedia:Main Page/3 * Wikipedia:Main Page/4 * Wikipedia:Main Page/5 * Main Page Editing File:FillmoreHouse.jpg WARNING: This page has been protected so that only administrators can edit it because it is transcluded in the following pages (which are protected with the "cascading" option enabled). Please ensure that you are following the protection policy. * Wikipedia:Main Page/1 * Wikipedia:Main Page/2 * Wikipedia:Main Page/3 * Wikipedia:Main Page/4 * Wikipedia:Main Page/5 * Main Page Editing File:Harriet quimby.jpg WARNING: This page has been protected so that only administrators can edit it because it is transcluded in the following pages (which are protected with the "cascading" option enabled). Please ensure that you are following the protection policy. * Wikipedia:Main Page/1 * Wikipedia:Main Page/2 * Wikipedia:Main Page/3 * Wikipedia:Main Page/4 * Wikipedia:Main Page/5 * Main Page Editing File:Darnley stage 3.jpg WARNING: This page has been protected so that only administrators can edit it because it is transcluded in the following pages (which are protected with the "cascading" option enabled). Please ensure that you are following the protection policy. * Wikipedia:Main Page/1 * Wikipedia:Main Page/2 * Wikipedia:Main Page/3 * Wikipedia:Main Page/4 * Wikipedia:Main Page/5 * Main Page
You are correct - it appears that the problem is sporadic. Even a sporadic problem of this magnitude needs to be addressed. There have been some problems, as I have indicated above. I have started a thread asking the Did You Know people to test this problem and leave messages here. I don't know how many have access to Bugzilla. Anyhow, you can follow the thread here: http://en.wikipedia.org/wiki/Wikipedia_talk:Did_you_know#Sporadic_problems_with_cascading_protection_on_main_page_images
Perhaps too obvious, but... You did clear your browser cache, right?
Can this have to do with the job queue? Depending on the length of the job queue it takes some time before the link tables are updated after a template is changed. And before the image links from the main page are updated in the imagelink table, the cascade protection protects the "old image" instead of the "current image".
Lejonel, that makes sense. I've noticed that it often takes tens of minutes for the links to the previous image to be released. I've already deleted an image that exists as the temporary local English Wikipedia image from the main page, just to find the the MPUploadbot has uploaded this same old image back because it thought that the old image was still on the main page. Can you change the priority of the task in the job queue so that it updates the imagelink table within a few seconds instead of tens of minutes?
5 minutes ago I posted an update to Did You Know, and I left the local image unprotected. I put up a template to make it look like it's protected. It's still not protected. The image is http://en.wikipedia.org/wiki/File:Hmserebus1826.jpg . See for yourself. You can edit the image.
I used my alternative non-admin account to successfully do a null edit 22 minutes after inserting on main page http://en.wikipedia.org/w/index.php?title=File:Hmserebus1826.jpg&diff=284594901&oldid=284593053 .
I asked a trustworthy non-admin make another null edit 40 minutes later to test to see if it's my browser cache, RFD had no problems! This edit could have been someone uploading a picture of their penis! http://en.wikipedia.org/w/index.php?title=File:Hmserebus1826.jpg&diff=284596826&oldid=284594901
Still not protected, 2 hours later
(In reply to comment #16) > Still not protected, 2 hours later There isn't a need for a running commentary. It is known that cascading protection takes a while to take effect due to deferred updates. I was under the impression that we solved this by having a 24-hour buffer for it to take effect, by virtue of [[Wikipedia:Main Page/Tomorrow]]. If this isn't working with "Did You Know?", then I would recommend manual protection.
(In reply to comment #16) > Still not protected, 2 hours later The file is protected, just the edit tab isn't changing to "View Source", it chucks up the following error message saying it is protected when you try to save: >This page is currently protected from editing because it is transcluded in the following page, which is protected with the "cascading" option: >* Main Page
The Tomorrow template includes only the current version of Did You Know, it gets manually updated every 6 hours or so. The tomorrow solution sounds like it works for Picture of the Day and Today's Featured Article. Tomorrow explains why only Did You Know and In the News images have been vandalized. I don't have any suggestions for In the News, but I do have one for Did You Know. There are 6 staging queues where hooks and images get placed by administrators before they appear on the main page. They could be placed under a template with cascading protection, similar to Tommorrow. There's still the problem of In the News. What fixed the problem? The image hadn't been protected at 2 hours, I cleared my browser cache and the page's cache before clicking edit on the image and it wasn't protected - the error message that p858snake mentioned wasn't there until after your posts. I didn't trust the "view source" tab. Did you clear the main page cache, Andrew? If so, I wonder, could a task be set up on a server to clear the main page cache every minute? Would that result in a performance hit, or would a single minor task like that result in a negligible performance degradation? Even a documented 40 minutes of having an unprotected image on the main page of the English Wikipedia is too scary for me. Sorry to be a pain. I was hoping that this unannounced and unadvertised test would help solve the bug. This can wait until after the weekend.
(In reply to comment #19) > What fixed the problem? The image hadn't been protected at 2 hours, I cleared > my browser cache and the page's cache before clicking edit on the image and it > wasn't protected - the error message that p858snake mentioned wasn't there > until after your posts. I didn't trust the "view source" tab. Did you clear the > main page cache, Andrew? If so, I wonder, could a task be set up on a server to > clear the main page cache every minute? Would that result in a performance hit, > or would a single minor task like that result in a negligible performance > degradation? Even a documented 40 minutes of having an unprotected image on the > main page of the English Wikipedia is too scary for me. Just time, the deferred updates got through. > Sorry to be a pain. I was hoping that this unannounced and unadvertised test > would help solve the bug. This can wait until after the weekend. No problem.
Would it be possible to update the link tables when the template is purged? -Shubinator (for the record, the same Shubinator that Royalbroil mentioned)
reverted summary since bug changed focus again to original issue
It seems that the issue is that the linktable updates that trigger cascading protection run through the job queue and are thus potentially delayed if the job queue is long. The solution, therefore, is to ensure that the templatelinks and imagelinks tables are updated quickly after a cascade-protected page is updated. IIRC someone (Tim?) is working on an improved job queue construction; as suggested in comment#12, a 'priority stream' should be considered in that system. In the meantime (and perhaps even regardless), it would seem to be sensible to update these tables *immediately* as part of the page save, if the page is cascade-protected. Since only admins can save cascade-protected pages, this whould not be a DoS vector.
Is there any progress on the bug? Happymelon's suggestion seems perfect. As I understand it, saving the page updates the link tables for only that page. For cascading protection, this means admins have to null edit (purge doesn't work) the Main Page. We could extend this so if (cascade protected) -> update link tables of that page -> propagate link table updates upwards in the chain of cascading protection. So in our example, updating Template:Did you know would update the link tables of the Main Page, which would trigger cascading protection instantaneously.
(In reply to comment #23) > It seems that the issue is that the linktable updates that trigger cascading > protection run through the job queue and are thus potentially delayed if the > job queue is long. The solution, therefore, is to ensure that the > templatelinks and imagelinks tables are updated quickly after a > cascade-protected page is updated. > > IIRC someone (Tim?) is working on an improved job queue construction; as > suggested in comment#12, a 'priority stream' should be considered in that > system. In the meantime (and perhaps even regardless), it would seem to be > sensible to update these tables *immediately* as part of the page save, if the > page is cascade-protected. Since only admins can save cascade-protected pages, > this whould not be a DoS vector. Requires serious rearchitecture, which is not justified by a minor problem for which a basic workaround exists.
Cascading protection takes time to take effect. Updating the bug summary to that effect, and since we know that, and per Andrew, a very simple workaround exists, this is going to be WONTFIX.
