robchur wrote:

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.

robchur wrote:

(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.

ayg wrote:

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