Behavior seems a bit hard to predict, as far as what's going to go in the header and what in the browser window etc. Pulling it back for further testing and discussion.
* Use wfMsg to show error message in user preference language. wfMsgForContent does not make sense
* Rename new message name to MediaWiki code standards. Use dash and not underscore
I don't really like this in general; the API isn't meant for the UI and there should be little to no call to link to it from body content.
Additionally, I believe we're trying to move all new parser functions to the convention of using the # prefix to avoid conflict with the template namespace.
This implements an mb_str_pad fallback function, but there is no mb_str_pad in PHP documentation, and the doc comments are really weird -- it says it returns an integer!
If this function is created from whole cloth and doesn't exist in PHP, it should be given a MediaWiki style name and not be done with a function_exists check as though it were a compat function.
* Wrote a tool to check the integrity of the autoloader class list, fixed some issues that came up.
* Start the autoloader before LocalSettings.php, so that when an extension writer thinks an inefficient one-file special page extension is the way to go, they don't have to use explicit includes to make the class inheritance work. Should continue to work with $IP set in LocalSettings.php as long as $IP is set before extensions are included.
2008-06-16 20:21:26 +00:00
Renamed from includes/CoreParserFunctions.php (Browse further)
