Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: Iced714bca004756b461b66067a49a925a7e3b877
Variants included 'in <version>', 'as of <version>' and just the
version number.
Some @deprecated annotations do not have the version number at all,
I want to hunt them down separately.
Change-Id: I8208c6097098f4735d4f51bc42254675f1f27f6d
On revision delete success, we show an excerpt from the log,
it is very confusing when that excerpt doesn't include the
action that you just did.
Bug: 57033
Change-Id: Ica79bf76243f7ab7a2a0fb40689c34bd2ffc0297
* LogEventsList::getDisplayTitle() was deprecated in 1.20.
* LogPage::logHeader() was deprecated in 1.19.
* LogPage::logName() was deprecated in 1.19.
No remaining uses in core.
Change-Id: I073f11a7776f6e3809d20d50e61e57486b77f494
Also:
* Take function call out of for loop test part.
* Suppress CodeSniffer warnings for unavoidable long lines.
Change-Id: I14044f14b30d494d910541a1dac50921254a7398
Added spaces after/before parenthesis
Removed unneeded parenthesis around some statements
Broke a long line
Change-Id: I7fbe129f7bbf524dd0598ece2a9708643f08453b
LogEventsList:showLogExtract currently pays attention to WebRequest
parameters such as offset, dir, order, and limit (although limit is
typically overridden by callers, and offset sometimes too).
While these make sense for a pager that is driving the whole page, it
doesn't make much sense for the "most recent log entry" boxes that are
displayed using LogEventsList:showLogExtract. So let's have
LogEventsList:showLogExtract ignore these, and for good measure add in a
parameter to use the old behavior in case any caller really needs that.
Change-Id: Id4380cd863ba69fc9b9afb5a0034d82ad4d9cc34
And added/removed spaces around some other tokens,
like +, -, *, /, <, >, =, !
Fixed windows newline style
Change-Id: I0b9c8c408f3f6bfc0d685a074d7ec468fb848fc8
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.
