[MediaWiki-CodeReview] [MediaWiki r91587]: New comment added
User "Peachey88" posted a comment on MediaWiki.r91587. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91587#c19303 Commit summary: Re-commiting QPoll v0.8.0a using svn move. This version is still in development and is not ready for production use. Documentation will follow after the bugfixes / feature additions. Comment: "/trunk/extensions/QPoll/qp_i18n.php (deleted) (diff)" ViewVC doesn't like deleted files. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r80240]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r80240. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/80240#c0 Commit summary: Fix bug 14267 by adding support for a MediaWiki:Mainpage-nstab. Additionally, *cough* *cough*: * Add a Title::isMainPage helper for the fairly common $title->equals( Title::newMainPage() ); test. * Update wfMessageFallback to also accept an array of message keys instead of requiring them listed as arguments to the function. * Move the bulk of wfMessageFallback code into Message.php instead of leaving it in GlobalFunctions.php * Change the wfMessageFallback implementation so that the Message class handles the fallbacks themselves eliminating any side effects caused by the fact that wfEmptyMsg always used usedb=false, language=userlang when one might actually use a different language or usedb setting in the message object that actually returned the text (this may be considered a wfEmptyMsg regression in 1.18). * Make blank "" message contents fallback like nonexistant messages do. * Re use the new tabAction array handling used to support mainpage-nstab in the talk and view tabs instead of making wfEmptyMsg calls directly in SkinTemplate. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r81106]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r81106. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81106#c0 Commit summary: (bug 26285) Extensions will be automatically generated on upload if the user specified a filename without extension. Note that this still will throw a warning. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r81507]: New comment added
User "Aaron Schulz" posted a comment on MediaWiki.r81507. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81507#c19302 Commit summary: Completely remove support for legacy style skins. All legacy skinning options are now part of a SkinLegacy/LegacySkinTemplate pair that inherits from the normal SkinTemplate setup. Also ported our three built in skins to use the new legacy classes. ( ;) if you want to kill legacy skins now, you only have to svn rm 4 files) Comment: Is this fully resolved? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r81536]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r81536. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81536#c0 Commit summary: (bug 19751) Filesystem is now checked during image undeletion * FSRepo::storeBatch() now does an sha1 check unless SKIP_VALIDATION flag is set * Introduced Status::$success in addition to Status::$successcount ** FSRepo::storeBatch() now logs success/failure in this variable * LocalFileRestoreBatch now aborts on failure in FSRepo::storeBatch() and cleans up the already copied files ** Introduced FSRepo::cleanupBatch() for this purpose * SpecialUndelete now aborts if LocalFile::restore() gives a fatal ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r81903]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r81903. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81903#c0 Commit summary: Added "context title" to replace $wgTitle, current behavior unchanges, but added a comment that this might change in the future to completely remove $wgTitle usage in EditPage Also removed null check on showEditForm() since $wgTitle is set on ApiEditPage.php, so it won't catch anything ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r82783]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r82783. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/82783#c0 Commit summary: * (bug 24230) Added JAR detection. ZIP archives containing a .class file will be rejected by default. Malformed ZIP archives will be rejected due to the danger of ambiguous parsing on the client side. * Removed the ZIP subtypes from $wgMimeTypeBlacklist, they no longer need to be there. * Added ZipDirectoryReader. Added some small ZIP files which are used to test its various error cases. Most were constructed with a hex editor. * Fixed getStatusArray() to return a consistent type regardless of whether the error message has parameters. This allows error messages with no parameters to work with the Status object conversion code in UploadBase::verifyFile(). ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] wiki markup lacks HTML precision anchors
On 11-07-06 08:27 PM, Alexander wrote: > On Jul 6, 2011, at 19:55, Jay Ashworth wrote: > >> - Original Message - >>> From: "Chad" >>> On Wed, Jul 6, 2011 at 10:29 PM, wrote: While I would not list the Mediawiki language as a 'crap' language, I still think it is regretful that one cannot achieve the precision of an HTML anchor, to say, make a link to a spot anywhere within a page, whereas with the Mediawiki language, the best one can do is link to the top of a table for example, http://en.wikipedia.org/wiki/Historical_Chinese_phonology#Initials instead of also to a random point within say, giant tables. >>> And doesn't work why? >> You can #-link to a *span name*? Really? >> >> I didn't know that. >> >> Cheers, >> -- jra > IIRC, all modern browsers support hash linking to any element with an id > attribute. > --Alexander Yes, in fact that's the standard. The standard has been id="" since XHTML. HTML5 continues it, name="" is gone. Only ancient HTML4 used and it's only used in obsolete browsers now. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r82908]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r82908. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/82908#c0 Commit summary: Moved stuff so the cURL class can be used to post files and added constants so you can check if the class allows for file posting ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84233]: New comment added, and revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r84233. Old Status: new New Status: fixme User "Aaron Schulz" also posted a comment on MediaWiki.r84233. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84233#c19301 Commit summary: (bug 27403) saved user preferences which are subsequently disabled with $wgHiddenPrefs are not used in output, but are retained in the database in case the preference is subsequently re-enabled. Comment: Can you make $ignoreHidden use a const or string param "ignoreHidden". I really don't like opaque Booleans like this. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91625]: Revision status changed
User "Reedy" changed the status of MediaWiki.r91625. Old Status: new New Status: deferred Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91625#c0 Commit summary: Make navigating between blocks (with cursor left and right) works ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87705]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r87705. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87705#c0 Commit summary: Make it so that when a special page is trancluded, the output won't vary by url parameter. This stops severe ugliness http://test.wikipedia.org/wiki/User:Bawolff/special?feed=atom where the rss feed and the html of the page is concated together. This could potentially break stuff if someone was using a transcludable special page with an html form, or if someone is actually passing parameters to the transcludable special page via the url. I'm not aware of anyone who does that, and both those things seem rather evil. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87900]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r87900. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87900#c0 Commit summary: Add unit test for jquery.colorUtil module ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88896]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r88896. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88896#c0 Commit summary: Use WebRequest::getQueryValues() to get all query strings parameters instead of $_GET ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88898]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r88898. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88898#c0 Commit summary: Merged MediaWiki::performRequestForTitle() and MediaWiki::handleSpecialCases() into MediaWiki::performRequest(): * this allows to perform tests in the correct order, i.e. first BadTitle check and then userCanRead() * the Article object is now returned by the function instead of passed back in pass-by-reference parameter * Removed the "return false;" when MediaWiki detects a redirect, was causing an useless full execution ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88914]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r88914. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88914#c0 Commit summary: Refactor the common code of compareParsers.php and preprocessDump.php into a dumpIterator.php script. Implement a simple 'search into this dump' ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88942]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r88942. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88942#c0 Commit summary: Move down interwiki disabling to dumpIterator and make SearchDump work without a db. Removed stripParameters() which shouldn't have been added to the base class in r88914 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88914]: New comment added
User "Aaron Schulz" posted a comment on MediaWiki.r88914.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88914#c19300
Commit summary:
Refactor the common code of compareParsers.php and preprocessDump.php into a
dumpIterator.php script.
Implement a simple 'search into this dump'
Comment:
$this->hasOption('file') ^ $this->hasOption('dump')
Should that be 'xor' instead of "bitwise xor"? I guess the later still works
due to casting.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] wiki markup lacks HTML precision anchors
On Jul 6, 2011, at 19:55, Jay Ashworth wrote: > - Original Message - >> From: "Chad" > >> On Wed, Jul 6, 2011 at 10:29 PM, wrote: >>> While I would not list the Mediawiki language as a 'crap' language, >>> I still think it is regretful that one cannot achieve the precision >>> of >>> an HTML anchor, to say, make a link to a spot >>> anywhere >>> within a page, whereas with the Mediawiki language, the best one can >>> do >>> is link to the top of a table for example, >>> http://en.wikipedia.org/wiki/Historical_Chinese_phonology#Initials >>> instead of also to a random point within say, giant tables. >>> >> >> And doesn't work why? > > You can #-link to a *span name*? Really? > > I didn't know that. > > Cheers, > -- jra IIRC, all modern browsers support hash linking to any element with an id attribute. --Alexander ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r89110]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r89110. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89110#c0 Commit summary: Some language love ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] wiki markup lacks HTML precision anchors
- Original Message - > From: "Chad" > On Wed, Jul 6, 2011 at 10:29 PM, wrote: > > While I would not list the Mediawiki language as a 'crap' language, > > I still think it is regretful that one cannot achieve the precision > > of > > an HTML anchor, to say, make a link to a spot > > anywhere > > within a page, whereas with the Mediawiki language, the best one can > > do > > is link to the top of a table for example, > > http://en.wikipedia.org/wiki/Historical_Chinese_phonology#Initials > > instead of also to a random point within say, giant tables. > > > > And doesn't work why? You can #-link to a *span name*? Really? I didn't know that. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r89204]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r89204. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89204#c0 Commit summary: * Fix hphpi mode in run-server, it wasn't quite working properly ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89206]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r89206. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89206#c0 Commit summary: * Made the profiler work in HipHop: ** Don't try to set a global variable in the same file as a class definition (Profiler.php). Set it in WebStart.php instead. ** In StartProfiler.sample, don't use require_once() to get ProfilerStub. * Removed the setproctitle() stuff from ProfilerStub, the extension is not maintained and doesn't work with Apache 2.x * Added an optimisation to wfProfileIn() and wfProfileOut() to reduce the overhead when profiling is not enabled * Added the ability to configure in StartProfiler.php whether CPU time or wall-clock time is used, avoiding recompilation ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] IRC Triage of “easy” bugs
>I've been waiting for this but unfortunately I can't be at that time. Would >there be a log about the result? #wikimedia-dev is always logged at http://prototype.wikimedia.org/logs/%23wikimedia-dev/ -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r89318]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r89318. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89318#c0 Commit summary: Explored some ideas for HipHop optimisation. Made a preprocessor implementation, based on a copy of Preprocessor_Hash, with a preprocessToObj() which is optimised. It takes 33% less time than Preprocessor_Hash for a certain realistic test case (the Barack Obama article). Some notes about what I did: * Set EnableHipHopSyntax=true to enable string and integer type hints. I gave the file a .hphp extension to avoid false alarms in syntax checking scripts. * Made sure almost all the local variables in preprocessToObj() have a specific type, instead of being variants. This is useful for integers, but has the largest impact for objects, since dynamic method calls can be avoided. * Stopped using extract() since it forces all local variables to be variants, and adds some hashtable initialisation overhead. * Found a way to cast a variant to a specific object class, by abusing argument type hinting. The method does not require special syntax; it is harmless in Zend PHP. * Wrapped various internal function calls with type casts. strspn() and substr() need to be wrapped with intval() and strval() respectively, since they return a variant to support special error return values. HipHop isn't smart enough to know whether the error case will be triggered. * Replaced most instances of double-equals with triple-equals. Profiling indicates that this makes a very large difference when comparing strings, much more so than in Zend. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] wiki markup lacks HTML precision anchors
On Wed, Jul 6, 2011 at 10:29 PM, wrote: > While I would not list the Mediawiki language as a 'crap' language, > I still think it is regretful that one cannot achieve the precision of > an HTML anchor, to say, make a link to a spot anywhere > within a page, whereas with the Mediawiki language, the best one can do > is link to the top of a table for example, > http://en.wikipedia.org/wiki/Historical_Chinese_phonology#Initials > instead of also to a random point within say, giant tables. > And doesn't work why? -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r90096]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r90096.
Old Status: new
New Status: resolved
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90096#c0
Commit summary:
wgNamespaceIds in JavaScript didn't include canonical namespaces. Adding them
to it, in a similar way that Language->getNamespaceIds does it for the
localized namespaces and the namespace aliases.
Fixes bug in mw.Title constructor when .setNamespace() is used with a canonical
namespace on a non-English content-language wiki.
Example: On a German wiki "var foo = new mw.Title('bar').setNamespace('file')"
will throw an Error, as wgNamespaceIds only contains localized namespaces +
namespace aliases, not canonical ones (in contrary to the assumption that has
been made in various places).
(bug 25375) Add canonical namespaces to JavaScript "wgNamespaceIds"
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] wiki markup lacks HTML precision anchors
While I would not list the Mediawiki language as a 'crap' language, I still think it is regretful that one cannot achieve the precision of an HTML anchor, to say, make a link to a spot anywhere within a page, whereas with the Mediawiki language, the best one can do is link to the top of a table for example, http://en.wikipedia.org/wiki/Historical_Chinese_phonology#Initials instead of also to a random point within say, giant tables. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r90588]: New comment added, and revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r90588. Old Status: new New Status: fixme User "Aaron Schulz" also posted a comment on MediaWiki.r90588. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90588#c19299 Commit summary: Follow-up r90482: escape some more wikitext Comment: wfMsgExt replaces the vars before parsing (unless you give it the 'replaceafter' param). This will now double-encode. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90833]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r90833. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90833#c0 Commit summary: Per http://translatewiki.net/wiki/Thread:Support/Unprotect get rid of term unprotect (hard to translate, not necessarily used to remove protection) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90089]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r90089. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90089#c0 Commit summary: makeCollapsible fix for jQuery 1.6.1 * Pre 1.6, jQuery returned an empty string for attributes that were not set. Although in a way that was wrong, it was the way it was. From jQuery documentation: "As of jQuery 1.6, the .attr() method returns undefined for attributes that have not been set." [1] ** Fixing makeCollapsible by removing empty-string checks and casting to boolean instead * Wrapped a long line [1] http://api.jquery.com/attr/ (jQuery 1.6.1 upgrade was in r89866) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] Postmortem for the MediaWiki 1.17 release
Hi everyone I've just posted postmortem notes on the MediaWiki 1.17 release here: http://www.mediawiki.org/wiki/MediaWiki_1.17/Release_postmortem ...and since I expect there will be some editing/futzing with that page, I've included the full wikitext below. Also, I wouldn't be surprised if this generates some discussion on this list. (start of wikitext): We released [[MediaWiki 1.17]] on June 22. In the interests of doing better next time, a small group of us (Tim, Chad, Sam, Sumana, and RobLa) got together to brainstorm what went right and what we need to look at. [[User:RobLa-WMF|RobLa]] then summarized that discussion, and wrote this summary up. Any first person references are probably me (RobLa), and any references to "we" is probably the group above. See the history for this page for the raw notes. Note: this is specifically about the MediaWiki 1.17.0 release, rather than the 1.17 deployment. == Timeline == Here is the timeline, derived from SVN commit logs: * 2010-07-28 - MediaWiki 1.16.0 released * 2010-12-07 - REL1_17 branched. This is the branch that MediaWiki 1.17.0 was based on. * 2011-02-03 - 1.17wmf1 branched * 2011-05-05 - MediaWiki 1.17.0beta1 tagged * 2011-06-14 - MediaWiki 1.17.0rc1 released * 2011-06-22 - MediaWiki 1.17.0 released == How it went == We started by brainstorming "what went well" and "what to look at". In the initial brainstorming, the original group had many more items in the "what to look at" section than in the "what went well". I then set about organizing things, and settled upon four categories: substance, polish, timing, and process. What became clear was that we felt pretty good about the substance and polish of the release (where positive and negatives balanced out pretty well), but the timing and process categories had the most that we needed to look at. === Substance and polish === As for the substance, it went very well. We had three large features (ResourceLoader, category sorting and the new installer) that complicated this release. As of this writing, it looks like these features are in pretty good shape, and we can be pretty proud of releasing them in the state that they're in. We fixed a lot of bugs (207 noted in the [[Release notes/1.17|release notes]), and made many smaller improvement to the codebase. Everyone was right to be very eager to get this release out. Things of substance that didn't go so well: our PostgreSQL support suffered until quite late in the process, and our command line installer is incomplete in some frustrating ways. On PostgreSQL: the developers who fixed the last of the bugs aren't people that use PostgreSQL on a day-to-day basis. The folks that normally develop our PostgreSQL support had other engagements, and we don't have a very deep list of people to fall back on. We need to work out a plan for engaging PostgreSQL users as developers in this area, or it will be very difficult to continue support for this DB. The command line interface to the installer just needs a little more time to mature; there are many ways of solving this problem without delaying a release, but I won't get overly prescriptive in this writeup. The polish of 1.17 was superb. The release notes were well-written, and there hasn't been an urgent need for a rapid 1.17.1 release. We'll do one anyway, since there were a couple of niggly bugs that can be fixed easily enough. === Timing === As noted, the biggest area for improvement is around the timing and release process. It wasn't all bad; we did (just barely) manage to keep the release cycle under one year. Still, that's much longer than our aspiration of quarterly releases, or even the previous historic norm of 2-3 releases per year. Moreover, it has been a long time since branching 1.17, so we already have seven months worth of work backed up for future releases. 1.18 was branched in early May, so in addition to the five months of changes we have backed up for that release, we already have two more months of changes backed up for 1.19. The biggest thing that delayed this release (and the 1.17 deployment in March) was the code review backlog. That topic has been covered in many earlier threads, but a brief recap: after the 1.16 release, we fell way behind on code review, relying solely on Tim up until that point. We added more reviewers in October, which helped us get the backlog down to a reasonable level by December. We branched, finished off the 1.17-specific review, and deployed. Further minor review work was needed prior to the 1.17 release. With more Wikimedia Foundation developers spending 20% of their time on review, we're optimistic we'll be able to finish off the backlog and stay on top of the review process. As we drew closer to the 1.17 release, we issued 1.17 beta 1. This beta unintentionally lasted several weeks as we tried to finish off the last of the release blockers. In particular, a security bug we worked on during this time created an awkwa
[Wikitech-l] Bug solving metric?
Hi,
is there any metric defined to see how the bug solving pro-
cess has improved over time?
The main reason I'm asking is today's two mails regarding
bug #24000 ("Update rsvg so styling SVG images with CSS
works properly on Commons"). Reported more than a year ago,
the solution found early on was to update rsvg. I would have
suspected that to do that you execute an "rpm -Uvh" equiva-
lent on the server farm and close the bug. Yet for months
nothing happened at all, and then some keywords were added,
removed and replaced.
From an outside perspective, this looks like (much) more
energy is spent on managing the bugs than actually squashing
them. But that of course is not only an outside perspective,
but the biased view of a user who is affected by the bug,
sees a possible solution on his screen and experiences the
helplessness of being at the mercy of someone else :-). So
is there any "scorecard" with more detailed data than the
weekly report, i. e. minimum/average/maximum time to closure
of bugs/non-bugs, some nice visualizations, etc.?
TIA,
Tim
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r90670]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r90670. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90670#c0 Commit summary: Add tooltips to the Special:Recentchanges checkboxes follow up r83110 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90766]: Revision status changed
User "Aaron Schulz" changed the status of MediaWiki.r90766. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90766#c0 Commit summary: Rename messages from r90670 * uses hyphens instead of underscore * follow the tooltip- format * rephrase tooltip-invert per CR ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] Heads-up: WMF engineering process improvement meetings
Hi folks, this is a heads-up that Tomasz, Rob, Alolita, CT, Brion, Roan[TBC], Howie and I will be meeting with ThoughtWorks ( http://en.wikipedia.org/wiki/ThoughtWorks ) Thursday and Friday. Rob and I also got a download from Tim ahead of time. ThoughtWorks has done great work with the fundraising developers (Arthur, Katie, Kaldari) already in helping protect that team from distractions, prioritize its work, and ensure that roles/responsibilities are clearly understood vis-a-vis the fundraising folks in the community department. So, we're now exploring a deeper engagement with ThoughtWorks on problem-solving across the engineering organization. Following initial conversations, the purpose of the meeting tomorrow is to do a deep-dive into a specific problem set: the code review, deployment and release management process. We'll be digging into questions like: 1) What are the best methods to ensure we keep up with the backlog while still maintaining a good clip of WMF priority development; 2) What's a realistic deployment and release cycle to shoot for (for trunk, extensions, branches); 3) How do we dissipate key skills more widely among both staff and volunteers (e.g. deployment, security reviews); 4) How/when can we split "big hairy projects" with integration issues into more manageable chunks; 5) What other high priority improvements do we need to prioritize (e.g. increased test coverage, improvements to the testing frameworks, het-deploy, staging environments, etc.) We're intentionally keeping this first meeting at a manageable size to have a high face-to-face throughput and to explore where ThoughtWorks can best help us. But I'm very much intending to make our thinking public, and to form clear and visible groups around core problems we're tackling, just as we have been doing with all WMF engineering projects. So, I'll keep you posted, and if you have thoughts that you'd like to post ahead of time, please do it onlist or offlist :-) Thanks, Erik -- Erik Möller Deputy Director, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r67742]: New comment added
User "Brion VIBBER" posted a comment on MediaWiki.r67742. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/67742#c19298 Commit summary: Moved functionality for testing browser compatability and finding the highest tabindex in use on a page to the mw.usability object to avoid the Vector extension accessing functionality from (and thus depending on) the WikiEditor extension. Comment: Bug 29749 notes that this added a blacklisting for IE 6 and earlier, while the commit comment only says that it's switching from one set of compatibility check calls to another. Is there a compat issue with IE 6 on this or was this a cut-and-paste error? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91600]: Revision status changed
User "^demon" changed the status of MediaWiki.r91600. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91600#c0 Commit summary: Correct the documentation of srprop. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91626]: Revision status changed
User "Reedy" changed the status of MediaWiki.r91626. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91626#c0 Commit summary: adding USERINFO file jamesur ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91626]: New comment added, and revision status changed
User "Reedy" changed the status of MediaWiki.r91626. Old Status: ok New Status: new User "Reedy" also posted a comment on MediaWiki.r91626. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91626#c19297 Commit summary: adding USERINFO file jamesur Comment: Linked svn to wiki account ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91626]: Revision status changed
User "^demon" changed the status of MediaWiki.r91626. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91626#c0 Commit summary: adding USERINFO file jamesur ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] New committers
Added a few new committers in the last week(ish): Holger Motzkau - prolineserver - CiviCRM work Benedikt Kämpgen - bkaempgen - Semantic MediaWiki, Selenium, Maps James Alexander - jamesur - Fundraising Ian Baker - raindrift - WMF employee Welcome to everyone :) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91610]: Revision status changed
User "Reedy" changed the status of MediaWiki.r91610. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91610#c0 Commit summary: Made $wgFlaggedRevsRCCrap false by default ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91624]: Revision status changed
User "Reedy" changed the status of MediaWiki.r91624. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91624#c0 Commit summary: (bug 27997) Missing message right-lqt-react ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91605]: Revision status changed
User "Reedy" changed the status of MediaWiki.r91605. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91605#c0 Commit summary: MFT updated to head r91592 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91595]: New comment added
User "Reedy" posted a comment on MediaWiki.r91595. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91595#c19296 Commit summary: Added source tracking, fixed whitespace issues Comment: You've still got a mix of spaces and tabs for whitespace ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91590]: Revision status changed
User "Reedy" changed the status of MediaWiki.r91590. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91590#c0 Commit summary: Remove last wfDie()s from maintenance ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91618]: New comment added
User "Reedy" posted a comment on MediaWiki.r91618. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91618#c19295 Commit summary: Replace bullet-icon.png with an 8-bit version (became 24-bit due to r78011 which removed the color palette) * Fixes (bug 19514) Unordered list list-style-image should be IE6-compatible (8-bit) Comment: Tagging 1.17, as there is likely to be a 1.17.1 bugfix + i18n update soon ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r82783]: New comment added
User "^demon" posted a comment on MediaWiki.r82783. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/82783#c19294 Commit summary: * (bug 24230) Added JAR detection. ZIP archives containing a .class file will be rejected by default. Malformed ZIP archives will be rejected due to the danger of ambiguous parsing on the client side. * Removed the ZIP subtypes from $wgMimeTypeBlacklist, they no longer need to be there. * Added ZipDirectoryReader. Added some small ZIP files which are used to test its various error cases. Most were constructed with a hex editor. * Fixed getStatusArray() to return a consistent type regardless of whether the error message has parameters. This allows error messages with no parameters to work with the Status object conversion code in UploadBase::verifyFile(). Comment: Ah ok. Thanks for explaining. I guess those few Exceptions can become MWExceptions then. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r82125]: Revision status changed
User "Krinkle" changed the status of MediaWiki.r82125. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/82125#c0 Commit summary: fixes Bug #27381 Don't (un)expand headings on right click with attached patch ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r82783]: New comment added
User "Tim Starling" posted a comment on MediaWiki.r82783. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/82783#c19293 Commit summary: * (bug 24230) Added JAR detection. ZIP archives containing a .class file will be rejected by default. Malformed ZIP archives will be rejected due to the danger of ambiguous parsing on the client side. * Removed the ZIP subtypes from $wgMimeTypeBlacklist, they no longer need to be there. * Added ZipDirectoryReader. Added some small ZIP files which are used to test its various error cases. Most were constructed with a hex editor. * Fixed getStatusArray() to return a consistent type regardless of whether the error message has parameters. This allows error messages with no parameters to work with the Status object conversion code in UploadBase::verifyFile(). Comment: Maybe at an early stage of development, it was imagined as a standalone library. But it turns out that the PEAR ZIP library was not as bad as I thought it was, so it should be sufficient for most people who need a standalone library. So the main motivation for completing ZipDirectoryReader became the fact that it could be tuned for MediaWiki and integrated with it. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91519]: Revision status changed
User "^demon" changed the status of MediaWiki.r91519. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91519#c0 Commit summary: (follow-up r91518; bug 29658 et al.) Improving RTL support for several extensions: AbuseFilter: aligning rules edit box as LTR, since they are essentially English CodeReview: aligning commit messages according to content language direction; and aligning input boxes on SpecialRepoAdmin as LTR FlaggedRevs: aligning box shown on articles to content language dir; and adding direction marks to ReviewedPages & UnreviewedPages LiquidThreads: * add direction mark * make headings follow the content language dir * remove lqt_post_ltr/rtl (added a few commits ago) to use mw-content-ltr/rtl in core UploadWizard: make calendar input follow user direction (not content direction, as since r91518) (see bug 28902) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91541]: Revision status changed
User "^demon" changed the status of MediaWiki.r91541. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91541#c0 Commit summary: Follow-up r91293, r91519: use wfUILang() for better backwards compatibility ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91293]: Revision status changed
User "^demon" changed the status of MediaWiki.r91293. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91293#c0 Commit summary: Better RTL interface support for CodeReview (bug 29658): paths and code diff should be LTR ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88628]: Revision status changed
User "^demon" changed the status of MediaWiki.r88628. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88628#c0 Commit summary: Made $wgFlaggedRevsAutoconfirm a wrapper around $wgAutopromote ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] ResourceLoader JavaScript validation on trunk (bug 28626)
On 07/06/2011 03:04 PM, Brion Vibber wrote: > Some of you may have found that ResourceLoader's bundled & minified > JavaScript loads can be a bit frustrating when syntax errors creep into your > JavaScript code -- not only are the line numbers reported in your browser of > limited help, but a broken file can cause *all* JS modules loaded in the > same request to fail[1]. This can manifest as for instance a jquery-using > Gadget breaking the initial load of jquery itself because it gets bundled > together into the same request. Long term I wonder if we should not be looking at closure compiler [1], we could gain an additional 10% or so compression with simple optimisations, and it has tools for inspecting compiled output [2] Long term we could work toward making code compatible with advanced optimisations, as a side effect we could get improved jsDoc docs and even better compression and optimisations would be possible. [1] http://code.google.com/closure/compiler/ [2] http://code.google.com/closure/compiler/docs/inspector.html ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91597]: New comment added, and revision status changed
User "^demon" changed the status of MediaWiki.r91597. Old Status: new New Status: fixme User "^demon" also posted a comment on MediaWiki.r91597. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91597#c19292 Commit summary: Added sourcetracking sql file Comment: * We don't typically denote our table/column names with backticks, just use the bare name * Please put /*_*/ in front of 'sourcetracking' so it respects $wgDBprefix * Rather than using PRIMARY KEY(trackingid), do this: trackingid int(11) NOT NULL AUTO_INCREMENT PRIMARY KEY. This way you can support Sqlite * Don't hardcode Engine=InnoDB and the charset, replace them with /*$wgDBTableOptions*/ ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91588]: Revision status changed
User "Reedy" changed the status of MediaWiki.r91588. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91588#c0 Commit summary: Removed stray ";" ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91615]: Revision status changed
User "^demon" changed the status of MediaWiki.r91615. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91615#c0 Commit summary: * (bug 29481) Add German namespace names to LQT ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91516]: Revision status changed
User "^demon" changed the status of MediaWiki.r91516. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91516#c0 Commit summary: Don't use an example query that gives a warning ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91619]: Revision status changed
User "Krinkle" changed the status of MediaWiki.r91619. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91619#c0 Commit summary: (bug 23086) AbuseFilter config diff date and time should use user preference instead of UTC ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91617]: New comment added
User "Kaldari" posted a comment on MediaWiki.r91617. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91617#c19291 Commit summary: moving DB function into DB class and giving functions more logical names Comment: This rev also added banner assignment and weight logging to the campaign logging system. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91608]: New comment added
User "Brion VIBBER" posted a comment on MediaWiki.r91608. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91608#c19290 Commit summary: * (bug 28626) Validate JavaScript files and pages loaded via ResourceLoader before minification, protecting separate modules from interference This is possibly not perfect but seems to serve for a start; follows up on r91591 that adds JSMin+ to use it in some unit tests. May want to adjust some related bits. - $wgResourceLoaderValidateJs on by default (can be disabled) - when loading a JS file through ResourceLoaderFileModule or ResourceLoaderWikiModule, parse it using JSMinPlus's JSParser class. If the parser throws an exception, the JS code of the offending file will be replaced by a JS exception throw listing the file or page name, line number (in original form), and description of the error from the parser. - parsing results are cached based on md5 of content to avoid re-parsing identical text - for JS pages loaded via direct load.php request, the parse error is thrown and visible in the JS console/error log Issues: - the primary use case for this is when a single load.php request implements multiple modules via mw.loader.implement() -- the loader catches the exception and skips on to the next module (good) but doesn't re-throw the exception for the JS console. It does log to console if present, but it'll only show up as a regular debug message, not an error. This can suppress visibility of errors in a module that's loaded together with other modules (such as a gadget). - have not done performance testing on the JSParser - have not done thorough unit testing with the JSParser Comment: There could perhaps be some benefit to logging if we're attempting to detect bad .js files creeping into source. For user JS it's probably unnecessary noise to record that. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] ResourceLoader JavaScript validation on trunk (bug 28626)
On Wed, Jul 6, 2011 at 3:18 PM, K. Peachey wrote: > How is JSMin+ different to the plain JSMin that we had and was removed > due to licensing conflicts? > It's a different program, written by different people, based on code from another unrelated project, under a different license. "Open Source is a wonderful thing; we use it every day and in this case it would be a waste if we were the only one to benefit from the hard work of others. We dubbed our little project "JSMin+" because essentially it acts as Douglas Crockford's JSMin but is far less restrictive, and released it under the same MPL/GPL/LGPL tri-license as the original Narcissus code." http://crisp.tweakblogs.net/blog/1665/a-new-javascript-minifier-jsmin+.html -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [Wikimedia r259]: Revision status changed
User "Awjrichards" changed the status of Wikimedia.r259. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/259#c0 Commit summary: Command-line wrapper should exit with an error if the processor execute returns false. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91557]: Revision status changed
User "^demon" changed the status of MediaWiki.r91557. Old Status: new New Status: reverted Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91557#c0 Commit summary: Revert r91426 and followups r91427, r91430: Breaks Gallery-related parser tests ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91598]: Revision status changed
User "^demon" changed the status of MediaWiki.r91598. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91598#c0 Commit summary: * Removed isPatrollable(); unused * Fixed comment ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91613]: Revision status changed
User "^demon" changed the status of MediaWiki.r91613. Old Status: new New Status: deferred Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91613#c0 Commit summary: Adding directory and work for vandal_conversion ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] ResourceLoader JavaScript validation on trunk (bug 28626)
How is JSMin+ different to the plain JSMin that we had and was removed due to licensing conflicts? (See: http://lists.wikimedia.org/pipermail/wikitech-l/2011-January/051308.html https://bugzilla.wikimedia.org/show_bug.cgi?id=26791) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91608]: New comment added
User "Nikerabbit" posted a comment on MediaWiki.r91608. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91608#c19289 Commit summary: * (bug 28626) Validate JavaScript files and pages loaded via ResourceLoader before minification, protecting separate modules from interference This is possibly not perfect but seems to serve for a start; follows up on r91591 that adds JSMin+ to use it in some unit tests. May want to adjust some related bits. - $wgResourceLoaderValidateJs on by default (can be disabled) - when loading a JS file through ResourceLoaderFileModule or ResourceLoaderWikiModule, parse it using JSMinPlus's JSParser class. If the parser throws an exception, the JS code of the offending file will be replaced by a JS exception throw listing the file or page name, line number (in original form), and description of the error from the parser. - parsing results are cached based on md5 of content to avoid re-parsing identical text - for JS pages loaded via direct load.php request, the parse error is thrown and visible in the JS console/error log Issues: - the primary use case for this is when a single load.php request implements multiple modules via mw.loader.implement() -- the loader catches the exception and skips on to the next module (good) but doesn't re-throw the exception for the JS console. It does log to console if present, but it'll only show up as a regular debug message, not an error. This can suppress visibility of errors in a module that's loaded together with other modules (such as a gadget). - have not done performance testing on the JSParser - have not done thorough unit testing with the JSParser Comment: No non-js logging yet? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91606]: Revision status changed
User "Nikerabbit" changed the status of MediaWiki.r91606. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91606#c0 Commit summary: Fix trailing whitespace ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] ResourceLoader JavaScript validation on trunk (bug 28626)
Some of you may have found that ResourceLoader's bundled & minified JavaScript loads can be a bit frustrating when syntax errors creep into your JavaScript code -- not only are the line numbers reported in your browser of limited help, but a broken file can cause *all* JS modules loaded in the same request to fail[1]. This can manifest as for instance a jquery-using Gadget breaking the initial load of jquery itself because it gets bundled together into the same request. I've taken a copy of JSMin+ (MPL 1.1/GPL 2.0/LGPL 2.1 triple-license) to our includes/libs -- it's a JS minification library that had originally gotten knocked out of the running for merging due to being a bit slow, but has the advantage of coming with an actual JavaScript parser [2]. Only the parser is being used right now, in two places: - on the JavaScriptMinifier test cases to confirm that results are valid JS (should be extended to a fuzz tester, probably) - on each individual file loaded via ResourceLoaderFileModule or ResourceLoaderWikiModule, so we can throw a JavaScript exception with details of the parse error *with line numbers for the original input file* This can be disabled by turning off $wgResourceLoaderValidateJs, but I'm setting it on by default to aid testing. I'd like for folks to keep an eye out to make sure they don't get any false positive parse errors in real-world modules, and to see if there are any noticeable performance regressions. Like ResourceLoader's minification itself the validation parses are cached so shouldn't cause too much ongoing load, but it still takes some time. [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=28626 [2] http://crisp.tweakblogs.net/blog/1856/jsmin+-version-13.html -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91469]: Revision status changed
User "NeilK" changed the status of MediaWiki.r91469.
Old Status: new
New Status: ok
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91469#c0
Commit summary:
Fixing AFT bug 29721
* (bug 29721) Tooltips shouldn't stay or re-appear when going to view page
ratings and going back
Cause:
// Setup switch behavior
.find( '.articleFeedback-switch' ).click( function( e ) {
context.$ui.find( '.articleFeedback-visibleWith-' + $(this).attr( 'rel'
) )
.show()
.. since articleFeedback-rating-tooltip had this class (because it should be
hidden in the report), it was forced to be visible when going back to the form
thus ignoring the fact that it wasn't hidden because of the switch to 'report'
but because of the hover-event.
Fixed by seperating the visisbleWith-form/report element from the
"articleFeedback-rating-tooltip" element.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91466]: New comment added, and revision status changed
User "NeilK" changed the status of MediaWiki.r91466. Old Status: new New Status: ok User "NeilK" also posted a comment on MediaWiki.r91466. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91466#c19288 Commit summary: adjusting width of ArticleFeedback-tooltip container. - Previously much wider than the actual 5-star-rating-container, which was done as a middle way to have tooltips on one line, but due to the last rating-box not having any space to the right this in-between solution looked inconsistent. However when making it as wide as the 5-star-rating-container (11em) some tooltips will wrap three lines: http://i.imgur.com/HHbGW.png For now made the width equal to that 11em + 1em = 12em where 1em is the margin between the boxes so it's still wider and won't cause tooltips to span 3 lines, and still not underneath other rating boxes either. This solution is better than what it was but not ideal and especially when i18n comes in, it's simply unacceptable. This will probably be a moot point when the widget is redesigned to take all the recent modifications into account. Comment: seems like a dubious solution (enclosing items of fixed pixel width with ems?) but Krinkle is aware of the issue so marking it okay for deploy ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85918]: Revision status changed
User "^demon" changed the status of MediaWiki.r85918. Old Status: fixme New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85918#c0 Commit summary: Improvements to handling of 'catastrophic' errors, like unsupported PHP versions, no MySQL functions, no LocalSettings, etc. * Fix parsing of the three major entry points (index.php, api.php, load.php) back to PHP 4.4.9. We don't care what happens if you actually try to run these files on old versions, but the entry files need to parse correctly. * consign /includes/templates/PHP4.php and /includes/templates/NoLocalSettings.php to the fiery pit of hell where they belong. * Prevent loading of any other files for PHP < 5. WebStart.php was rendered unparseable in PHP 4 by the introduction of try/catch blocks in r85327. * Die outright with a pretty error message on PHP < 5.2.3 as well as PHP 4. All versions of PHP below that throw parse errors of various sorts. * Reimplement wfDie() to provide an entry-point-dependent die-with-readable-error-message function (for instance, we want a pretty human-readable page in index.php, something wrapped in CSS/JS /*...*/ comment block in load.php, etc). * Standardise the appearance of the catastrophic errors thrown at the top of the stack with the ones lower down (exception-within-exception, etc). There isn't really a way to do this without duplication, AFAICT. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87271]: Revision status changed
User "DieBuche" changed the status of MediaWiki.r87271. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87271#c0 Commit summary: AFT Fixes * Linking page titles in the Dashboard at Special:ArticleFeedback * (bug 28125) Don't load the ext.articleFeedback module, nor initialize it on inexisting pages * ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [Wikimedia r204]: New comment added, and revision status changed
User "Awjrichards" changed the status of Wikimedia.r204. Old Status: fixme New Status: resolved User "Awjrichards" also posted a comment on Wikimedia.r204. Full URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/204#c19287 Commit summary: Actually started communicating with pfp's test system. Pulled out a bunch of reusable stuff and stashed it in the ActiveMQStompTest.class file (in fundraising-misc/test_resources/phpUnit_Classes), added comments, general cleanup. Comment: Ok - marking resolved. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [Wikimedia r198]: New comment added, and revision status changed
User "Awjrichards" changed the status of Wikimedia.r198. Old Status: fixme New Status: resolved User "Awjrichards" also posted a comment on Wikimedia.r198. Full URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/198#c19286 Commit summary: Fixing my unit test, adding a config.ini-dist, and fixing the thing it was testing as well. Story 149 in the 2011 fundraiser. Comment: All looks fixed in r254, marking resolved ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [Wikimedia r254]: Revision status changed
User "Awjrichards" changed the status of Wikimedia.r254. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/254#c0 Commit summary: followup r198 Based on comments: * Functionalizes some repeated logic in the log testing * rawurlencodes the values sent to pfp, for everything other than the password. Trying to rawurlencode the password caused us to not be able to log in at all. * If there is no HTTP_USER_AGENT, it no longer tries to curl a useragent. * handle_pending_transaction now expects three parameters (added gateway_txn_id) instead of decoding the json on the inside for it. * Replaces the exit(1) in fetch_payflow_transaction_status with a return false, and gracefully handles a false being returned. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91439]: New comment added
User "Jan Luca" posted a comment on MediaWiki.r91439. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91439#c19285 Commit summary: Add PLURAL-support Comment: I have copied it from my local svn checkout of MW. Maybe I forgot to change the encoding when I edit it to remove MW-specified thing form the constructor but my editors (Notepad++ and Eclipse) normally doesn't change the current encoding of the files. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91594]: Revision status changed
User "^demon" changed the status of MediaWiki.r91594. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91594#c0 Commit summary: Remove 'upload-wasdeleted' message. Its no longer used. Original feature was (accidently?) removed/broken in r57868 and then re-created using the message 'upload-recreate-warning' in r65339. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91106]: New comment added
User "Brion VIBBER" posted a comment on MediaWiki.r91106. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91106#c19284 Commit summary: Add wfUnserialize() wrapper around unserialize to prevent E_NOTICE and use it in ExifBitmap.php. There are probably many more places that could use this. This should fix Platonides' problem at r90421, but also added a check for $wgShowExif to prevent the test from failing. Comment: In this particular case we don't need generic validation/error handling for our expected cases, since there's a particular symbolic value we're looking for that indicates we shouldn't try to unserialize. :) But some others check to see if the item could be unserialized and then have some error-handling code (skip this item, recalculate, whatever). This might feel clearer with a wfUnserialize() wrapper that suppresses the notice on failure '''but throws an exception''' -- which can be caught by callers that need error recovery, or left to kill the process & log the exception for cases that weren't expecting it. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91589]: Revision status changed
User "^demon" changed the status of MediaWiki.r91589. Old Status: new New Status: deferred Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91589#c0 Commit summary: Minor fixes and follow-up to r91439 (Integration of PLURAL / MediaWiki language classes) * Names.php - Deleting now-redundant copy Names.php - Using languages/classes/Names.php instead - new "demo7" to test/demonstrate language names * Language.php - Re-fork Languages.php (it was probably copied from wikimedia-svn/viewvc, many mangling/encoding issues) - new "demo8" for MessagesFunctions * Minor fixes - line break in LICENSE.txt intro - Starting function documentation with 1-word type then the description (@foo type Description; @return object Instance of MessagesFunction) - Renaming /classes/ to /mw-classes/ to emphasize the fork - Moved getFallbacks.php to /scripts/ (Follow-up r90764) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91592]: Revision status changed
User "^demon" changed the status of MediaWiki.r91592. Old Status: new New Status: deferred Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91592#c0 Commit summary: Localisation updates for core and extension messages from translatewiki.net (2011-07-06 19:40:00 UTC) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91106]: New comment added
User "Bawolff" posted a comment on MediaWiki.r91106. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91106#c19283 Commit summary: Add wfUnserialize() wrapper around unserialize to prevent E_NOTICE and use it in ExifBitmap.php. There are probably many more places that could use this. This should fix Platonides' problem at r90421, but also added a check for $wgShowExif to prevent the test from failing. Comment: Or actually we do a validity check before the unserialize that would catch that, so I guess there's no way for there to be an E_NOTICE at this point, so nevermind what i just said :) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91106]: New comment added
User "Bawolff" posted a comment on MediaWiki.r91106. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91106#c19282 Commit summary: Add wfUnserialize() wrapper around unserialize to prevent E_NOTICE and use it in ExifBitmap.php. There are probably many more places that could use this. This should fix Platonides' problem at r90421, but also added a check for $wgShowExif to prevent the test from failing. Comment: Most other calls to unserialize are wrapped in wfSuppressErrors anyways. If bad data ever got into the db (which should not happen), it would generate an E_NOTICE. I'd prefer to leave the error suppression in, but don't have strong opinions. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91439]: Revision status changed
User "Krinkle" changed the status of MediaWiki.r91439. Old Status: fixme New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91439#c0 Commit summary: Add PLURAL-support ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91439]: New comment added, and revision status changed
User "Krinkle" changed the status of MediaWiki.r91439. Old Status: deferred New Status: fixme User "Krinkle" also posted a comment on MediaWiki.r91439. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91439#c19281 Commit summary: Add PLURAL-support Comment: The Language.php is mangled with messed up characters. I suspect you might have copied it from /viewvc/ and/or in a text editor with the wrong encoding set (not UTF-8). ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91537]: New comment added, and revision status changed
User "Raymond" changed the status of MediaWiki.r91537. Old Status: fixme New Status: ok User "Raymond" also posted a comment on MediaWiki.r91537. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91537#c19280 Commit summary: v0.8.0a It is possible to interpretate poll results and store user ratings / marks - as educational tool or as psychological tests. Step towards HMVC separation. Still is not fully tested and requires some polishing. Do not use in the production. Comment: Dunno why but http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/QPoll/i18n/qp.i18n.php?view=log&r1=91587&pathrev=91587 looks good. Thanks a lot. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91587]: New comment added
User "QuestPC" posted a comment on MediaWiki.r91587. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91587#c19279 Commit summary: Re-commiting QPoll v0.8.0a using svn move. This version is still in development and is not ready for production use. Documentation will follow after the bugfixes / feature additions. Comment: qp.i18n.php online diff now produces 400 bad request on me. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91537]: New comment added
User "QuestPC" posted a comment on MediaWiki.r91537. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91537#c19278 Commit summary: v0.8.0a It is possible to interpretate poll results and store user ratings / marks - as educational tool or as psychological tests. Step towards HMVC separation. Still is not fully tested and requires some polishing. Do not use in the production. Comment: Looking for online diff of i18n file now produces 400 bad request on me: http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/QPoll/i18n/qp.i18n.php?&pathrev=91587&r1=91586&r2=91587 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91584]: New comment added
User "Aaron Schulz" posted a comment on MediaWiki.r91584. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91584#c19277 Commit summary: * Call viewRedirect() on Article (WikiPage doesn't inherit this anymore) * Fixed bug 29734 - "categories on redirect pages don't appear on stable version" * Fixed globalArticleInstance() to account for RequestContext stuff which broke it (it was loading the pre-redirected title) * Renamed $parserOptions vars for briefity Comment: Tagged for porting to 1.18. Note that the change to account for WikiPage doesn't effect 1.18. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91537]: New comment added
User "QuestPC" posted a comment on MediaWiki.r91537. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91537#c19276 Commit summary: v0.8.0a It is possible to interpretate poll results and store user ratings / marks - as educational tool or as psychological tests. Step towards HMVC separation. Still is not fully tested and requires some polishing. Do not use in the production. Comment: Recommitted with svn move in r91587. I hope it fits, probably cannot do better. It is after major refactoring so the diffs will be large anyway. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [Wikimedia r204]: New comment added
User "Khorn (WMF)" posted a comment on Wikimedia.r204. Full URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/204#c19275 Commit summary: Actually started communicating with pfp's test system. Pulled out a bunch of reusable stuff and stashed it in the ActiveMQStompTest.class file (in fundraising-misc/test_resources/phpUnit_Classes), added comments, general cleanup. Comment: Actually: We can't really reuse anything in its current state: The processor only reads transactions. This handles writing them from a test, so the processor has something testable to read. In the future, it may be useful to write a pfp connection library and have everything reference that code, but that seems like new development. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90741]: Revision status changed
User "^demon" changed the status of MediaWiki.r90741. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90741#c0 Commit summary: Fixed silly test bug ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91348]: Revision status changed
User "^demon" changed the status of MediaWiki.r91348. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91348#c0 Commit summary: Removed some dead code (useless since r87806) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91512]: Revision status changed
User "^demon" changed the status of MediaWiki.r91512. Old Status: new New Status: deferred Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91512#c0 Commit summary: + _readme.txt ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91106]: New comment added, and revision status changed
User "Brion VIBBER" changed the status of MediaWiki.r91106. Old Status: new New Status: resolved User "Brion VIBBER" also posted a comment on MediaWiki.r91106. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91106#c19274 Commit summary: Add wfUnserialize() wrapper around unserialize to prevent E_NOTICE and use it in ExifBitmap.php. There are probably many more places that could use this. This should fix Platonides' problem at r90421, but also added a check for $wgShowExif to prevent the test from failing. Comment: I took out wfUnserialize() and the call to it in r91581. The tweak to disable the exif tests when required libraries are unavailable is kept. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90194]: Revision status changed
User "^demon" changed the status of MediaWiki.r90194. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90194#c0 Commit summary: Fixes for r90105, r90193: * Actually removed $wgProto. * Per Aryeh's suggestions on the future of $wgServer: made $wgServer detection in DefaultSettings.php more permanent by merging it with the new code from r90105. This means that bug 14977 is properly fixed now. * Require entry points to set up the autoloader before including DefaultSettings.php. Comments on bug 14977 indicate that at some point in the past, this may have broken something. Anything that breaks now should just be fixed, we need the autoloader. Tested the most common entry points. * Since the detection code has moved from Installer to WebRequest, I also moved the relevant test file and updated the test. The function under test is now public static, so r90154 is superseded. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91575]: New comment added
User "IAlex" posted a comment on MediaWiki.r91575. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91575#c19273 Commit summary: Move wfShowingResultsNum() back into SpecialSearch where it belongs. No need for a global function for something thats only used once in core or extensions Comment: \o/ ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
