Deprecated only since 1.23, but universally reviled, and used only by
MwEmbedSupport, which no longer uses it as of I43af3c87a).
Change-Id: I36c89b273fdb0ec3a76034c7a6d2f48a15d5457f
* By default, wiki should keep the envelope sender as $wgPasswordSender
* Requires BounceHandler extension. Added hook to core
* Alters the return path, to bounce-{key}@domain
* The envelope sender is set using the 5th param in mail()
Bug: 46640
Needed By: I9463ae33ae327405725ea9693d45ad61b8ecf798
Change-Id: Ic5c1231611a5c4984ddf81fd716e6f3a3e82fd57
Location is a tad bit different now than on the wikiHow codebase and some
arguments have been added, as per code review.
Because sometimes you have things that are stored in the user_properties
database table that should *not* be reset even when the user has requested
to reset all prefs back to the site defaults.
Live example of a thing using this hook (well, its previous iteration) is
wikiHow's WikihowPreferences extension.
Change-Id: I1da936c786adb21e2c1802ef405bb904c9cf4918
Adding 3 hooks to MimeMagic.php
- MimeMagicInit: Add assignments of MIME types -> Media types
and assignments of MIME types -> File extensions
- MimeMagicImproveFromExtension: Further improve the MIME type detected
by considering the file extension
- MimeMagicGuessFromContent: Guess the MIME from file content
This is the successor of Icf9eec10bec7c0a7e.
PHP's own module fileinfo module is not capable detecting Chemical
table files. Instead, they are reported as text/plain.
MediaHandlers can be attached by MIME type only. That's why these
changes are required for [[Extension:MolHandler]] to work.
Clean up:
Do not create unused property MimeMagic::mToMime.
Change-Id: I67f3e4e83b47e6df0d9e8371f09a741a8aa77651
It is needed for PageImages to collect information about galleries, improving results
for Commons mainspace.
Bug: 66510
Change-Id: I3136d648ef2c1841767db0ab33855cd168e3de3e
Hooks with dynamically generated names cannot be documented in the normal
manner, and indeed this set, added in r86482 / 10d93c34cb, was not.
In contrast, every other hook in core has a name that is a fixed string
and thus is easy to grep for, create a manual page title for, and so on.
Conceptually, each hook's name should correspond to one or more locations
at which code can be inserted.
So I changed the code to use hook name "SpecialPageBeforeFormDisplay"
for all FormSpecialPages and added the special page name as a parameter,
which is consistent with existing hook "ActionBeforeFormDisplay".
From extensions in Gerrit, the only use I found was in StopForumSpam,
which is updated to use the new hook in Id474915a. So I chose to break
backward compatibility instead of using a hack to hide the old hooks
from maintenance/findHooks.php.
After three years, the script again reports, "Looks good!"
Change-Id: I7ea6521b47fb034bc367a1d06d477a7654035a5f
This hook is poorly thought out. The only extension that uses it
can't possibly think it works how they're expecting.
Change-Id: I853a01afc8e922f22e949321a2f2343d264632a6
* Correct typo in docs/hooks.txt.
* Add a few directories.
Left unfixed is "Undocumented: Special{$this->getName()}BeforeFormDisplay",
which will be addressed separately.
Change-Id: I4fda8960642c23500bd20e0b89c1d1327456313b
Allows for modifying returnTo url, url parameters, and the redirect
type.
New return to condition 'signup' if redirecting after signup
Treated same as 'success', though now explicitly marking as such
Part of making GettingStarted not dependent on CentralAuth
Bug: 65619
Change-Id: I219353d9825918e22d4772611a38d72c4e674e10
For ZERO, we need to be able to avoid forceHTTPS from taking place in
case user logged in while on wifi, and later switched to
zero.wikipedia.org for the carrier who doesn't support HTTPS.
In that case, the extension will need to be able to cancel redirect
and force regular HTTP handling.
Open Question: should this code log off user in case hook returns false?
Bug 65567
Change-Id: If04c83066c5d47b3c04ad7674e3c4e95a4cd464b
Called before a link to the current article is displayed to allow the display
of the link to be customized.
Bug: 63592
Change-Id: I343e1b1b08ec841d22a1b22bcb8af43bb65a5a50
All other footer content is rendered in the user language and the
copyright notice on the edit page is also in the user language.
See EditPage::getCopyrightWarning().
We already do this on WMF wikis through the WikimediaMessages
extension (which sets $forContent to false). The same behaviour has
been requested for 3rd party wikis as well.
Bug: 49116
Change-Id: I1dddfa7771c7063ec319fa441c2e400a374abc92
This should explain the conventions of the MediaWiki project.
Wikimedia is a prominent user of MediaWiki, but not the only one.
Other MediaWiki installations do not share all of Wikimedia's
values and mission. However, it is possible to express common values
that should guide this work in core.
Thus, I retained some of the existing text, as well as adding one other
point, accessibility (which we have discussed but was not mentioned
here).
Change-Id: Iafc8641c9b89138b3e4b7f6e274395279ddad43c
Allows to modify sidebar abstract representation just before its output
Required by change Ib4014253016db1c3d6b624be9ebbdaf452115145
Change-Id: I170e7253825c8dab5cad38e6b0ba59f28572efbf
This hooks allows extensions to override the normal model-specific
rendering of page content. A typical use would be to provide syntax
highlighting for pages that contain scripts. In that sense,
ContentGetParserOutput is a generalization of the old ShowRawCssJs
hook.
This, together with I76412f9d, is a (hopefully) fixed version of the
reverted Ibfb2cbefea44.
Change-Id: I979e2438689648ba4c959d8083197ef14ce524e8
In bug 63240, Roan calls it a 'misfeature', which I think is exactly right. It
has been used as a lazy workaround for having to think about load-order,
dependency management, and race conditions.
Bug: 63240
Change-Id: Ic48ad39c6d3d166d6bb8f60dfdd5f95aa7ed16a6
Nothing is listed on mw.org as using these and nothing in Git uses
them either. Less hooks is a good thing, we've still got 11 here :(
Change-Id: I2dd1dbb269820b192f8d9e9a496a161f4ef851bf
EditPage::showReadOnlyForm:initial which is analogous to
EditPage::showEditForm:initial
Bug: 45258
Change-Id: I6885d617e18562acf0331e8db5790b53b489dbc2
The static method 'Linker::makeMediaLinkFile' produced a HTML string
without usage of MediaWiki 'Html' class. It also lacked a hook to allow
modifications of the output HTML.
I altered the implementation and added a hook that provides a signature
and behaviour similar to the existing 'LinkerMakeExternalLink' and
'LinkBegin'/'LinkEnd' hooks. It provides all available context information
and allows modification of single attributes or the output HTML as a
whole. I have updated the 'docs/hooks.txt' file to provide proper
documentation.
Change-Id: I6d7769298a4ca6cbbf807fcebb91fb0d2222f8d8
Old hooks (called by SpecialWatchlist, SpecialRecentChanges and
SpecialRecentChangesLinked) have been deprecated, but I'm not planning
to remove them anytime soon. (They have lots of usages in extensions
as of this writing.)
The new hooks (and their deprecated friends) are:
* ChangesListSpecialPageFilters:
* Replaces: SpecialRecentChangesFilters and SpecialWatchlistFilters
* The signature for this one is exactly the same as signatures for
the other two. We might want to pass something else than $this
here…
* ChangesListSpecialPageQuery
* Replaces: SpecialRecentChangesQuery and SpecialWatchlistQuery
* These hooks have wildly different signatures. The new one is a
superset of the old ones, in a more reasonable order, with the
addition of the name of the special page we're doing right now.
Change-Id: I9cceda5d2dcfc53c852c5682c466b48ad8f31202
