after the page content and article metadata. Updated all skins and skin
templates to work with that hook.
The hook is added in the newly introduced Skin::hookAfterContent(). It
couldn't be implemented anywhere else as we want to be able using a single hook
in all skins:
Some skins are based on SkinTemplate (e.g. MonoBook), while
some directly extend the Skin class (like CologneBlue). The Skin based ones
collect their output from several functions from Skin class, while SkinTemplate
prepares an array with all the needed data and passes it to the skins using it.
Thus we had to create said new protected function for running that hook. SkinTemplate
pushes the function's output into the data array. The Skin class based skins
directly use the function's output.
Bug 14965 - https://bugzilla.wikimedia.org/show_bug.cgi?id=14965
PHP Catchable fatal error: Argument 1 passed to Title::equals() must be an instance of Title, null given, called in /usr/local/apache/common-local/php-1.5/includes/Linker.php on line 1323 and defined in /usr/local/apache/common-local/php-1.5/includes/Title.php on line 3003
$wgTitle isn't available in this sort of background rendering.
Make Linker::doEditSectionLink() public, and change its interface to be like that of editSectionLink(). Use that in Parser (which is the only place that uses the old functions that I can find), and mark the old two functions deprecated. Add a hook 'DoEditSectionLink' with a new, clean interface, which is run immediately before the return so it can override the whole function. Advise people in hooks.txt to use the new hook, not the old ones.
This passes a MovePageForm, which seems unwise. It won't apply to the edit API, and generally seems like a weak interface -- an internal UI object is passed instead of specific information, leaving it unstable to future changes.
This hook is incomplete and won't work as advertised. Will fail to run when the email address is confirmed through other means, such as a password reset; also there's no corresponding hook for when the mail gets *un*confirmed, so would lead to inconsistent state.
This hook seems pretty unclear to me. What's it meant to accomplish? It passes no data to be customized, and has no code interface for building a sustainable, forward-compatible extension from it.
This seems a bit icky and inconsistent. If it's necessary to pass titles around here, it should be done consistently, with appropriate fixups and refactoring to the old spaghetti code.
"Improving extendibility of the sidebar improvements, css adding, and also JS variables."
"* New hooks:"
"** SkinSidebarSpecialBox and SkinSidebarOutputSpecialBox to allow extensions to add new custom boxes to Tim's new Sidebar system"
"** SkinSetupSiteCss to allow extensions to modify and add new stylesheets to load into the page. This one allows for fine positioning and can be very useful for things like an extension providing global css for a wiki farm."
"** SkinGlobalVariables to allow extensions to add new global variables to export to the JS variables in the page."
At least some of these appear to duplicate existing functionality -- extensions already can add new stylesheets and JS variables, and I'm pretty sure can add portals as well.
* New hooks:
** SkinSidebarSpecialBox and SkinSidebarOutputSpecialBox to allow extensions to add new custom boxes to Tim's new Sidebar system
** SkinSetupSiteCss to allow extensions to modify and add new stylesheets to load into the page. This one allows for fine positioning and can be very useful for things like an extension providing global css for a wiki farm.
** SkinGlobalVariables to allow extensions to add new global variables to export to the JS variables in the page.
As a general rule, it would be a good idea to first split the functions off into their own file without changing them, and then refactor them in a separate commit. Otherwise it's very hard to follow what's actually being changed. (git actually tracks changes to functions when they're moved across files, incidentally, which is quite awesome.)
* Don't pass $data or $flags by reference. They're never accessed again, so it makes no sense.
* Document in hooks.txt.
The interface for this hook seems very messy. It seems like it would be much cleaner to expose $data as $url (null if stored locally); and $flags as an array, or something like that. If the text is gzipped, the text can be extracted from the Revision and re-gzipped if you really want to for some strange reason.
The hook seems a bit odd; it triggers on some of the composes, but not all. There's another loop right after this one.
Also, there's no need to pass objects as references here.
This hook allows for modification of the title and text of a template which is being transcluded.
Use of this hook will allow extensions to create features such as TransWiki for an alternative to ScaryTransclusions."
This hook seems a bit oddly placed to me; the template gets fetched locally, and *then* we give the opportunity to fetch it remotely instead? Just seems to be in the wrong order, and pretty unclear.
This hook allows for modification of the title and text of a template which is being transcluded.
Use of this hook will allow extensions to create features such as TransWiki for an alternative to ScaryTransclusions.
ExtendJSGlobalVars is probably ok in function, though I don't really like its name.
wfMessageCacheReplace seems really unclear as to what it's trying to accomplish.
This is done by adding the <moz:SearchForm> extension element with the Special:Search URL.
Removed the 24-character truncation on ShortName... neither Firefox nor IE seems to care about longer names, but both expect the ShortName and <link> title to match, and will think you have a duplicate search provider if they don't match because only one was truncated. (Besides, 24 was longer than the spec's limit of 16 -- why bother limiting at all if not to spec?)
The JSON suggestions are now no longer included in the OpenSearch description if the API is disabled, since the interface won't work.
Generally removed some hardcoded escape-then-stick-vars-in-string-output eww... Extension hooks now have a more general opportunity to alter or replace the OpenSearch URLs by tying into the OpenSearchUrls hook.
