Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
Added/removed spaces after opening/before closing parentheses
Added a space after a comma
Removed unneeded parentheses in condition
Change-Id: I306091347ccaaf11dee0cdfda3019cb0c12be51b
This avoids $wgUser in that method
Also removed the double strencode for logtypes,
that is already done by Database::addQuotes/Database::makeList
Change-Id: I5f7f6da06594d92375f74ca48c04d180505642a9
When a user has only deletedhistory and not deletelogentry he should not
see checkboxes, because the button at the begin of the page is missing
and than the checkbox is useless. Use links instead, as the history page
does.
Change-Id: Icae8267dcf3032437eae08372ddbe5769bed7a86
* This allow extensions to set both action text and links directly
from a subclass LogFormatter instead of having to use the LogLine
hooks for this purpose.
* Moved stuff for logs that already use a subclass of LogFormatter
there and the remaining in LegacyLogFormatter. I had to an hack
there so that the pass-by-ref of the comment parameter in the
LogLine hook still works.
* Removed RevisionDeleter::getLogLinks(), included it directly in
DeleteLogFormatter::getActionLinks(); it have a so ugly signature
that is very hard to use it somewhere else (and maintain backward
compatibility too).
* Removed the message caching system in LogEventsList since it's
not used anymore.
* Some misc cleanup to LogEventsList::logLine()
Change-Id: I96d696eed2ae35f5f5640e422ceb0a5b0c33babf
The line above changed in that revision, but not this one,
so I highly suspect that this occurence of deleterevision
should have been changed to deletelogentry.
Change-Id: Ief4ca9acf08bccc8ff064cea5795a2dbeae44d19
This change adds a new permission ('deletelogentry') which is required to be able
to delete log entries.
It does not affect who can see deleted content.
Change-Id: I6b69919a1bdc502becc1ae4ac9169b8b0e85bfdc
@fixme is simply not recognized by doxygen whereas @todo is used to
generate a nice ... todo list!!
Change-Id: If956c0a164373126ce48b791d45c56962034eecd
Modified the constructor so that it simply needs a IContextSource in the first parameter, but it
still accepts a Skin object instead. The second parameter is now unused. Updated SpecialLog accordingly.
Change-Id: I6dde2a23d98568abe10e92f0761ae3be7c65a856
* mw.config is the new way, and global config variable lookups are deprecated
* Based on two phase3-wide quick searches:
-- of " wg": http://toolserver.org/~krinkle/wikimedia-svn-search/view.php?id=321&hash=81700bf7486e4fee3b7bc1f83eb9eba6
-- of "!wg": http://toolserver.org/~krinkle/wikimedia-svn-search/view.php?id=327&hash=47c9d54a7a1d5d58a724dd834585f40d
Related changes:
* Changed some php comments mentioning "wg" variables to include the dollar sign, and a typo when the wf function prefix was meant.
* Removed TODO comment in wikibits.js and made it use the JS equivalent of wfUrlencode, which we have now, mw.util.wikiUrlencode
* SpecialUpload.php: use OutputPage::addJsConfigVars instead of creating a new script tag through OutputPage::addScript(Skin::makeVariablesScript(..))
* Renamed wgUploadSetup in upload.js and made it local. Not used anywhere in ./trunk/phase3 and ./trunk/extensions
* Fix OutputPage::addJsConfigVars so that it can actually be called with an array instead of two arguments for key/value
* Some minor whitespace/convention stuff around the same line
those logs are restricted, will generate a warning, since it removes first entry of
array, but doesn't re-index the array, and subsequent code makes assumptions of the
form if ( count( $this->types ) $singleType = $this->types[0] (which doesn't work, as
first index is 1).
Thus cause array to be re-indexed if a $wgLogRestriction causes a log type to be removed.
Steps to reproduce the issue is make deletion log restricted, then view a (non-existent) user page.
Personally I think its kind of weird/wrong that if someone restricts both the move and delete log,
then viewing a non-existent will give "This page has been deleted, here's delete log:" followed by an
entry from *any* public log.
