[MediaWiki-CodeReview] [MediaWiki r91817]: New comment added
User IAlex posted a comment on MediaWiki.r91817. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91817#c19415 Commit summary: Now that the hooks ArticleDelete and ArticleDeleteComplete are called from WikiPage::doDeleteArticle() and not anymore from Article::doDelete(), let's call the former and handle ourself the output Comment: Done in r91860. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91749]: New comment added
User F.trott posted a comment on MediaWiki.r91749. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91749#c19416 Commit summary: r86603 : Updating module name of mediawiki.legacy.edit in SemanticForms Extension Comment: Do we need a version switch here? SF still states compatibility back to 1.15. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91749]: New comment added
User DieBuche posted a comment on MediaWiki.r91749. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91749#c19417 Commit summary: r86603 : Updating module name of mediawiki.legacy.edit in SemanticForms Extension Comment: We're already inside a pseudo version switch: if ( method_exists( $wgOut, 'addModules' ) eg. if 1.17 or later ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91548]: New comment added
User Schnark posted a comment on MediaWiki.r91548. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91548#c19418 Commit summary: Redoing r87173 with scrollbars instead of word-wrap per CR Comment: Look at http://translatewiki.net/wiki/MediaWiki:Common.css versus http://translatewiki.net/wiki/MediaWiki:Common.css?useskin=monobook with a window of a width of 800px. In Monobook you have the horizontal scrollbar at the bottom of the window, but in Vector this scrollbar is at the end of the page. So if you want to scroll right to see all the css you first have to scroll down to the scrollbar, scroll right and then up again, which isn't very user-friendly. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91749]: New comment added
User F.trott posted a comment on MediaWiki.r91749. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91749#c19419 Commit summary: r86603 : Updating module name of mediawiki.legacy.edit in SemanticForms Extension Comment: Yes, but it does not cover the switch from mediawiki.legacy.edit to mediawiki.action.edit, right? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91548]: New comment added
User DieBuche posted a comment on MediaWiki.r91548. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91548#c19420 Commit summary: Redoing r87173 with scrollbars instead of word-wrap per CR Comment: You can also scroll by selecting dragging the text to the right. Not perfect though... ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91749]: New comment added
User DieBuche posted a comment on MediaWiki.r91749. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91749#c19421 Commit summary: r86603 : Updating module name of mediawiki.legacy.edit in SemanticForms Extension Comment: Right. I'll add one later ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] thumbnail generation for Extension:OggHandler
* Michael Dale md...@wikimedia.org [Fri, 08 Jul 2011 10:52:52 -0700]: I recommend using the static binaries hosted on firefogg or if you want to compile it your self using the build tools provided there: http://firefogg.org/nightly/ Hi Michael, thank you for the tips. Static binary for ffmpeg wasn't completely static, it was linked against different version of libc, so it refused to run. Maybe that binary was compiled in different distro. However, ffmpeg2theora.linux from the same page worked just fine in CentOS 5.6. Also I would suggest you take a look at TimedMediahandler as an alternative to oggHandler it has a lot more features such as WebM, timed text, and transcoding support. http://www.mediawiki.org/wiki/Extension:TimedMediaHandler This extension is more complicated. Forutunately it has a better README file - there are recommended configure options for ffmpeg compilation which I was looking for. It was not easy to compile ffmpeg with recommended transcoding options, but I finally managed to do that. However README should mention that the user should run php update.php, otherwise extension complains about missing DB tables. Is it really necessary to have as much as 6GB of shell memory? Because I have only 1GB at this shell. A live install is on prototype if you want to play around with it: http://prototype.wikimedia.org/tmh/ The samples are nice. If you run into any issue, please report them on the bug tracker or directly to me. https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensionscomponent=TimedMediaHandler Yes, I have an issue - I run MediaWiki 1.17.0 (r6), however it seems that trunk version of TimedMediaHandler is already designated for improved 1.18 Skin / Linker: 2011/07/11 15:04:06 [error] 21984#0: *1006 FastCGI sent in stderr: PHP Warning: array_merge(): Argument #1 is not an array in /var/www/wiki/universe/extensi ons/TimedMediaHandler/TimedMediaHandler.hooks.php on line 87 while reading response header from upstream, client: 193.233.48.78, server: x.x.x.x, reque st: GET /load.php?debug=falselang=rumodules=startuponly=scriptsskin=universe* HTTP/1.1, upstream: fastcgi://127.0.0.1:9000, host: x.x.x.x, re ferrer: http://x.x.x.x/index.php/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:Version; 2011/07/11 15:04:07 [error] 21984#0: *1009 FastCGI sent in stderr: PHP Warning: array_merge(): Argument #1 is not an array in /var/www/wiki/universe/extensi ons/TimedMediaHandler/TimedMediaHandler.hooks.php on line 87 while reading response header from upstream, client: 193.233.48.78, server: x.x.x.x, reque st: GET /index.php/skins/universe/images/vakosha.png HTTP/1.1, upstream: fastcgi://127.0.0.1:9000, host: x.x.x.x, referrer: http://x.x.x.x/ index.php/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:Version One probably should create new Linker(), that's how I do in my Extension:QPoll (although I haven't checked it with 1.18 yet). TimedMediaHandler is r91852. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] thumbnail generation for Extension:OggHandler
I run MediaWiki 1.17.0 (r6) and use TimedMediaHandler is r91852. I always prefer to run stable MW and latest extensions. Is it wrong idea? 2011/07/11 15:12:51 [error] 21984#0: *1029 FastCGI sent in stderr: PHP Warning: array_merge(): Argument #1 is not an array in /var/www/wiki/universe/extensi ons/TimedMediaHandler/TimedMediaHandler.hooks.php on line 87 PHP Fatal error: Using $this when not in object context in /var/www/wiki/universe/includes/Linker.php on line 175 while reading response header from upstrea m, client: 193.233.48.78, server: 94.127.69.133, request: GET /index.php/%D0%A4%D0%B0%D0%B9%D0%BB:Apollo_15_launch.ogg HTTP/1.1, upstream: fastcgi://127.0. 0.1:9000, host: 94.127.69.133, referrer: http://94.127.69.133/index.php/%D0%A1%D0%BB%D1%83%D0%B6%D0%B5%D0%B1%D0%BD%D0%B0%D1%8F:ListFiles; The wiki was running just fine, some weidness appeared when I've installed UploadWizard, but now I've disabled it. Now it fails again. Interesting, why Special:Version and Special:ListFiles fail, they used to work before. I need a time to investigate. Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91854]: New comment added
User Raymond posted a comment on MediaWiki.r91854. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91854#c19422 Commit summary: SocialProfile: add a special page, Special:GenerateTopUsersReport, to generate the report of the users who earned the most points during the past week or month. This is the only way to update the points_winner_weekly and points_winner_monthly columns in the user_stats table. This requires that the user_points_archive, user_points_monthly and user_points_weekly tables exist in the database; SocialProfile does not yet ship with the schemas for those tables, but I'll try to fix that soon-ish. To access Special:GenerateTopUsersReport, you need the generatetopusersreport user right, which isn't given to any user group by default. Code from http://trac.wikia-code.com/browser/wikia/trunk-1.15/extensions/wikia/UserStats/SpecialGenerateTopUserReport.php with tweaks and cleanup by me Comment: I do not know this extension, so take it as suggestions only: * 'user-stats-weekly-win-congratulations' and others needs PLURAL support for $2 extra points * Numbers should be run through $wgLang-formatNum() or $wgContLang-formatNum() * Add code$wgAvailableRights[] = 'generatetopusersreport';/code * Add a special page alias file ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] thumbnail generation for Extension:OggHandler
Yes, locally patched both issues, now runs fine. $wgExcludeFromThumbnailPurge is not defined in 1.17, made a check. BTW, it is a bit evil to exclude some extensions from Purge. Maybe there should be another action Superpurge? Linker::link() was called statically in TranscodeStatusTable class. Created new Linker() and now it works. I haven't committed into svn, don't know if anyone cares of backcompatibility. BTW, if I'd was an leading developer (who makes decisions), I'd probably make MW 1.16 an LTS (long time support) version for legacy setups and extensions.. Though maybe that is unneeded (too much of burden for non-profit organization). Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikimedia engineering report for June 2011
On 7/1/2011 11:19 AM, Guillaume Paumier wrote: *Academic publications authentication proxy* --- Chad Horohoe http://www.mediawiki.org/wiki/User:%5Edemon started a project whose goal is to allow selected Wikimedians to access third-party academic publishing sites to help with content verifiability http://en.wikipedia.org/wiki/Wikipedia:Verifiability. The authentication challenges this entails are not trivial; Ryan Lane http://www.mediawiki.org/wiki/User:Ryan_lane is also involved in this project, particularly because of his previous experience with OpenID (which may be used as a mechanism for tying to CentralAuth). ^--- This burns me up. It seems to me that organizations that charge $1000's of dollars for access to content should not be getting free publicity from organizations like Wikipedia. They deserve to vanish in obscurity, dry up and blow away in the winds of history. Governments pay $50,000 or $100,000 to have a research paper written, but they can't seem to find the $5 it would take to make the paper available for free indefinitely. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91882]: New comment added
User Reedy posted a comment on MediaWiki.r91882.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91882#c19423
Commit summary:
Added Global statistics support
Comment:
1 very minor issue is
pre
if(! $is_new_rating ) {
/pre
Should really be
pre
if( !$is_new_rating ) {
/pre
The other is the usage of empty... [[Manual:Coding_conventions#PHP_pitfalls]]
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91882]: New comment added
User Yuvipanda posted a comment on MediaWiki.r91882. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91882#c19424 Commit summary: Added Global statistics support Comment: Ow, isn't !$ kinda weird? Is there any particular reasoning for this? Doesn't the ! get lost with the $? /whine ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91882]: New comment added
User ^demon posted a comment on MediaWiki.r91882. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91882#c19425 Commit summary: Added Global statistics support Comment: No, it's the way we format our code :) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91627]: New comment added
User ^demon posted a comment on MediaWiki.r91627. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91627#c19426 Commit summary: Initial import of GSoC project. Comment: This is the review of your proposed schema: * I see you used my old mwreleases schema for tracking MediaWiki core releases. Good, because I liked it :) * For all the tables: we could probably drop the (8) and (10) for our id columns. They're unsigned anyway. * Also, adding some more comments about what the columns do will help answer questions too. * Looking at 'extensionmanagement', there's a couple of things: ** We try to name all columns in a table with the same prefix, so it would be good to rename current_desc and current_authors to begin with ext_ ** Is current_desc supposed to be a short one or two sentence summary of the extension? If so then that seems fine. ** current_authors is a BLOB. How were you planning on storing the information here? Presumably we'd be wanting to store user_ids of the Mediawiki.org users who are maintaining an extension. If that's the case, I would suggest moving this to its own table called extension_authors or similar. This would let you have columns like (ext_id,user_id) which is [[w:Third normal form|good form]] in database design and allows you to do queries like Name all of the extensions user 123 helps maintain. Still having a column for the primary maintainer/owner in this table does sound like a good idea though * Couple of notes on 'extensionmanagement_versions': ** We don't use foreign keys in Mysql in MediaWiki. Enforce this logic in your code. ** What is version_status tracking? ** version_release_date should be varbinary(32) like I did in mwreleases. ** is version_directory the directory name in SVN? ** version_entrypoint -- I'm pretty sure this is for tracking what entry point we would put in LocalSettings for enabling an extension. Since 1.17, we've tried very hard to enforce the ''extensions/FooBar/FooBar.php'' naming convention, so I'm not sure this is really necessary to track. This is a great first draft though, thanks for getting it into SVN! ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91882]: New comment added
User Yuvipanda posted a comment on MediaWiki.r91882. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91882#c19427 Commit summary: Added Global statistics support Comment: Dammit, whining doesn't seem to get me anywhere. Will fix. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89165]: New comment added
User Yuvipanda posted a comment on MediaWiki.r89165. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89165#c19428 Commit summary: Added entry for alias file Comment: http://xkcd.com/583/ ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89165]: New comment added
User Bawolff posted a comment on MediaWiki.r89165. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89165#c19429 Commit summary: Added entry for alias file Comment: Do you have [[Manual:$wgDevelopmentWarnings]] on? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91854]: New comment added
User Jack Phoenix posted a comment on MediaWiki.r91854. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91854#c19430 Commit summary: SocialProfile: add a special page, Special:GenerateTopUsersReport, to generate the report of the users who earned the most points during the past week or month. This is the only way to update the points_winner_weekly and points_winner_monthly columns in the user_stats table. This requires that the user_points_archive, user_points_monthly and user_points_weekly tables exist in the database; SocialProfile does not yet ship with the schemas for those tables, but I'll try to fix that soon-ish. To access Special:GenerateTopUsersReport, you need the generatetopusersreport user right, which isn't given to any user group by default. Code from http://trac.wikia-code.com/browser/wikia/trunk-1.15/extensions/wikia/UserStats/SpecialGenerateTopUserReport.php with tweaks and cleanup by me Comment: Thanks for the code review! *'''user-stats-weekly-win-congratulations' and others needs PLURAL support for $2 extra points'' **can't think of why, at least when it comes to English and Finnish, although some funny sysadmin might set it so that a weekly win earns you one point... *''Numbers should be run through $wgLang-formatNum() or $wgContLang-formatNum()'' **Probably the former, can't think of a good reason why they should be in content language. Then again other parts of the code than just GenerateTopUsersReport.php use stuff like raw number_format() and whatnot; I must say that I wasn't even aware of Language::formatNum(). :-) *''Add code$wgAvailableRights[] = 'generatetopusersreport';/code'' **I thought of this, too, but I couldn't find a suitable place for that declaration since UserStats doesn't have a setup file like UserProfile (UserProfile.php) and others have. I didn't see any brokenness on my test wiki, so I'll assume that it isn't horribly important. *''Add a special page alias file'' **No need to add a separate file, this can be done by adding GenerateTopUsersReport to SocialProfile/SocialProfile.alias.php. There are plenty of things to be done with this special page (for example, the generated reports use the American MM/DD/ date format whereas the Finnish date format is DD.MM.), but I just wanted to commit it so that it doesn't get lost now that I finally got it working. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] thumbnail generation for Extension:OggHandler
Thanks for this thread, Please do commit fixes for 1.17, If not obvious already I have really only been targeting trunk. While the extension has been around since before 1.16, it would be very complicated to restore the custom resource loader it was using before there was a resource loader in core. In terms of Superpurge, that is essentially what we do with the transcode status table on the image page that lets users with the given permission purge the transcodes. We did not want to make it too too easy to purge transcodes cuz once purged a video could be inaccessible for devices / browsers that only had webm or only had ogg support, until the file was retranscoded. --michael On 07/11/2011 04:48 AM, Dmitriy Sintsov wrote: Yes, locally patched both issues, now runs fine. $wgExcludeFromThumbnailPurge is not defined in 1.17, made a check. BTW, it is a bit evil to exclude some extensions from Purge. Maybe there should be another action Superpurge? Linker::link() was called statically in TranscodeStatusTable class. Created new Linker() and now it works. I haven't committed into svn, don't know if anyone cares of backcompatibility. BTW, if I'd was an leading developer (who makes decisions), I'd probably make MW 1.16 an LTS (long time support) version for legacy setups and extensions.. Though maybe that is unneeded (too much of burden for non-profit organization). Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r88815]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r88815. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88815#c0 Commit summary: * Check existence in correct language * Simplify a bit existence check ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90256]: New comment added, and revision status changed
User Bawolff changed the status of MediaWiki.r90256. Old Status: fixme New Status: new User Bawolff also posted a comment on MediaWiki.r90256. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90256#c19431 Commit summary: (follow-up r86567) per CR rename the class JpegOrTiffHandler to ExifBitmapHandler. Comment: Added tests in r91885 - resetting to new and removing keyword. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91784]: New comment added, and revision status changed
User Aaron Schulz changed the status of MediaWiki.r91784. Old Status: new New Status: ok User Aaron Schulz also posted a comment on MediaWiki.r91784. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91784#c19432 Commit summary: Pass the User object to RecentChange::doMarkPatrolled() instead of relying on $wgUser Comment: InterwikiIntegrationRecentChange.php should be updated. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88727]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r88727. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88727#c0 Commit summary: Simplify message existence checks by using wfMessage() instead of wfEmptyMsg() ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91807]: Revision status changed
User Catrope changed the status of MediaWiki.r91807. Old Status: new New Status: deferred Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91807#c0 Commit summary: Localisation updates for core and extension messages from translatewiki.net (2011-07-09 19:33:00 UTC) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91886]: New comment added
User Reedy posted a comment on MediaWiki.r91886. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91886#c19433 Commit summary: (bug 29797) Error: Tried to load block with invalid type when subpages are disabled for user pages. Patch by Jarry1250 Comment: pre === --- trunk/phase3/CREDITS(revision 91885) +++ trunk/phase3/CREDITS(revision 91886) @@ -97,6 +97,7 @@ * FunPika * Harry Burt * Ireas +* Jarry1250 * Jaska Zedlik * Jeremy Baron * Jidanni /pre Jarry1250 == Harry Burt ;) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90687]: Revision status changed
User Catrope changed the status of MediaWiki.r90687. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/90687#c0 Commit summary: move comment ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91854]: New comment added
User Raymond posted a comment on MediaWiki.r91854.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91854#c19434
Commit summary:
SocialProfile: add a special page, Special:GenerateTopUsersReport, to generate
the report of the users who earned the most points during the past week or
month.
This is the only way to update the points_winner_weekly and
points_winner_monthly columns in the user_stats table. This requires that the
user_points_archive, user_points_monthly and user_points_weekly tables exist in
the database; SocialProfile does not yet ship with the schemas for those
tables, but I'll try to fix that soon-ish.
To access Special:GenerateTopUsersReport, you need the generatetopusersreport
user right, which isn't given to any user group by default.
Code from
http://trac.wikia-code.com/browser/wikia/trunk-1.15/extensions/wikia/UserStats/SpecialGenerateTopUserReport.php
with tweaks and cleanup by me
Comment:
* 'user-stats-weekly-win-congratulations' and others needs PLURAL support for
$2 extra points
** can't think of why, at least when it comes to English and Finnish, although
some funny sysadmin might set it so that a weekly win earns you one point...
*** Keep in mind that some languages, like Russian, has 4-5 plural forms,
partly very complex.
* Numbers should be run through $wgLang-formatNum() or $wgContLang-formatNum()
** Probably the former, can't think of a good reason why they should be in
content language.
*** Because you call content: codewfMsgExt(
user-stats-{$period}-win-congratulations, array( 'parsemag', 'content' ),
.../code
* Add a special page alias file
** No need to add a separate file, this can be done by adding
GenerateTopUsersReport to SocialProfile/SocialProfile.alias.php
*** Ah, I missed this.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91030]: Revision status changed
User Catrope changed the status of MediaWiki.r91030. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91030#c0 Commit summary: InstantCommons files also have -1 as page id; handle this case when dealing with filename uniqueness. (Did this change recently?!) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91886]: New comment added
User SPQRobin posted a comment on MediaWiki.r91886. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91886#c19435 Commit summary: (bug 29797) Error: Tried to load block with invalid type when subpages are disabled for user pages. Patch by Jarry1250 Comment: Ah, didn't know that, fixed in r91887 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91525]: Revision status changed
User Catrope changed the status of MediaWiki.r91525. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/91525#c0 Commit summary: (part of bug 24692) Make RTL versions of the arrows at the top of UploadWizard ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91887]: Revision status changed
User Reedy changed the status of MediaWiki.r91887. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91887#c0 Commit summary: Jarry1250 = Harry Burt, per Reedy on r91886 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91074]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91074. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91074#c0 Commit summary: * Modified some methods of SpecialWatchlist to be non-static so that they can use $this-getTitle() instead of having to pass the special page's name * Use context variable instead of global ones * Really use countItems() * Updated InterwikiIntegration for these changes; I'm not keeping b/c since anyway that extension was broken until now because SpecialWatchlist::countItems() was static and SpecialInterwikiWatchlist::countItems() not (was throwing fatal error) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91875]: New comment added
User Siebrand posted a comment on MediaWiki.r91875.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91875#c19436
Commit summary:
* (bug 16699) {{#language:}} accepts second parameter to specify the language in
which the language name is wanted. Coverage depends on the cldr extension.
Comment:
Please add parameter documentation for language().
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89005]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r89005. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89005#c0 Commit summary: Refactor MessageBlobStore::updateModule() to remove the multi-language update behavior. Instead of updating all language's blobs at once, it now only updates the requested language. This, in combination with the bug fixed in r89001, was what caused the UploadWizard timeouts on the cluster ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91461]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91461. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91461#c0 Commit summary: Override IndexPager::getTitle() in AlphabeticPager instance of core to not rely on $wgTitle ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91889]: Revision status changed
User Reedy changed the status of MediaWiki.r91889. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91889#c0 Commit summary: Fix MIME types of images added in r91525 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91551]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91551. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91551#c0 Commit summary: Override Pager::getTitle() in core subclasses of ReverseChronologicalPager that don't have it ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91677]: New comment added
User Aaron Schulz posted a comment on MediaWiki.r91677. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91677#c19437 Commit summary: * Fixed comment * Wrap arround RequestContext::msg() instead of doing that all that stuff once more Comment: Ah, my SVN copy was outdated ;) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91677]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91677. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91677#c0 Commit summary: * Fixed comment * Wrap arround RequestContext::msg() instead of doing that all that stuff once more ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91800]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91800. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91800#c0 Commit summary: Call doMarkPatrolled() on the RecentChange object instead of calling RecentChange::markPatrolled() that will create a second instance ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89001]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r89001. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89001#c0 Commit summary: Fix issue on the live site causing RL requests for ext.uploadWizard to consistently take more than 5 seconds: the cache freshness check was failing all the time because ext.uploadWizard listed some messages twice, and duplicates were filtered on the left-hand side of the !== comparison (implicitly, because they're array keys), but not on the right-hand side. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88705]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r88705. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88705#c0 Commit summary: Rewriting mw.loader test suite. The previous one didn't work properly in IE6-IE8. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91875]: New comment added
User Nikerabbit posted a comment on MediaWiki.r91875.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91875#c19438
Commit summary:
* (bug 16699) {{#language:}} accepts second parameter to specify the language in
which the language name is wanted. Coverage depends on the cldr extension.
Comment:
http://www.mediawiki.org/w/index.php?title=Help:Magic_wordsdiff=416834oldid=413662
?
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91844]: New comment added
User Brion VIBBER posted a comment on MediaWiki.r91844. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91844#c19439 Commit summary: Add test suite for jquery.byteLimit: - Tests to verify that the byteLength does not exceed the byteLimit when inserting more characters - Tests to verify that it doesn't prevent too early (ie. if limit is 10 and we insert 20 characters, there should be 10 characters in the input field). This test suite has exposed that the latter is currently broken. jquery.byteLimit is preventing characters to be added as soon as byteLength(currentValue) + 3 is more than the given limit. (Follows-up r86698, r91148) Comment: r91891 fixes the test cases, including a correction for the last test which actually ends up with a length of 12 as there are two more ASCII chars to be inserted. Note that I'm leaving that bug open as there seem to be some general issues, and further testing is required to see how things actually work, especially with non-BOM characters and funky input method stuff. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91875]: New comment added
User Siebrand posted a comment on MediaWiki.r91875.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91875#c19440
Commit summary:
* (bug 16699) {{#language:}} accepts second parameter to specify the language in
which the language name is wanted. Coverage depends on the cldr extension.
Comment:
Then either add that URL/rev to the source code, or document it in the source
code, too?
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88646]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r88646. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88646#c0 Commit summary: * Simplify message existence checks by using wfMessage() instead of wfMsg() with wfEmptyMsg() * Fixed one check in Skin::addToSidebarPlain() that used user language for existence and content language for message's content * Changed SkinTemplate::buildContentNavigationUrls() to use Title::getDefaultMessageText() instead of wfEmptyMsg() ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91830]: Revision status changed
User Siebrand changed the status of MediaWiki.r91830. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91830#c0 Commit summary: Tweak extension credits, add description message Add extension to Translatewiki, ping r87714 to inform the author ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91875]: New comment added
User Nikerabbit posted a comment on MediaWiki.r91875.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91875#c19441
Commit summary:
* (bug 16699) {{#language:}} accepts second parameter to specify the language in
which the language name is wanted. Coverage depends on the cldr extension.
Comment:
I fail to see the point of documenting that function. It's only called by the
parser.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91844]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r91844. Old Status: new New Status: resolved User Brion VIBBER also posted a comment on MediaWiki.r91844. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91844#c19442 Commit summary: Add test suite for jquery.byteLimit: - Tests to verify that the byteLength does not exceed the byteLimit when inserting more characters - Tests to verify that it doesn't prevent too early (ie. if limit is 10 and we insert 20 characters, there should be 10 characters in the input field). This test suite has exposed that the latter is currently broken. jquery.byteLimit is preventing characters to be added as soon as byteLength(currentValue) + 3 is more than the given limit. (Follows-up r86698, r91148) Comment: r91894 fixes another bug in the test cases; using the array operator to get a char from a string (codestr[i]/code) doesn't work in IE6 or IE 7, which caused the simulated keypress stuff to fail to update the field properly. Switching to codestr.charAt(i)/code fixes this right up! ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91894]: Revision status changed
User Krinkle changed the status of MediaWiki.r91894. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91894#c0 Commit summary: Followup r91844: fix jquery.byteLimit test cases on IE6, IE7 str[i] doesn't work on these older browsers; use str.charAt(i) instead. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91891]: Revision status changed
User Krinkle changed the status of MediaWiki.r91891. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91891#c0 Commit summary: * (bug 29804) Fix byte-length-limited fields to check the length of to-be-added char instead of hardcoding a possible length of 3. Since the Unicode code point of the character being inserted is passed with the keypress event, we can simply turn it into a string and toss it into jquery.byteLength to calculate the length in bytes. Also fixed a broken test case that had the wrong number of expected chars. Note that this will probably still not work right in many circumstances -- pastes, anything dealing with selection, and it's entirely possible that individual 'keypress' events might be totally unreliable when dealing with funky input methods. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88071]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r88071. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88071#c0 Commit summary: Follow-up r88054: Update messages.inc ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91857]: Revision status changed
User Krinkle changed the status of MediaWiki.r91857. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91857#c0 Commit summary: follow-up to r91853 - revising comments to explain the new logic, also guarding against javascript error in case of data.redirect being undefined for some reason ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88054]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r88054. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88054#c0 Commit summary: (bug 23002) Imagelinks table not updated after imagemove. The actual bug was inconsistent behaviour between imagelinks and pagelinks for redirects. * Parser now only adds the redirect source to imagelinks, like it does in pagelinks * ImagePage now shows the file redirects in-line with the normal The following pages link to this file: ** Added message linkstoimage-redirect ** Removed the separate file redirects section and removed associated message redirectstofile ** ImagePage::imageLinks will first fetch image links to the file, determine which are redirects, and if there are fewer links than the limit, fetch the redirect target links. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91853]: New comment added
User Krinkle posted a comment on MediaWiki.r91853.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91853#c19444
Commit summary:
Use more strict if-statement to decide whether to reload current page or
rebuild url.
- Extracting the current url without the hash-tag
- Building the target url without the hash-tag
- Wether the same or not, set window.location (this solves another bug [1])
- If the same, also call reload()
- Removing single-quotes from object literal / trailing spaces while at it
This is change is mainly to fix:
* (bug 29805) WikiLove should redirect to user talk view instead of reloading
if current page is not a normal view
[1]: Another minor bug fixed here is that in the case of reload() the hash-tag
wasn't set so the user would end up on top (instead of at the section) of a
refreshed talk page. By setting the hash tag regardless and refreshing after
that, it'll refresh including the hash tag.
Although I don't expect cross-browserness to be different from the previous
version, tested locally with 1.19-svn in Safari 5, Chrome 12 and Firefox 5.
Comment:
Note I left this part untouched (which made the additional check in the next
statement redundant)
pre
if ( data.error !== undefined ) {
$.wikiLove.showPreviewError( data.error.info );
return;
}
/pre
I guess that should probably be an 'is' instead of an 'is not', anyway, fixed
now by you in r91857.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] testing mobile browsers?
On Sat, Jul 9, 2011 at 2:30 AM, Ashar Voultoiz hashar+...@free.fr wrote: * Safari, Opera Mozilla for mobile : they are probably mostly the same as the desktop version. I have not found emulators for them. * Android : has an emulator. On my computer it is painfully slow and not usable for anything. * Blackberry : emulator is Windows only :-/ Would be great to enhance our testswarm with more browsers. Maybe we could contact those mobiles developers to connect to our testswarm? Note also that there'll be at least three distinct things we want to test on the mobile browsers: * JS browser interactive behavior _of MediaWiki_ * JS browser interactive behavior _of the alternate mobile view_ (MobileFrontend, on track to replace the current mobile. and m. gateways) * default redirection to the appropriate view based on device For the MediaWiki JS tests on Mobile Safari, Android default browser, Blackberry default browser, Opera Mobile, etc we should only need to add those browsers to the job submissions going into TestSwarm so it'll farm the tests out to any connected clients -- currently Krinkle manages how that's set up. However for the most part, Mobile Safari, default Android browser, Opera Mobile, and Firefox for Android should work _about the same_ as their desktop equivalents, with the same modern JavaScript engines etc. There will be some differences in JavaScript HTML support (for instance, the Android browser doesn't support SVG until 3.0) but this is unlikely to trip up much in the core JS tests. More relevant in most cases will probably be UI tests, like making sure that various links and buttons are in visible, clickable areas of the screen; we don't have any of these tests yet using QUnit. Anything related to MobileFrontend will need to have a test suite created for it; note that for less-capable devices, TestSwarm's client-side JavaScript system probably won't actually work (certainly it won't for Opera Mini!) Redirection tests again might need another test harness infrastructure. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91896]: Revision status changed
User Krinkle changed the status of MediaWiki.r91896. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91896#c0 Commit summary: Follow-up r91895: Call parent destructor as well, just to be safe. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] testing mobile browsers?
On Mon, Jul 11, 2011 at 11:40 AM, Brion Vibber br...@pobox.com wrote: default redirection to the appropriate view based on device I can tell you right now that Firefox for Android has never redirected to the mobile site for me. If you want more device/version details let me know... Steven ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Postmortem for the MediaWiki 1.17 release
On 07/07/11 03:42, Rob Lanphier wrote: http://live.gnome.org/ThreePointOne snip having clear deadlines for proposing new features, deadlines for features being done or pulled, and other date-risk mitigation strategies. Having a roadmap like Gnome is the way I am advocating. Another way I could consider is having a stable branch and only merge in stable/reviewed patches. After each merge you can either: - hold for more patches - release on live site - tag a release (beta, RC...) This path is probably as predictable as the first one. Its drawback is that new features might have less attention. Anyway, both ways are *very* far away from our wiki-way of handling /trunk/ (which is messy). -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Postmortem for the MediaWiki 1.17 release
On 07/07/11 03:42, Rob Lanphier wrote: we're probably too reliant on Tim to not only drive but execute many steps. snip Additionally, we will probably experiment with other team members (e.g. Chad) performing at least alpha or beta releases. This is actually a great way to train new people. Let Chad takes the release management cycle, make sure Tim is around though or next release he will have to be trained by Chad :-b -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] testing mobile browsers?
- Original Message - From: Brion Vibber br...@pobox.com * default redirection to the appropriate view based on device Please remember that some people with high-function browsers *want* the low-function results... and some people with *what your code thinks are low-function browsers* want the standard results; a user-controllable per-browser persistent cookie to override is a very nice touch here. 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
Re: [Wikitech-l] testing mobile browsers?
On Sat, Jul 9, 2011 at 7:30 PM, Ashar Voultoiz hashar+...@free.fr wrote: * Android : has an emulator. On my computer it is painfully slow and not usable for anything. I can connect to TestSwarm with the stock Android browser on 2.3 (though it's identifying it as 2.2) but it won't give me any tests to run. TestSwarm 'doesn't need my help' when I load it with Fennec 5 or Opera Mobile 11.1. -- Stephen Bain stephen.b...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] testing mobile browsers?
On Tue, Jul 12, 2011 at 5:59 AM, Stephen Bain stephen.b...@gmail.com wrote: TestSwarm 'doesn't need my help' when I load it with Fennec 5 or Opera Mobile 11.1. Though Opera does allow you to set the UA to mobile or desktop, and it will let me run tests when set to the desktop version. (Wikipedia doesn't give me the mobile site whatever the UA setting.) -- Stephen Bain stephen.b...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] testing mobile browsers?
On Mon, Jul 11, 2011 at 12:56 PM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Brion Vibber br...@pobox.com * default redirection to the appropriate view based on device Please remember that some people with high-function browsers *want* the low-function results... and some people with *what your code thinks are low-function browsers* want the standard results; a user-controllable per-browser persistent cookie to override is a very nice touch here. That's why there's a per-browser persistent cookie to override it, yes. :) (Not 100% all pretty yet, but I think it mostly works in the MobileFrontend version now. The live versions still just have the one-time flip-to-desktop the permanent-disable, which are both annoying limited.) -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91842]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91842. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91842#c0 Commit summary: * Changed dynamic calls to Linker methods into static ones * Also preferably pass a Language object instead of a Skin one or boolean indicating whether it's for content. No other calls to these methods in core or extensions. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91804]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91804. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91804#c0 Commit summary: Added Request::setLang() and RequestContext::setSkin(); the latter will clone the object and set the context on it. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91744]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91744. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91744#c0 Commit summary: Fix for r78786: make Special:Wantedpages includable again ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91862]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91862. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91862#c0 Commit summary: Override UsersPager::getTitle() in ActiveUsersPager ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91864]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91864. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91864#c0 Commit summary: Call Linker methods statically and removed the $mSkin member ___ 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:04 PM, Brion Vibber br...@pobox.com wrote: 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. Per feedback from TranslateWiki (yay testers!) I've disabled validation for JS modules coming from on-disk files; large libs like jQuery can hit the PHP memory limits if you're unlucky. This kills the load.php process, neatly defeating the purpose of validating the code. ;) Validation is still on by default for JS modules pulled from wiki pages -- which are editable and therefore what we really cared about to begin with. :) May still be nice to reduce the memory footprint of the syntax tree as it's being built, as it's likely a very inefficient structure by default. Gadgets that stuff big JS libraries into their pages are probably the most likely to still be able to fail this way. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r91859]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91859. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91859#c0 Commit summary: Removed print and render actions from the check: * print was removed in 86373 * render does not reach this point since it simply output the content without any part of the skin ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91820]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91820. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91820#c0 Commit summary: Disable feed mode when including the page. I know that there is already r87705 to address this, but this one is needed for the future. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91861]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91861. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91861#c0 Commit summary: Use getPageTitle() to set the page title instead of doing it manually ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91732]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r91732. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91732#c0 Commit summary: Create a new RequestContext to use its OutputPage and Skin members instead of messing with global ones ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r80612]: New comment added
User Siebrand posted a comment on MediaWiki.r80612. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/80612#c19445 Commit summary: Partial revert r78450: doQuery() and query() are not the same. You can't just swap one for the other without checking what might be using the result Comment: Tagged 1.18 because r78450 is tagged 1.18. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89817]: New comment added
User Siebrand posted a comment on MediaWiki.r89817. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89817#c19446 Commit summary: Fix for logic error in r89529 causing a notice. Comment: Tagging 1.18 because r89529 is tagged 1.18. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90531]: New comment added
User Siebrand posted a comment on MediaWiki.r90531. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90531#c19447 Commit summary: Follow up with the problem noted in r90530. You can't pass the result of a function to reset(), since it expects a reference. Those random errors show now as UploadStashFileException: error storing file in 'tests/phpunit/includes/upload/bug29408.': fileexistserror images/temp/0/02/20110621151405!bug29408. because it gets run twice in the same second. Comment: Tag 1.18 because r90340 is tagged 1.18. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90866]: New comment added
User Siebrand posted a comment on MediaWiki.r90866. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90866#c19448 Commit summary: Tweaked r90766 messages. Still awkward. Also, this still needs JS to disable the check if all is selected, to be less confusing. Comment: Tagged 1.18 because r90766 is tagged 1.18. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r90793]: New comment added
User Siebrand posted a comment on MediaWiki.r90793. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90793#c19449 Commit summary: *sigh*...added bit left off of r90789 Comment: Tagged 1.18 because r90789 is tagged 1.18. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r83791]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r83791. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83791#c0 Commit summary: (bug 2581, bug 6834) Added links to thumbnail in several resolutions to the file description page. The sizes are set by $wgImageLimits. Not really happy about how it looks, perhaps only the numbers should be linked? See http://www.mediawiki.org/wiki/User:Bryan/Bug_2581 for options. Removed message show-big-image-thumb, added show-big-image-preview, show-big-image-other, show-big-image-size. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] testing mobile browsers?
On Mon, Jul 11, 2011 at 1:36 PM, Brion Vibber br...@pobox.com wrote: On Mon, Jul 11, 2011 at 12:36 PM, Tomasz Finc tf...@wikimedia.org wrote: Firefox is tough as the current version has the exact same UA on mobile phones AND tablets. And since we don't redirect tablets we haven't switched it over yet. Anyone know why they did that? Mozilla generally recommends using CSS media queries and other client-side techs for adapting your pages to small or large screened-devices; while this is generally a good idea, it doesn't help directly with an issue like this where we'd really prefer to know a binary device claiming to have a tiny freaky screen or anything else so we can divide people down the mobile-optimized or regular web site paths. (We need to support older/more primitive phones that don't handle any of this stuff.) There are a couple closed-with-extreme-prejudice bugzilla entries like this: https://bugzilla.mozilla.org/show_bug.cgi?id=625238 https://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/43d566ca1333234e?pli=1 which mostly look like they're about wanting / not wanting whole gobs of device data in the user-agent string. All *we* really want is are you a small screen - include 'Mobile' in the UA or otherwise - don't include 'Mobile' in the UA... it may or may not be worth seeing if that can get added in as a compatibility thing, however I'm not sure offhand how easy it actually would be to detect whether such a flag should be added or not. I know that iOS has an explicit way to find out whether the app is running in the phone-style UI (iPhone, iPod Touch, and iPhone-targeted apps running on iPad in compat mode) or the tablet-style UI (iPad). I don't know if there's an equivalent on Android. An alternative if that can't be shoehorned in upstream is to do a JavaScript-side check while loading the regular web view; if we're in a browser where CSS media queries detect a tiny mobile screen, and we don't have a redirect preference cookie, then do the redirection after the fact. (And optionally set a default state for the per-browser preference cookie so we only have to do the test once instead of every visit?) I like this idea and think that we could implement it well. Also, this seems like it would be a good solution moving forward. As, it would just continue to work without the need to constantly update UA detection, etc. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r83778]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r83778. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83778#c0 Commit summary: (bug 14706) Added support for the Imagick PHP extension. Based on patch by Leslie Hoare. Scaler type is imext. Rotation is supported. Logic mostly copied from transformImagemagick() and ported to Imagick calls. Resizing animated gifs is broken; it only shows the first frame and I can't find out why it does not work, but otherwise it is fully working. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r50526]: New comment added
User Siebrand posted a comment on MediaWiki.r50526. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/50526#c19450 Commit summary: fixing spacing Comment: This rev has been marked todo for the past 2 years. Quick check came up with almost [http://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/todo 90 todos]. What's the meaning of this tag, as it is very unspecific and appears to have little to no value if it is not resolved after two years... ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r83280]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r83280. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83280#c0 Commit summary: Follow-up r83183, r83202: * Update SpecialCheckUser.php to new location of IP functions * Spin out the 'hide-other-field-if-select-box-not-on-other' function as one which should apply to all such fields, especially those created via HTMLForm. SpecialBlockip and SpecialGlobalBlock should ultimately be converted to use HTMLForm anyway. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r50526]: New comment added
User Tfinc posted a comment on MediaWiki.r50526. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/50526#c19451 Commit summary: fixing spacing Comment: Fixed in r51000 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r83280]: New comment added
User Aaron Schulz posted a comment on MediaWiki.r83280. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83280#c19452 Commit summary: Follow-up r83183, r83202: * Update SpecialCheckUser.php to new location of IP functions * Spin out the 'hide-other-field-if-select-box-not-on-other' function as one which should apply to all such fields, especially those created via HTMLForm. SpecialBlockip and SpecialGlobalBlock should ultimately be converted to use HTMLForm anyway. Comment: Nevermind. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r79856]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r79856. Old Status: ok New Status: fixme User Brion VIBBER also posted a comment on MediaWiki.r79856. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/79856#c19453 Commit summary: Bug 26563: Add bytes changed per revision for stub and full article dumps Comment: New schema version file isn't available at the expected URL: http://www.mediawiki.org/xml/export-0.5.xsd ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91842]: New comment added
User Siebrand posted a comment on MediaWiki.r91842. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91842#c19454 Commit summary: * Changed dynamic calls to Linker methods into static ones * Also preferably pass a Language object instead of a Skin one or boolean indicating whether it's for content. No other calls to these methods in core or extensions. Comment: Maybe I forgot, or maybe I triggered for the right reason. An interface was changed here, shouldn't that do to RELEASE-NOTES? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r79856]: New comment added
User Brion VIBBER posted a comment on MediaWiki.r79856. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/79856#c19455 Commit summary: Bug 26563: Add bytes changed per revision for stub and full article dumps Comment: Added to shell bugs: bug 29819. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91885]: New comment added
User Brion VIBBER posted a comment on MediaWiki.r91885. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91885#c19456 Commit summary: (follow-up r90256) Unit tests. Comment: Hmm... this seems to sound like it'll *drop* metadata from a paged tiff file proxied from another site via an API repo. This would presumably lose ability to select pages etc or...? Should ExifBitmapHandler ever be testing metadata from a PagedTiffHandler? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91870]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r91870. Old Status: new New Status: fixme User Brion VIBBER also posted a comment on MediaWiki.r91870. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91870#c19457 Commit summary: wgAction incorrectly asumes 'view' instead of 'historysubmit' on diff-pages without a action parameter. Bug 25800 Comment: This seems wrong; diff views default to a special subset of page views, so having action be 'view' is expected. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91873]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r91873. Old Status: new New Status: fixme User Brion VIBBER also posted a comment on MediaWiki.r91873. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91873#c19458 Commit summary: r91870 : Got tricked into believing it was action=diff instead of action=historysubmit Comment: This seems wrong; diff views default to a special subset of page views, so having action be 'view' is expected. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91870]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r91870. Old Status: fixme New Status: reverted User Brion VIBBER also posted a comment on MediaWiki.r91870. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91870#c19459 Commit summary: wgAction incorrectly asumes 'view' instead of 'historysubmit' on diff-pages without a action parameter. Bug 25800 Comment: Reverted in r91927. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91873]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r91873. Old Status: fixme New Status: reverted User Brion VIBBER also posted a comment on MediaWiki.r91873. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91873#c19460 Commit summary: r91870 : Got tricked into believing it was action=diff instead of action=historysubmit Comment: Reverted in r91927. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91776]: New comment added
User NeilK posted a comment on MediaWiki.r91776. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91776#c19461 Commit summary: start special page for viewing archived content. Comment: FYI Archive is an overloaded term in MediaWiki, since old deleted pages are also called 'archive'. Suggest you stick to calling it Special:ArchiveLinks like the class. I see you're thinking of including an output form as a default experience, but as we discussed I don't think you need this just yet. Still it would be neat if you could look up a URL. wget.exe should be replaced by a configurable path to wget. Generally we use the default for Ubuntu Linux so that would be '/usr/bin/wget' -- of course you fix it to whatever for your local machine. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91776]: New comment added
User NeilK posted a comment on MediaWiki.r91776. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91776#c19462 Commit summary: start special page for viewing archived content. Comment: Also, in general, try to move configuration into its own block or method. It's much better if you figure out what the $quota is way before you need to involve it in computation. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91869]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r91869. Old Status: new New Status: fixme User Brion VIBBER also posted a comment on MediaWiki.r91869. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91869#c19463 Commit summary: use tab name, not tab index for anchors on Special:Preferences. Bug 29672 . Patch by Jarry1250. Ping r91757 Comment: This puts unvalidated input into the creation of a jQuery selector; while it may not be exploitable, it's sloppy. Recommend validating with a basic ascii id regex. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r91869]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r91869. Old Status: fixme New Status: resolved User Brion VIBBER also posted a comment on MediaWiki.r91869. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/91869#c19464 Commit summary: use tab name, not tab index for anchors on Special:Preferences. Bug 29672 . Patch by Jarry1250. Ping r91757 Comment: did that real quick in r91929 -- otherwise looks good! ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
