One use case I'd like to see supported is for organisational profiles to be able to have rel="me" as well. For example, a Contact page on a wiki should be able to link with [https://social.example.org/@account @firstname.lastname@example.org] and have it get the rel attribute. I guess these site-wide URLs would be defined in LocalSettings.php.
- Mentioned In
- T341085: Verify @email@example.com
rERAMc4d27da34831: extension.json: Bump required MW version
rERAMce31154771e5: Support non-user pages through MediaWiki:realme-config.json
rERAMdaffe0b9eec8: Support non-user pages through MediaWiki:realme-config.json
rERAM9725554a9b3c: Support non-user pages through MediaWiki:realme-config.json
T322717: Allow Wikimedians to verify their Mastodon profile with rel="me"
So this is kind of what I tried in https://www.mediawiki.org/wiki/Extension:RelMicroformat, except I only implemented it for the sidebar.
That said, do you really want the link to have rel=me sitewide? Would you be fine with just specific pages?
$wgRealMeLinks = [ 'https://social.example.org/@account' => [ 'Contact', 'Main_Page' ], ];
When you mentioned this initially, I was thinking of stuff like https://wikis.world/@wikisignpost linking to https://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost - but you wouldn't want that to have rel=me on every page that links to the Signpost.
You're quite right. It shouldn't be necessary to have rel=me on every link, and certainly it wouldn't be good to mix it with links on user pages. I like your suggestion of a map for the config.
Regarding the sidebar links, it'd presumably be problematic if they are given rel=me when viewing user pages which also have their own rel=me links.
I spent a while going back and forth on whether this should be a sysadmin-level config setting or just a on-wiki admin wiki page. I settled on the latter because 1) expecting sysadmins to manually approve/check each account to verify patches doesn't scale and seems like a giant waste of time and 2) in the theoretical case of a rogue admin trying to hijack or misrepresent something...they could just hijack the wiki page itself. Possibly this is a bit more subtle way of doing so, but that seems to be at the appropriate level of things we trust admins with.
Other things I noted in the commit message:
- URLs are validated pre-save using the same validity and protocol checks as Special:Preferences
- This does not require the link be used on the wiki page
- It cannot be used on User/User talk pages
Unfortunately, I forgot to test on 1.39, and it's no longer compatible:
TypeError: Argument 1 passed to MediaWiki\Extension\RealMe\Hooks::getLinksFromConfig() must be an instance of MediaWiki\Title\Title, instance of Title given, called in /var/www/mediawiki/extensions/RealMe/src/Hooks.php on line 223
Tests unbroken on REL1_39, features in master backported to REL1_39 and REL1_40.
As per https://www.mediawiki.org/wiki/Extension:RealMe, the relevant branch should be used with the corresponding MW core branch
Snapshots releases along with MediaWiki. Master is not backward compatible.
The requires in extension.json still needs bumping (patch above), as the tests in master won't pass on the apparent supported version...