We would like to begin deployment of the 1.18 code base on Monday, but
we've fallen a little behind of where we need to be.
We want to have all code reviewed and all FIXMEs fixed by Friday night
so that we can enjoy the weekend, relax and prepare to push out the 1.18
code base to the first few wikis on Monday.
As of Thursday night, New York City time, we have 16 revisions left to
review and 4 FIXMEs left to fix.
More eyes on these problem revisions would help so here are the last 20
revisions that need work along with their committers and commit
summaries:
FIXMEs
==============
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86312 (reedy)
We need a title object for parsing, do one against the message key
Doesn't seem to be the best way, but it's the most applicable. If I
abused $wgTitle, Chad would come and beat me too ;)
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86735 (reedy)
Followup to r86312
<ialex> Reedy: that rev is breaking usage of {{PAGENAME}} in
messages, such as in MediaWiki:Noarticles
Allowing optional passing in of a Title object (like it may be set
in Message), but if it's not set, or not a title object, fall back
and use $wgTitle (I'm sorry!)
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91518 (robin)
(bug 6100; follow-up to r91315) Being bold and removing
$wgBetterDirectionality (and dependent wfUILang) in core, as most or
all work is finished. Also:
* Introduce classes mw-float-end, mw-float-start so we don't have to
use inline css depending on wfUILang()/$wgLang (see HistoryPage
and SpecialFileDuplicateSearch)
* Add direction mark to protection log
* Remove specialpageattributes as it is obsoleted by this commit
(also fixes bug 28572)
* Add two direction marks in wfSpecialList, which makes ltr links on
rtl wiki (and vice versa) display nicely as well (only on those
special pages however)
* Revert r91340 partially: use mw-content-ltr/rtl class anyway in
shared.css. Both ways have their [dis]advantages...
* Set the direction of input fields by default to the content
language direction (except buttons etc.) in shared.css
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91561 (bawolff)
(Bug 19725) Do not include suppressed edits in the "View X deleted
edits" message, and when doing prefix search of special:undelete.
I'm not 100% sure this is the right thing to do, see the bug for the
details. But basically this doesn't include an edit in the count if
its text is hidden and its hidden from admins. (Not sure if it
should not be included only if everything is hidden). Its also weird
to show people different things depending if they have suppress
rights, without really indicating that.
Minor db note: This causes the query to no longer use a covering
index. I don't think that matters but just thought i'd mention.
p.s. The upload page show deleted edits link is broken right now,
(from before) I'll fix in a follow-up.
Needs Review:
==============
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84591 (aaron)
* Made BeforeParserMakeImageLinkObj/BeforeGalleryFindFile let hooks
set sha1 parameter
* Made FlaggedRevs specify files by sha1,timestamp to handle renames
with no redirects. This makes them handled as well as templates in
this regard. (bug 27836)
* Moved BeforeGalleryFindFile hook to proper place (don't trigger
for non-NS_FILE titles)
* Removed unused mRevisionId field from ImageGallery
* Removed old hotfix from makeMediaLinkObj(); all the current
callers would crash beforehand if the title was null anyway
* Updated hook docs (some prior params were missing)
* Broke some long lines and cleaned up some whitespace
* TODO: track file info in core rather than fr_fileSHA1Keys and
ugly, duplicated, queries. This should be easy to do now.
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84610 (aaron)
* Put parser output file version tracking to core
* Added some ParserOutput accessors
* A few cleanups to fetchFile()
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84619 (aaron)
Follow-up r84610: removed fr_fileSHA1Keys and use core file version
tracking instead. Handles query spam FIXME in code.
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88780 (aaron)
* Follow-up r88740:
* Fixed parse() arguments in getRevIncludes()
* Changed clearTagHook() to avoid preprocessed-xml cache corruption
* Check current version cache in getRevIncludes()
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97022 (aaron)
Possible fix for issue reported in r83762. I had a hard time
confirming the problem/fix with profiling. Committing this now to
get more attention.
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97077 (aaron)
FU r97022: Fallback to empty array for getExtraSortFields() result
in __construct() if no value is set for the sort order/type.
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97034 (brion)
* (bug 6722) Spacing fixes for math functions with/without parens
* (bug 18912) Add math support for \sen Spanish variant of \sin
* (bug 18912) Fix spacing for \operatorname in math
Reapplies r86962, r87117, r87936, r87941 plus some parser tests.
Note that further batch testing to identify any other potential
problems due to the spacing tweaks is a good idea!
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/74966 (catrope)
First shot at porting Monobook to Vector. The only
non-straightforward part is moving from a separate rtl.css file to a
main.css file we can safely Janus. This is half-done right now.
Notable things:
* No longer including rtl.css, instead relying on Janused main.css
* Renamed external.png to external-ltr.png so Janus will pick up on
external-rtl.png (already exists)
* Added @embed to all images, add @noflip where needed (may not have
covered all cases)
* Pulled some things from rtl.css into main.css such that they're
no-ops in LTR but are needed in RTL. Example: body {
direction:ltr;
* Killed some RTL-specific rules in main.css that were superseded in
main.css
* Changed padding: 0 foo; to padding-right: foo; so it gets Janused
right
* Commented out loading of IE*Fixes.css. Still need to incorporate
these into main.css somehow
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/96560 (catrope)
OggHandler: Address issues with protocol-relative URLs. Live hack in
r96400.
* Use $wgExtensionAssetsPath instead of "$wgScriptPath/extensions"
* Use wfExpandUrl() rather than the DIY method of detecting whether
the URL needs expanding and prepending $wgServer. Left the
detection for $wgCortadoJarFile alone since that needs $scriptPath
prepended to it if it's not absolute
* Expand $this->videoUrl using PROTO_RELATIVE instead of r96400 's
PROTO_CURRENT to avoid cache pollution, and add a protocol the
second the URL arrives on the JS side
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97150 (catrope)
Update jquery.tablesorter for r97145: emulate <thead> if there is no
<thead> in the HTML, by walking down the table starting at the first
row and moving rows to the <thead> as long as all of its cells are
<th>s (or the row is empty). Also fix and simplify the sortbottom
code, which was incorrectly creating multiple <tfoot> elements if
there were multiple sortbottom rows.
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/92054 (diebuche)
Render category links as an HTML list. Bug 12261. Based on patch by
Thana & Bergi. It's removing the textual pipe separator, wrapping
the links inside li elements and adding a left 1px border as
separator. This makes it much easier to manipulate the list via JS
or CSS and is also semantically correct
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89220 (platonides)
Remove Cite singleton. Store it inside each associated parser at
$parser->extCite This fixes bug 20748 and bug 15819 without breaking
the other tests. Reverts r88971. The conflict with CategoryTree was
the old problem of a message being called inside of a parser
callback, this time with clearState for which the hook is global.
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89706 (platonides)
Reinstate r79122 (fix for bug 14404), reverting r83868. The real bug
seem to have been r86131, fixed in r88902 (1.17) and r88902 (1.18).
This is not merged with the r86131 change to
Article::getParserOptions() since I don't see the point for the new
function yet. Reenabled its test ArticleTablesTest which was
disabled in r85618
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86304 (reedy)
* (bug 28532) wfMsgExt() and wfMsgWikiHtml() use $wgOut->parse()
* (bug 16129) Transcluded special pages expose strip markers when
they output parsed messages
Also adding some related documentation during my travels around the
code
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97192 (robin)
Use wfSpecialList() so it displays properly when user direction !=
content direction, and call Linker function statically.
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97145 (tstarling)
Reverted r85922 and related: new doTableStuff(). I copied in the old
doTableStuff() from before r85922 and reverted all parser test
changes that looked vaguely related. Apologies to Platonides, since
some of his parser tests appeared to be relevant to the old parser,
but it's simplest to just revert all the related changes and then
re-add any useful tests later. See CR r85922 for full rationale.