Before this change, there were (? being regex 0 or 1)
"" ===? 1
'' ===? 24
"" !==? 8
'' !==? 32
== "" 14
== '' 344
!= "" 9
!== "" 4
!= '' 151
!== '' 85
Rhs was the much more common, and the preferred style by many developers.. (Was a similar discussion in #mediawiki recently.. After that lolbugreport i think)
Where there is a string (non empty) on the lhs, and variable/method call on the rhs still need normalising
1. Only use Accept-Language when 301 redirection happens. It won't call the parser, but it is the most case we need to ensure it uncacheable.
2. Merge addXVOHeader with addVaryHeader.
* Fixed CR r49408: removed JS dependency for multiple revision delete/undelete. Using <button type=submit> we can submit the parameter "action=revisiondelete". The custom action is then distributed to Special:Revisiondelete, which can understand this kind of entry point with only minor changes.
* Also used <button type=submit> to avoid submitting the htmldiff button caption back to the server
* Show the same buttons at the top and bottom of the history page, refactored duplicated code
* Moved historyLine(), beginHistoryList(), endHistoryList() and related helper functions to the pager class.
* Renamed HistoryPage member variables, removed "m" prefix.
* Added declaration for IndexPager::$mIsFirst
r44972 isn't quite behaving transparently; non-view URLs are also being redirected to the raw view page, so for instance an ?action=edit or diff or whatever gets lost.
See for example:
http://en.wikipedia.org/wiki/Image:Wiki.png?action=edithttp://en.wikipedia.org/wiki/Media:Wiki.png?action=edit
these both currently behave just like:
http://en.wikipedia.org/wiki/File:Wiki.png?action=edit
while with this patch the Media: one would unexpectedly redirect to the view URL.
The redirection should probably just be done where other existing normalization is... perhaps all that's actually needed is just to replace a Media: Title with the equivalent File: one when initializing the title in the first place, and the existing normalization-redirection will take care of it.
Mostly seems to be formatting tweaks, loss of useful debug log output, and mysterious unexplained changes.
If some of these tweaks actually are based on profiling data, please provide details, such as "rearranging this call reduces service time from 80ms to 50ms for client cache hits on my machine" or whatever.
Article::viewUpdates() may do things other than update counters (for instance, it updates the user-talk and watchlist for last-viewed status, and might do other things in the future). Let it centralize its own checks for what things are enabled. Since you won't necessarily know them all over in Wiki.png, they may get out of sync and lead to bugs if you try to replicate the check.
Let the doUpdates() func get counted even when it has nothing to do; otherwise stats will be skewed to only times when there are multiple updates. Or.... hmmm. bleah.
