Last modified: 2013-07-03 17:00:44 UTC
It should be possible to modify page properties on a per-page basis via a user interface in MediaWiki. This should include logging for each change (particularly to enable easy reversion in case of vandalism). --- I don't believe this already has a bug. Since <https://github.com/wikimedia/mediawiki-core/commit/269a91037b7e47e92197fed5c3a16ecc2567f4e3>[1] we have a page_props table for page properties on a per-page basis. And since Ia1878588f718e99756caf23ae9c5a131eb70bf12 we have a re-implemented info action that exposes page properties for a particular page. And since Ib0d4e17f22b8d0cb9894eac6095962315480e809, you can list pages via a Special page that have a particular page property. But as far as I'm aware, there's no user interface currently to control, for example, whether a page should use LiquidThreads. Or what a page's default sort key should be. There are a few ways to add or remove page properties currently, but they usually involve awkwardly editing the page text of the page in question (using {{#UseLiquidThreads:1}} or {{DEFAULTSORT:}} or whatever). This isn't great and could definitely be improved with a proper interface. [1] Is there another revision view I could/should be using here? Using GitHub feels strange.
(In reply to comment #0) > [1] Is there another revision view I could/should be using here? Using GitHub > feels strange. Using the hashes directly should work fine as we configured bugzilla to auto-link those. Though we currently only forward to Gerrit, which is the only way we can have it link to any repository. The downside is that Gerrit doesn't have the full index. git.wikimedia.org is the replacement of gerrit.wikimedia.org/r/gitweb (which is now 404).
(In reply to comment #1) > git.wikimedia.org is the replacement of gerrit.wikimedia.org/r/gitweb (which > is now 404). I tried git.wikimedia.org, but anywhere I put "269a91037b7e47e92197fed5c3a16ecc2567f4e3" didn't seem to actually find the appropriate revision. I also tried to find a way to easily map "269a91037b7e47e92197fed5c3a16ecc2567f4e3" to [[mw:Special:Code]], but even just getting the timestamp out of GitHub was surprisingly difficult (I could only find "5 years ago").
While I think this would be a good idea, how do you plan to handle conflicts between the parsed text (with stuff like {{DEFAULTSORT:abc}} etc.) and information set by the user interface? It would be really confusing to have DEFAULTSORT in page source but it to not actually apply because someone has overridden it through another method (the page properties UI). This would've been nice to have when page_props was first introduced (in 1.13 I guess, maybe the parser functions are older), but now the existing flags set by the parsed text are going to be difficult to remove.
(In reply to comment #2) > I also tried to find a way to easily map > "269a91037b7e47e92197fed5c3a16ecc2567f4e3" to [[mw:Special:Code]], but even > just getting the timestamp out of GitHub was surprisingly difficult (I could > only find "5 years ago"). They are mapped in git commit notes. You can get them locally with this command: git fetch gerrit refs/notes/commits:refs/notes/commits They will be then shown in `git log`, `git show` etc., as well as some GUI viewers (gitk supports them, dunno about other). They are also shown in GitBlit, for example here: https://git.wikimedia.org/commit/mediawiki%2Fcore.git/269a91037b7e47e92197fed5c3a16ecc2567f4e3 And that commit hash should be autolinked, I wonder why it isn't above. 269a91037b7e47e92197fed5c3a16ecc2567f4e3
(The notes feature is documented at https://www.mediawiki.org/wiki/Gerrit/Advanced_usage#Code_Review_links .)
