-- Introduce tagging of individual changes (revisions, logs, and on recentchanges). The tags are customisable, and currently settable by the Abuse Filter and by the TorBlock extension. The tags can be styled on the various pages on which they appear.
-- Introduces a schema change, three new tables (valid_tag, change_tag, and tag_summary).
* Therefore added a hook to catch them from an extension (successfully tested with the cldr extension (see next commit))
* Add a title tag to the interlanguage box entries. Only added when the title differ from the shwon text.
No change of behaviour until an extension is enabled.
Removing SpecialListusersGetGroups hook completely, and changing the
UsersPager::getGroups function to use User::getEffectiveGroups instead
of directly making a DB query itself.
something, before it was using $addable and $removable which are not used in
the showEditUserGroupsForm function since r32610, now it uses $groups instead.
* Changed a $user->getGroups call in showEditUserGroupsForm to use $groups
instead, the function is passed $groups, which is supposed to be an array of
groups the user is in, so no point in getting the array again
* Removed a useless line of code in showEditUserGroupsForm
"list( $addable, $removable ) = $this->splitGroups( $groups );"
this was never removed from when $addable and $removable were changed to
just $groups, and so it does nothing and is just confusing.
As a UI thingy, $wgUser will be the only relevant user object here; there's no circumstance in which we might pass some other user object. No reason to pass it to hooks just on the off chance that they might use it, then...
The namespace parsing thing feels very hacky and grabs bits out of an internal implementation function which doesn't feel like a stable interface.
Would recommend thinking about this and coming up with a more serious stable interface for it.
If Linker::link() is passed an invalid Title, now that it fails gracefully, we should fail gracefully before passing over to the hook. In theory some hooks might want to override this, but it's unlikely, because any caller that passes a non-Title is probably buggy and should be fixed anyway. This saves unexpected fatal errors and/or having to add "if( !$target instanceof Title ) return true;" to the beginning of every function hooking into this.
Also ensure that $options is an array before passing to the hook, just for convenience.
If $injected_html is provided, then the redirect page on login will still be shown. This is needed for auto-login in CentralAuth. I can't test that the fix works, though, because I don't have CentralAuth installed. Unfortunately, this means Wikipedia won't benefit from one less click, but I can't think of an easy way around that.
This saves a click. A "You have successfully logged in" message adds no extra information, it just gets in the way -- especially if you got to the login page from a permissions error. The welcome message is still displayed on account creation.
This slightly modifies the semantics of a hook. It also makes the loginsuccess message unused, so I've deleted it from the maintenance files and also MessagesEn. I assume it will automatically vanish from the other message files, or at least that there's some tool to remove it that I don't know about that's better than sed.
This was prompted by discussion on bug 15484.
* Avoid overselecting fields in RC and add $fields to SpecialRecentChangesQuery
* Some whitespace tweaks in RecentChange.php. Remove dead code.
* Avoid rc_new check in ChangesList
* Move some "unpatrolled" CSS to shared.css. Add 'newuser' CSS.
* Bump style version
** Backend code moved to RecentChange::reallyMarkPatrolled() and doMarkPatrolled()
** Adapted Article::markpatrolled()
* (bug 15466) Added action=patrol to the API. Modified patch by Soxred93
* Added rctoken=patrol to list=recentchanges
* Detect duplicate warnings in ApiBase::setWarning()
* Introduced SiteConfiguration::$siteParamsCallback, a callback function that returns an array of params to define custom parameters to replace and wiki tags so that they can be used at run time (e.g. for CentralAuth or SiteMatrix), can also override SiteConfiguration::siteFromDB(). See the documentation of that variable for further information. Backward compatibility is maintened for paramters passed to SiteConfiguration::get() and similar functions but the vaules returned by the callback function will override them.
* Added SiteConfiguration::arrayMerge() for merging arrays, written by Werdna. Warning: as array_merge(), it may change numeric keys, so don't use it for settings having namespaces index in keys.
* Removed SiteFromDB hook, deprecated by the callback function
* document a bit
$wgAddGroups and $wgRemoveGroups, where the user must belong to a specified
group in order to add or remove those groups from themselves.
Backwards compatibility is maintained.
* Added hook 'UserrightsChangeableGroups' to allow modification of what
groups may be added or removed via the Special:UserRights interface.
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.
