Topic on Project:Support desk

I once used an API called wfMsgWikiHtml that is now erased. This is a serious problem since deprecated APIs need to be replaced. If it's not possible to know how they operated it's not possible to replace.

https://doc.wikimedia.org/mediawiki-core/master/php/search.php?query=wfMsgWikiHtml

It now redirects to a page here with no mention of it. Perhaps it was never documented in the first place, but otherwise I don't think that I would have written code with it if I didn't see it used in other MediaWiki code that made clear its usage.

WfMsg statistics has an index of code for these, but it's not clear how to retrieve the source code marked at rev. 97412 according to the document. I found a github repository but GitHub doesn't seem to have a practical way to reference revisions.

Deprecated API is documented in the Release Notes. See Release notes/1.27 which lists "wfMsgWikiHtml() was removed (deprecated in 1.18)." You can see the previous code in the corresponding changeset at https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/262333/

see also manual:wfMessage for docs on the suggested replacement

(Obviously this isn't a good documentation system.)

Going by https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/262333/4/includes/GlobalFunctions.php I need to implement wfMsgGetKey that isn't in that change/file, nor is it explained by the wfMessage wiki page.

I originally implemented a replacement with wfMessage($key)->parse() (though the wiki page suggests parseAsBlock) but I do have one instance that breaks down when the skin does $this->html('subtitle') that displays a subpage under the main heading. When the subpage title has an apostrophe, for example, the page is cut off there ending with & as if it's converted to '

I'm upgrading so I'm not sure what to blame or if a better approximation of wfMsgWikiHtml would repair this behavior, or if it's just a breaking change. To replicate it I would need wfMsgGetKey code for the message to see. I think the problem is likely wfMessage adds '

Hello again, I'm still curious about wfMsgGetKey however if anyone can look at (Topic:Vckr289fz0jyvhkw) this is the source the parsing bug I explained.

Sorry, I should explain the link refers to Extension:Arrays that has a variable ported to use extension.json that is not formatted correctly in its JSON form.

Indeed, looking at current docs of MediaWiki, for a feature that was replaced 7 years ago, isn't going to yield much info. Older versions of the docs are probably more relevant

wfMsgGetKey() is an implementation detail of the old system. It is roughly equivalent to either wfMessage( 'msgname' )->plain() or wfMessage( 'msgname' )->text() depending on the third argument. You

It would be unusual to use ->parseAsBlock(). 99% of the time you want ->parse() not ->parseAsBlock(). The most direct equivalent to wfMsgHtml() is wfMessage( 'keyname' )->rawParams( 'parameter' )->parse(). However, rawParams is strongly discouraged as it is very easy to give yourself an XSS security vulnerability, as it does no escaping of the parameter. It is strongly encouraged to use ->params() if at all possible.

Yes, ->parse() & ->parseAsBlock() will always convert apostrophes in the message to ' I don't understand how or why this is causing a problem. If it is because you are inserting the message inside a url, you should use urlencode to ensure its properly encoded for a url. If its not because of url, what's the context that the & causes a problem?

Just fyi, to lookup old svn revision numbers, you can go to Special:Code/MediaWiki/97412. It is also included in the git notes of the git repo, although those are often not downloaded by default during a git clone.

This is why APIs should be documented and the documentation should stay up indefinitely even after removal, since old code must consult the documentation to ensure it does what it's designed to do, without guess work. Mediawiki would be much more useful if it had a deep-search function to find a term like wfMsgWikiHtml inside old versions of wiki pages.

the primary api documentation is in git. Pages on mediawiki are more like tutorials. They arent api documentation

Well, it's where no one can find it then.