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.