Last modified: 2008-09-05 22:59:31 UTC
Created attachment 3766 [details] proposed patch I made a patch that adds last protection log entry to edit page. The entire log is not needed because it will be too long for heavily-vandalized pages.
Working off logs isn't the best approach here; the reason shown should be taken out of the protection table directly. Showing log fragments without any explanation on the edit page is not a good idea; I'm also wary of complicating Article::showLogFragment().
(In reply to comment #1) > Working off logs isn't the best approach here; the reason shown should be taken > out of the protection table directly. > > Showing log fragments without any explanation on the edit page is not a good > idea; I'm also wary of complicating Article::showLogFragment(). > Perhaps you're schema change could add pr_reason. That would really help out SP:ProtectedPages. Currently I use a JS to scrap of the logs when checking it.
(In reply to comment #2) > Perhaps you're schema change could add pr_reason. That would really help out Yes, I was thinking of that.
It might not make sense to take only the last as the reason. It's not uncommon to have multiple consecutive protections that tweak the level up or down. If pr_reason is added, perhaps it would be best to change the log message box to be prefilled with the existing comment, or have a separate box for it, or something. Otherwise you'll get a fair number of pr_reasons like "forgot move protection" that don't really explain things by themselves, even though they're completely suitable as *log* comments. Repurposing log comments for pr_reason is sort of messy.
Perhaps a good link to protection log for the page will do for now.
Done in r40509
