[MediaWiki-CodeReview] [MediaWiki r89676]: New comment added
User Tim Starling posted a comment on MediaWiki.r89676. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89676#c17855 Commit summary: 1.17: MFT r82247, r87203, r87265, r87494, r87497, r87711, r87840, r88076, r89615 Comment: Did you mean to backport r87711? I thought we weren't going to use it. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89713]: Revision status changed
User Hashar changed the status of MediaWiki.r89713. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89713#c0 Commit summary: Revert r87145, bug 28752: Xcache doesn't work in cli mode. As pointed out on CR, this didn't fix it, it just hid the issue. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85323]: New comment added
User Hashar posted a comment on MediaWiki.r85323. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85323#c17856 Commit summary: Type hints to substring used in integer addition Comment: I got your point. Maybe use meaningful variables instead? $hour = substr( $now, 8, 2 ) $minute = substr( $now, 10, 2) Html::hidden( 'wpServerTime', $hour * 60 + $minute ) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code
On 07/06/11 20:56, Brion Vibber wrote: Currently working (mostly backwards) to fill in the Code Review holes from before 1.18 branch point: Since ci.tesla is almost stable since last week, I have switched to reviewing 1.18. I might have added some bugs in the 1.17 backport queue. Is there any policy to backport a revision to 1.17? -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code
On 07/06/11 23:27, Rob Lanphier wrote: http://toolserver.org/~robla/crstats/crstats.118all.html And here's the goals I posted on Friday: 2011-Jun-03 1594 2011-Jun-10 1329 2011-Jun-17 1064 2011-Jun-24 799 2011-Jul-01 534 2011-Jul-08 269 2011-Jul-15 4 This is a linear progression, the revision become harder and harder to review since, with time, most of the easy stuff got reviewed :-) Make it a long tail maybe ? :-) -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r87164]: New comment added
User IAlex posted a comment on MediaWiki.r87164. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87164#c17857 Commit summary: Recommit r87129 and follow-ups but with a fix for the bug Brion found (sorry) Comment: Yes, the problem is that you cannot select the entire table, such as the user table in this case, with a GROUP BY on only some fields (here rev_user and rev_user_text) in PostgreSQL, so I worked arround this by only selecting the user_real_name field from the user table (user_id and user_name come from the revision table) and this required those changes in the User object. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89252]: New comment added
User Freakolowsky posted a comment on MediaWiki.r89252. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89252#c17858 Commit summary: * MFT r89250. only the tableExists function ad 1.17 already supports user-dbname difference Comment: The function is not exposed to direct input so i don't see any reason why to even bother with it. This change was made because we introduced selectDB functionality into this backend type. What we do there is change the default schema pointer so DB has me logged in as one user but uses objects in another schema as my defaults. However all the user_* catalogs still show the objects from the actual user so we have to use main catalogs. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] sprint ? Implement a way for _only authorized users to use Special:PasswordReset on other usernames bug29135
Am 02.06.2011 04:33, schrieb Mark A. Hershberger: === Implement a way for _only authorized users to use Special:PasswordReset on other usernames === https://bugzilla.wikimedia.org/29135 A valid feature request, but just that a lot of details, so this makes a good one for me to promote for a weekend sprint. Because the implementation would touch some sensitive areas (password/login), I refrained from patching and would like someone to give me hints, or to help directly there. * Problem to be solved: User A can trigger a password-mail to any other user B by accessing (simply by accessing Special:PasswordReset and inputting username B into the field) * Situation: When logged-in users visit Special:PasswordReset, they see an _emtpy_ input field for entering an arbitrary username. The _empty_ field does not make sense, because:... ... read the cumulative summary on https://bugzilla.wikimedia.org/show_bug.cgi?id=29135#c6 signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code
* Brion Vibber br...@pobox.com [Tue, 7 Jun 2011 11:56:36 -0700]: Currently working (mostly backwards) to fill in the Code Review holes from before 1.18 branch point: http://www.mediawiki.org/w/index.php?title=Special:Code/MediaWikioffset=87519path=%2Ftrunk%2Fphase3 Roadmap provisionally says July for 1.18 deployment: http://www.mediawiki.org/wiki/MediaWiki_roadmap I wish there was WYSIWYG editor in the roadmap. It can be anything: Wikia RTE, Magnus Manske visual editor, or anything else - however, supporting creating content from scratch (not just editing over already existing article), working with built-in parser out of box, and no glitches like FCKeditor has. And being an WMF extension with all the advantages of continuous integration (core / extension compatibility). Dmitriy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r89723]: New comment added
User Nikerabbit posted a comment on MediaWiki.r89723. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89723#c17859 Commit summary: bug fix: multiselects not working from edit view Comment: Forgot debugging statements? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code
On Wed, Jun 8, 2011 at 9:30 AM, Dmitriy Sintsov ques...@rambler.ru wrote: I wish there was WYSIWYG editor in the roadmap. It can be anything: Wikia RTE, Magnus Manske visual editor, or anything else - however, supporting creating content from scratch (not just editing over already existing article), working with built-in parser out of box, and no glitches like FCKeditor has. And being an WMF extension with all the advantages of continuous integration (core / extension compatibility). Dmitriy There are people at WMF working on a visual editor. It's not on the roadmap page, but that doesn't mean it's not being worked on :) Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r89707]: New comment added
User Catrope posted a comment on MediaWiki.r89707. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/89707#c17860 Commit summary: quick fix for bug28983 . Do not use $path in the loop. Even the remaining $e is dangerous subject to change from the require-once-loaded extensions. This is NOT A FINAL fix, just a small improvement Comment: Foreach runs on a copy of the array, so changing or overwriting code$ext/code has no effect on the loop. This fix looks sufficient to me. Tagging 1.17, 1.18 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r81536]: New comment added
User Catrope posted a comment on MediaWiki.r81536. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/81536#c17861 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 Comment: Alright, untagging 1.17 then. If this bug was present in 1.16 as well, we can afford to delay the fix till 1.18. Besides, per my comment below I'm fairly sure this fix doesn't even work. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89676]: New comment added
User Catrope posted a comment on MediaWiki.r89676. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/89676#c17863 Commit summary: 1.17: MFT r82247, r87203, r87265, r87494, r87497, r87711, r87840, r88076, r89615 Comment: Crap, looks like I haven't done this correctly. Fixing. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89676]: New comment added
User Catrope posted a comment on MediaWiki.r89676. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/89676#c17864 Commit summary: 1.17: MFT r82247, r87203, r87265, r87494, r87497, r87711, r87840, r88076, r89615 Comment: Fixed in r89727 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87099]: New comment added
User Hashar posted a comment on MediaWiki.r87099. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87099#c17865 Commit summary: Provisional fix for Bug #28631 to remove artifacts from GIF. This seems better in my (very) limited testing than leaving it in, but I'd like to get more tests. Comment: Just for the context, this only apply when matching the three conditions: - image/gif - animated imagemagick = 6.3.5 The options which were passed to ImageMagick were: - fuzz 5% - layers optimizeTransparency - +map +map is supposed to look at the color map and generate the minimum map needed to represent the image. I do not think this parameter is the root cause although removing it might fix the issue as a side effect. I believe the root cause is the 'fuzz 5%' associated to the optimize transparency switch. From the documentation at http://www.imagemagick.org/script/command-line-options.php : '''optimize-transparency''' : Given a GIF animation, replace any pixel in the sub-frame overlay images with transparency, if it does not change the resulting animation by more than the current -fuzz factor. : This should allow a existing frame optimized GIF animation to compress into a smaller file size due to larger areas of one (transparent) color rather than a pattern of multiple colors repeating the current disposed image of the last frame. I am wondering if removing the fuzz option will be enough. Might be worth checking a newer imagemagick version and/or open an upstream bug. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87099]: New comment added
User TheDJ posted a comment on MediaWiki.r87099. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87099#c17866 Commit summary: Provisional fix for Bug #28631 to remove artifacts from GIF. This seems better in my (very) limited testing than leaving it in, but I'd like to get more tests. Comment: I don't remember exactly anymore, but I think that the fuzz factor is a very large influence on the compression factor of the animated gif filesize. And since that is the primary reason for handling these imagemagick options seperately, something to double check before making changes. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89728]: New comment added
User Reedy posted a comment on MediaWiki.r89728. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89728#c17867 Commit summary: Localization update for he. Comment: Wouldn't it be easier to just do these on TranslateWiki, easier to track changes, and then it's not a separate commit just to update one file? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r79463]: Revision status changed
User Reedy changed the status of MediaWiki.r79463. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/79463#c0 Commit summary: Move fallback function creation out of function_exists() conditionals. This allows for unit testing of the fallback functions to ensure that they work like the real functions do ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r81610]: Revision status changed
User Reedy changed the status of MediaWiki.r81610. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81610#c0 Commit summary: Ignore code coverage for compatibility and shell functions The compatibility functions in GlobalFunctions are just wrapper for their equivalent in the Fallback class. We should test the implementation and we can safely ignore those wrappers. Shell functions ignored make use of sleep() which is evil. They also do some outputs to the console which is probably hard to test properly. Given they are not critical, I just ignore their code coverage, we can still test them though :) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r81644]: Revision status changed
User Reedy changed the status of MediaWiki.r81644. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81644#c0 Commit summary: Fixed copy-paste fail that resulted in incorect authorship information. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86131]: New comment added
User Platonides posted a comment on MediaWiki.r86131. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86131#c17868 Commit summary: * Pass around parser options instead of users and made some parser options consistency fixes * Moved makeParserOptions to Article.php * Renamed currentIncludeVersions - getRevIncludes * Renamed updatePageCache - setPageCache * Moved FlaggedRevs::getCacheKey up Comment: In which case does your $user not match $wgUser? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89729]: Revision status changed
User Platonides changed the status of MediaWiki.r89729. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89729#c0 Commit summary: Fix r89696 - caused fatal error ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Showing stub links by default - is it possible in a Wikimedia project?
If we proceeded to remove the feature, they could fairly easily add it into Popups or one of the other JS citadels. I don't see a way to do it in JS w/o lengthy expensive API checks.. Leo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Extension bundling for 1.18
There has been some talk among developers and others about bundling some extensions with the tarball. The new installer supports enabling extensions during installation, so if we're going to do it, I would like to start bundling them with the 1.18 tarball. Part of my motivation is that many people seem to install MediaWiki and expect a wiki that acts very similar to Wikipedia, with which they are more familiar. Now, part of the problem is documentation — these people don't understand how the functionality of MediaWiki is partitioned. But in addition to documentation, we can start providing the most expected functionality in the tarball. Immediately, the objection of “bloat” would be raised. To alleviate this concern, we can still provide a “MediaWiki-lite” tarball with only the contents of phase3 as before. Assuming that we are going to put *some* extensions in, we need to decide which ones. Based on the problem reports in Bugzilla, I think at least Cite and ParserFunctions should be bundled. Others would be Gadgets and WikiEditor. So my list would be: Cite ParserFunctions Gadgets WikiEditor Have a look at http://en.wikipedia.org/wiki/Special:Version or http://www.mediawiki.org/wiki/Category:Extensions_used_on_Wikimedia and see which you would recommend we include. Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension bundling for 1.18
On 8 June 2011 16:22, Mark A. Hershberger mhershber...@wikimedia.org wrote: Part of my motivation is that many people seem to install MediaWiki and expect a wiki that acts very similar to Wikipedia, with which they are more familiar. Now, part of the problem is documentation — these people don't understand how the functionality of MediaWiki is partitioned. But in addition to documentation, we can start providing the most expected functionality in the tarball. Speaking as a tarball user: Yes please! Immediately, the objection of “bloat” would be raised. To alleviate this concern, we can still provide a “MediaWiki-lite” tarball with only the contents of phase3 as before. Works for me. So my list would be: Cite ParserFunctions Gadgets WikiEditor I would also ask for CategoryTree, though my users (office workers, a mix of geeks and non-geeks) could live without it. Suggestion: ask on mediawiki-l and mwusers.com, where tarball users might be found. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension bundling for 1.18
On Wed, Jun 8, 2011 at 11:22 AM, Mark A. Hershberger mhershber...@wikimedia.org wrote: Immediately, the objection of “bloat” would be raised. To alleviate this concern, we can still provide a “MediaWiki-lite” tarball with only the contents of phase3 as before. Since we're going down the road of offering different tarballs, can we also get an ultra-lite that only has MessagesEn? -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension bundling for 1.18
Hey, Assuming that we are going to put *some* extensions in, we need to decide which ones. As some might remember, I raised the question of the Validator extension [0] could be included in the tarball earlier this year [1]. This extensions goal is facilitating features in other extensions, which makes it somewhat unique, and is I think a good reason to include it in the tarball. It currently has 8 other extensions that are directly dependent on it, and at least a dozen more that are indirectly dependent on it, so having it in the tarball would make using it easier for extension devs. [0] http://www.mediawiki.org/wiki/Extension:Validator [1] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg11876.html Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] I'm in ur trunk, reviewing pre-1.18 branch code
That reminds me I should merge docs to the roadmap page! For now those live at http://www.mediawiki.org/wiki/Future -- brion On Jun 8, 2011 4:13 AM, Roan Kattouw roan.katt...@gmail.com wrote: On Wed, Jun 8, 2011 at 9:30 AM, Dmitriy Sintsov ques...@rambler.ru wrote: I wish there was WYSIWYG editor in the roadmap. It can be anything: Wikia RTE, Magnus Manske visual editor, or anything else - however, supporting creating content from scratch (not just editing over already existing article), working with built-in parser out of box, and no glitches like FCKeditor has. And being an WMF extension with all the advantages of continuous integration (core / extension compatibility). Dmitriy There are people at WMF working on a visual editor. It's not on the roadmap page, but that doesn't mean it's not being worked on :) Roan Kattouw (Catrope) ___ 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
Re: [Wikitech-l] Extension bundling for 1.18
While Vector is the default skin, the Vector extension should probably be bundled too. - Trevor On Wed, Jun 8, 2011 at 9:00 AM, Jeroen De Dauw jeroended...@gmail.comwrote: Hey, Assuming that we are going to put *some* extensions in, we need to decide which ones. As some might remember, I raised the question of the Validator extension [0] could be included in the tarball earlier this year [1]. This extensions goal is facilitating features in other extensions, which makes it somewhat unique, and is I think a good reason to include it in the tarball. It currently has 8 other extensions that are directly dependent on it, and at least a dozen more that are indirectly dependent on it, so having it in the tarball would make using it easier for extension devs. [0] http://www.mediawiki.org/wiki/Extension:Validator [1] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg11876.html Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ 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
Re: [Wikitech-l] Extension bundling for 1.18
Mark A. Hershberger wrote: Assuming that we are going to put *some* extensions in, we need to decide which ones. Based on the problem reports in Bugzilla, I think at least Cite and ParserFunctions should be bundled. Others would be Gadgets and WikiEditor. So my list would be: Cite ParserFunctions Gadgets WikiEditor Have a look at http://en.wikipedia.org/wiki/Special:Version or http://www.mediawiki.org/wiki/Category:Extensions_used_on_Wikimedia and see which you would recommend we include. Mark. I'd also include: * Vector Maybe worth consideration: * Renameuser * CategoryTree * DismissableSiteNotice[1] * ExpandTemplates -- Krinkle [1] Perhaps move this to core ? Probably super easy to do with modern javascript (if needed, could be disableable thru LocalSettings.php ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r86898]: Revision status changed
User Hashar changed the status of MediaWiki.r86898. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/86898#c0 Commit summary: proxy_check.php is probably useful to keep around, but it's not really an includes script Move it to maintenance/proxy_check.php ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Extension bundling for 1.18
On Wed, Jun 8, 2011 at 5:22 PM, Mark A. Hershberger mhershber...@wikimedia.org wrote: So my list would be: Cite ParserFunctions Gadgets WikiEditor ConfirmEdit (rationale: every single public wiki I've setup dies without this) -- Lucas 'TOR' Garczewski Community Engineer t...@wikia-inc.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Update Gadgets extension on WMF wikis
2011/6/7 Leo Koppelkamm diebu...@gmail.com: There's usually some code (general utility fn's, some legacy remappings etc.) in common.js that could break a lot of stuff if missing. +1 on moving optional stuff to gadgets It depends on project. General utility functions should be available as modules, which can be loaded when there is such need (as a dependency to a gadget or by user/script explicitly). It makes easier to port gadget to other projects and maintain them, when its dependencies are well defined, so all changes can be easily tracked. Separate modules can be directly imported, which is impossible with overbloated MediaWiki:Common.js. Regards, Ildefons Stułbia ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r89731]: New comment added
User Siebrand posted a comment on MediaWiki.r89731. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89731#c17869 Commit summary: * fixed regex to work * added missing directories Comment: Nitpick: should this script be named findHooks.php? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89730]: New comment added
User Nikerabbit posted a comment on MediaWiki.r89730. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89730#c17870 Commit summary: introduce setting for page to use for glossary Comment: Would nowiki[[$1|terminology]]/nowiki be better? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Update Gadgets extension on WMF wikis
2011/6/8 Ildefons Stułbia ildefons.stul...@gmail.com: 2011/6/7 Leo Koppelkamm diebu...@gmail.com: There's usually some code (general utility fn's, some legacy remappings etc.) in common.js that could break a lot of stuff if missing. +1 on moving optional stuff to gadgets It depends on project. General utility functions should be available as modules, which can be loaded when there is such need (as a dependency to a gadget or by user/script explicitly). It makes easier to port gadget to other projects and maintain them, when its dependencies are well defined, so all changes can be easily tracked. Separate modules can be directly imported, which is impossible with overbloated MediaWiki:Common.js. Yes, it does depend on the project, but I'm pretty sure that in most projects there are some chunks of js in Common.js that simply should not be disabled. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Intended purpose of MediaWiki:Common.js anno MW 1.19/RL 2.0
Subject was: Update Gadgets extension on WMF wikis This part of the thread is hereby forked to discuss MediaWiki:Common.js. I do not believe MediaWiki:Common.js should be deleted (atleast not yet), I'm merely curious what usecases people have for it which may or may not be useful to be taken into account during the upcoming revision of ResourceLoader and Gadgets. Ildefons Stułbia wrote: 2011/6/7 Leo Koppelkamm diebu...@gmail.com: There's usually some code (general utility fn's, some legacy remappings etc.) in common.js that could break a lot of stuff if missing. +1 on moving optional stuff to gadgets It depends on project. General utility functions should be available as modules, which can be loaded when there is such need (as a dependency to a gadget or by user/script explicitly). It makes easier to port gadget to other projects and maintain them, when its dependencies are well defined, so all changes can be easily tracked. Separate modules can be directly imported, which is impossible with overbloated MediaWiki:Common.js. Regards, Ildefons Stułbia Indeed. Regardless of what it's most common purpose has become (and nobody blames anybody for any of that, becaus wikis simple do what they must, with the tools they're given).. most things that are in Common.js should not be. I think only a few things (if at all) should eventually stay in MediaWiki:Common.js. I'm having a hard time coming up with examples, but basically only stuff that is truly specific to that particular wiki and not related to end-users in any way. For example custom config variables (wgFooBar) or central enhancements such as * scripts to move custom icons to the top of the page next to the title * some kind of interaction on the Main Page that is dependant But then again, I can imagine the top-icon-script being a gadget that would be imported to our central wiki as a global gadget that local wikis can enable/disable and, in most cases, set to default: on. And something that does awesome things to the main page ? Probably something that is useful and could be made more generic for use in other wikis. So in more cases than one might think, gadgets are or will be better suited for almost anything. For example javascript libraries or jquery plugins should be stored as gadget modules that are indicated as hidden (or private, the name hasn't been decided yet), which other gadgets can register as a dependancy. ie. Gadget-foo (dependancies: somelib, jquery.foobar, gadget-loremipsum) Question: Do you think MediaWiki:Common.js has future-proof usecases given the current plans ? If so, please share them in this thread. Again, nobody is threatening the existance of MediaWiki:Common.js, even if it would just be for legacy reasons (because millions of wikis are using it), it will not be removed any time in near or far future. Thanks, – Krinkle ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r89730]: New comment added
User F.trott posted a comment on MediaWiki.r89730. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89730#c17871 Commit summary: introduce setting for page to use for glossary Comment: I don't know, would it? I'd rather have it clearly identified without the need to follow (or at least hover over) the link. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Update Gadgets extension on WMF wikis
2011/6/8 Strainu strain...@gmail.com: Yes, it does depend on the project, but I'm pretty sure that in most projects there are some chunks of js in Common.js that simply should not be disabled. In my opinion any custom ui feature should be optional, because it will never satisfy all users. It will also simplify developing and testing new versions of a gadget, by giving users an ability to turn off old version and turn on the new one. User having trouble with interfering scripts will be able to find out which ones by selectively disabling gadgets. Getting rid of MediaWiki:Common.js may not be feasible for all projects, in the end it is all up to sysops how much freedom they are willing to grant to contributors and viewers. Regards, Ildefons Stułbia ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r89732]: New comment added
User Nikerabbit posted a comment on MediaWiki.r89732. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89732#c17872 Commit summary: followup r89730: Use the setting Comment: Perhaps say Page ... does not exist + 'lingo-noterminologypage' = '[[$1]] does not exist.', This is not how you use Title::makeTitle + $rev = Revision::newFromTitle( Title::makeTitle( null, $page ) ); Is there supposed to be one page for every language? What if the name of the page is the same in two languages? Also doing the lingo-desc message that way looks very fragile and prone to break. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Extension bundling for 1.18
On Wed, Jun 8, 2011 at 11:22 AM, Mark A. Hershberger mhershber...@wikimedia.org wrote: Assuming that we are going to put *some* extensions in, we need to decide which ones. [..] Have a look at http://en.wikipedia.org/wiki/Special:Version or http://www.mediawiki.org/wiki/Category:Extensions_used_on_Wikimedia and see which you would recommend we include. I'd suggest that you also look at Suggestions for extensions to be merged into core: http://www.mediawiki.org/wiki/Suggestions_for_extensions_to_be_merged_into_core The point of that page is to list extensions that we love and are frequently used. If they're not already in core, we should probably do the next best thing and bundle them. -- Casey Brown Cbrown1023 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r89732]: New comment added
User F.trott posted a comment on MediaWiki.r89732. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89732#c17873 Commit summary: followup r89730: Use the setting Comment: 1) Can do. 2) Changed to Title::newFromText in r89734. 3) Oops, no. There should only be one terminology page. I will use wfMsgForContent. 4) Why would this be fragile? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89733]: New comment added
User ^demon posted a comment on MediaWiki.r89733. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89733#c17874 Commit summary: Adding WURFL library Comment: Is this available in an external repository somewhere? If so, we should probably use an svn:external instead :) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84739]: Revision status changed
User Catrope changed the status of MediaWiki.r84739. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/84739#c0 Commit summary: Changes default value so that it's not converted to array( 0 = '' ) by the (array) cast a few lines below. This was breaking the check whether the magic word was found by Language::getMagic() or not. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88936]: Revision status changed
User MarkAHershberger changed the status of MediaWiki.r88936. Old Status: fixme New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88936#c0 Commit summary: This needs to be forward-ported to trunk. Fix for Bug #28172 - wfGetDB called when it shouldn't be Avoid an ominous error (“Mediawiki tried to access the database via wfGetDB(). This is not allowed.”) by passing db handles to user methods that would otherwise have to use wfGetDB(). ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89374]: Revision status changed
User MarkAHershberger changed the status of MediaWiki.r89374. Old Status: fixme New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89374#c0 Commit summary: Finish fix for bug #28172 (“wfGetDB called when it shouldn't be”). Will now forward port to trunk ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Extension bundling for 1.18
On 8 June 2011 21:01, Casey Brown li...@caseybrown.org wrote: I'd suggest that you also look at Suggestions for extensions to be merged into core: http://www.mediawiki.org/wiki/Suggestions_for_extensions_to_be_merged_into_core The point of that page is to list extensions that we love and are frequently used. If they're not already in core, we should probably do the next best thing and bundle them. Ooh, renameuser would be way useful in intranet land. I've had to twiddle in the database at all ever, which is deeply fragile and annoying ... - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension bundling for 1.18
On Wed, Jun 8, 2011 at 8:22 AM, Mark A. Hershberger mhershber...@wikimedia.org wrote: There has been some talk among developers and others about bundling some extensions with the tarball. The new installer supports enabling extensions during installation, so if we're going to do it, I would like to start bundling them with the 1.18 tarball. This would be 1.19 at the earliest. 1.18 is already branched, and if we're aspiring to do much more frequent releases, the last thing we should do is to complicate a 1.18 release by trying to add more features into the branch. While this may not be a relatively small change, there are *lots* of features that are small changes. I'm assuming our tarball release process currently involves doing svn export on the phase3 directory of the release branch. After that, I have no idea what sort of post-processing (if any) we do (er, Tim does). Clearly, having some extensions in there is something that makes things a little more complicated. Probably not rocket science, but it is work. I would prefer that we have a plan and a developer lined up to do this work before saying this is something that we're going to do. Who is willing to take this on? I would very much prefer if this were a volunteer rather than a WMF staff member. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension bundling for 1.18
On Wed, Jun 8, 2011 at 10:25 PM, Rob Lanphier ro...@wikimedia.org wrote: This would be 1.19 at the earliest. 1.18 is already branched, and if we're aspiring to do much more frequent releases, the last thing we should do is to complicate a 1.18 release by trying to add more features into the branch. While this may not be a relatively small change, there are *lots* of features that are small changes. This argument completely misses the point. The (probably trivial) extra work is in the tarballing process and doesn't touch anything else. There's no way it can subtly break things. I'm assuming our tarball release process currently involves doing svn export on the phase3 directory of the release branch. After that, I have no idea what sort of post-processing (if any) we do (er, Tim does). Clearly, having some extensions in there is something that makes things a little more complicated. Probably not rocket science, but it is work. I would prefer that we have a plan and a developer lined up to do this work before saying this is something that we're going to do. Who is willing to take this on? I would very much prefer if this were a volunteer rather than a WMF staff member. Why don't we first ask Tim how complicated it would be, and get someone else to do it if it's more than 2-3 hours of work? I'm also not sure the scripts Tim uses to create a tarball are even in SVN anywhere, maybe he'd be willing to share them if they're not public already. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension bundling for 1.18
On Wed, Jun 8, 2011 at 1:30 PM, Roan Kattouw roan.katt...@gmail.com wrote: Why don't we first ask Tim how complicated it would be, and get someone else to do it if it's more than 2-3 hours of work? I'm also not sure the scripts Tim uses to create a tarball are even in SVN anywhere, maybe he'd be willing to share them if they're not public already. They've been in SVN for some time (and luckily Tim rewrote them in Python from my older horrid bash code ;) http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/make-release/ Basically, we do a SVN export, chop out a few unneeded files, build a tarball and a patch, and GPG-sign them. Also checking out some extensions and dropping them in would not be very difficult to throw in. Currently the installer's support for extensions is limited; some won't actually set up right, and we don't handle dependencies well, but self-contained stuff like ParserFunctions and Gadgets should be pretty trivial. It would I think be possible to stash a few things in for 1.18 release with no problem (and no new code, just tossing the existing branched extensions into the tarball) if we wanted to, though they wouldn't be automatically activated at install unless the user actually selects them. Actually making things default would need some more work, and either way we'd want to do a little testing. :) -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension bundling for 1.18
On Wed, Jun 8, 2011 at 4:30 PM, Roan Kattouw roan.katt...@gmail.com wrote: Why don't we first ask Tim how complicated it would be, and get someone else to do it if it's more than 2-3 hours of work? I'm also not sure the scripts Tim uses to create a tarball are even in SVN anywhere, maybe he'd be willing to share them if they're not public already. Roan Kattouw (Catrope) They are, /trunk/tools/make-release -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension bundling for 1.18
On Wed, Jun 8, 2011 at 4:41 PM, Brion Vibber br...@pobox.com wrote: Currently the installer's support for extensions is limited; Yes :( some won't actually set up right, Examples? and we don't handle dependencies well, s/well/at all/ but self-contained stuff like ParserFunctions and Gadgets should be pretty trivial. I agree :) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Intended purpose of MediaWiki:Common.js anno MW 1.19/RL 2.0
On Wed, Jun 8, 2011 at 12:16 PM, Krinkle krinklem...@gmail.com wrote: Subject was: Update Gadgets extension on WMF wikis This part of the thread is hereby forked to discuss MediaWiki:Common.js. I do not believe MediaWiki:Common.js should be deleted (atleast not yet), I'm merely curious what usecases people have for it which may or may not be useful to be taken into account during the upcoming revision of ResourceLoader and Gadgets. In general, modular gadgets will be a better way in the future to create, maintain, share, and re-use client-side code components, as it will provide better infrastructure for doing those things versus manually cut-and-pasting a few bits of code. At the moment, we're only partway there; sharing things from site to site is still awkward, and there's not a good management interface for site admins to work with. Obviously MediaWiki:Common.js won't be removed in the short term (and may stay around for compat for a long long time). -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension bundling for 1.18
On Wed, Jun 8, 2011 at 1:43 PM, Chad innocentkil...@gmail.com wrote: On Wed, Jun 8, 2011 at 4:41 PM, Brion Vibber br...@pobox.com wrote: Currently the installer's support for extensions is limited; Yes :( some won't actually set up right, Examples? Whatever was listed in bugzilla on that one bug where something didn't run its installer stages or something? I don't remember; the point is that we know we don't hook all hooks etc. and we don't handle dependencies well, s/well/at all/ exactly. :) but self-contained stuff like ParserFunctions and Gadgets should be pretty trivial. I agree :) \o/ -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Cache Expiry
Hello, I've looked around for methods to manipulate the cache duration for a given article. There are methods to facilitate the expiration of an article, and there are extensions that can disable caching for articles via convenient management interfaces. What seems to be lacking though, is a way to expire the article after some duration. For instance, I'm working with embedded RSS feeds... from what I'm finding I have 3 options: 1. Live with the RSS feed being cached. 2. Immediately invalidate the article cache so that the next request causes the article to be rebuilt. 3. Tell users to use action=purge (or provide a button to manually do this (or invalidate the cache). The first option is not really an option :) The second option is inefficient. The third option is unpalatable. So the question becomes-- Would it be possible to have a new field added to the page database table that determines the duration of the cache? This would be optimal because extensions could then auto determine the maximum duration of the article either by directly manipulating the table entry, or preferably via a hook when the article is saved. Failing a change to the MediaWiki core, I guess I could create a service extension that uses it's own database table to track durations and checks for expirations via the job system at which time it could invalidate articles. But that seems roundabout for something that strikes me as better supported in the core. Thoughts? Cheers, Rob. -- E-Mail Disclaimer: Information contained in this message and any attached documents is considered confidential and legally protected. This message is intended solely for the addressee(s). Disclosure, copying, and distribution are prohibited unless authorized. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension bundling for 1.18
On Wed, Jun 8, 2011 at 4:48 PM, Brion Vibber br...@pobox.com wrote: On Wed, Jun 8, 2011 at 1:43 PM, Chad innocentkil...@gmail.com wrote: On Wed, Jun 8, 2011 at 4:41 PM, Brion Vibber br...@pobox.com wrote: Currently the installer's support for extensions is limited; Yes :( some won't actually set up right, Examples? Whatever was listed in bugzilla on that one bug where something didn't run its installer stages or something? I don't remember; the point is that we know we don't hook all hooks etc. That would be bug 28983, which is already fixed in trunk. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r89740]: New comment added
User F.trott posted a comment on MediaWiki.r89740. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89740#c17877 Commit summary: followup r89732: use wfMsgForContent, modify messages Comment: According to http://svn.wikimedia.org/doc/GlobalFunctions_8php.html#aad8d18cb2c96ef4c30f62a7975fc964c that function takes only one parameter. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89740]: New comment added
User Nikerabbit posted a comment on MediaWiki.r89740. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89740#c17878 Commit summary: followup r89732: use wfMsgForContent, modify messages Comment: All wfMsgFoo variants take the parameters as varargs. http://svn.wikimedia.org/doc/GlobalFunctions_8php.html#ab74e8af897e02ca032dd582aabd92282 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87734]: Revision status changed
User Catrope changed the status of MediaWiki.r87734. Old Status: new New Status: resolved Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87734#c0 Commit summary: Added messaging for above/below high/low tables ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87773]: Revision status changed
User Catrope changed the status of MediaWiki.r87773. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87773#c0 Commit summary: Followup r87734 addWikiText( wfMsg()) - addWikiMsg() ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87796]: Revision status changed
User Catrope changed the status of MediaWiki.r87796. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87796#c0 Commit summary: Checking for 10 rating sets rather than 5; Followup r87779 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88946]: Revision status changed
User MarkAHershberger changed the status of MediaWiki.r88946. Old Status: fixme New Status: new Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88946#c0 Commit summary: Fix Bug #28829 - “Failure to subscribe to mediawiki-announce is not reported to the user” Wasn't able to test an actual subscription failure, so I faked it. Error message showed. Tried double-subscribing an address and only got an emailed “privacy alert” from mailman. Doing a double-subscription manually didn't get any web-based error. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89494]: Revision status changed
User Catrope changed the status of MediaWiki.r89494. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/89494#c0 Commit summary: Fix syntax in .sql (spaces), crashed updater (follow-up r89277) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Cache Expiry
On Wed, Jun 8, 2011 at 1:50 PM, Robert Cummings rob...@interjinn.comwrote:
I've looked around for methods to manipulate the cache duration for a
given article. There are methods to facilitate the expiration of an
article, and there are extensions that can disable caching for articles
via convenient management interfaces. What seems to be lacking though,
is a way to expire the article after some duration. For instance, I'm
working with embedded RSS feeds...
[snip]
It looks like MediaWiki 1.17 and later support this already, by calling
updateCacheExpiry() on the parser cache output object.
The RSS extension uses this in its rendering hook:
if ( $wgRSSCacheCompare ) {
$timeout = $wgRSSCacheCompare;
} else {
$timeout = $wgRSSCacheAge;
}
$parser-getOutput()-updateCacheExpiry( $timeout );
In theory at least this should propagate the shorter expiry time out to both
the parser cache entry and the actual output page's HTTP headers, though I
haven't tested to double-check myself yet.
-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Intended purpose of MediaWiki:Common.js anno MW 1.19/RL 2.0
On Wed, Jun 8, 2011 at 16:16, Krinkle krinklem...@gmail.com wrote: I think only a few things (if at all) should eventually stay in MediaWiki:Common.js. I'm having a hard time coming up with examples, but basically only stuff that is truly specific to that particular wiki and not related to end-users in any way. For example custom config variables (wgFooBar) or central enhancements such as * scripts to move custom icons to the top of the page next to the title * some kind of interaction on the Main Page that is dependant On some Wikibooks projects (en, it, pt) for example, it was added a variable wgBookName[1], which is used e.g. to import book specific gadgets[2] (at least while MediaWiki is not able to provide per-book stylesheets[3]). But then again, I can imagine the top-icon-script being a gadget that would be imported to our central wiki as a global gadget that local wikis can enable/disable and, in most cases, set to default: on. And something that does awesome things to the main page ? Probably something that is useful and could be made more generic for use in other wikis. So in more cases than one might think, gadgets are or will be better suited for almost anything. There is also the script wich process the withJS and withCSS url parameters, which are used in various wikiprojects but doesn't seems to be adequate for global gadgets (what would be the point of letting the users to disable this?) For example javascript libraries or jquery plugins should be stored as gadget modules that are indicated as hidden (or private, the name hasn't been decided yet), which other gadgets can register as a dependancy. ie. Gadget-foo (dependancies: somelib, jquery.foobar, gadget-loremipsum) Should this be made locally by the local admins in MediaWiki:SpecificPages.js, or the users should request on Bugzilla the addition of new plugins to MediaWiki (such as jQuery.hotkeys[7])? Question: Do you think MediaWiki:Common.js has future-proof usecases given the current plans ? If so, please share them in this thread. Still talking about Wikibooks, there are scripts such as the one used to add a link to the sidebar providing access to a random bug (which is a workaround to another open bug[5]). Such an script could be useful as a global gadget, but only for wikis where there is a heavy use of subpages for (manual) meta-organization[6] of the content of the books (mainly Wikibooks and Wikisources). Regards, Helder [1] https://secure.wikimedia.org/wikibooks/en/wiki/MediaWiki:Common.js [2] https://secure.wikimedia.org/wikibooks/en/wiki/MediaWiki:Common.js/Perbook.js [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=15075 [4] https://secure.wikimedia.org/wikibooks/en/wiki/MediaWiki:Common.js/RandomBook.js [5] https://bugzilla.wikimedia.org/show_bug.cgi?id=16655 [6] https://bugzilla.wikimedia.org/show_bug.cgi?id=15071 [7] https://bugzilla.wikimedia.org/show_bug.cgi?id=27493 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension bundling for 1.18
On Wed, Jun 8, 2011 at 1:50 PM, Chad innocentkil...@gmail.com wrote: Whatever was listed in bugzilla on that one bug where something didn't run its installer stages or something? I don't remember; the point is that we know we don't hook all hooks etc. That would be bug 28983, which is already fixed in trunk. Objection withdrawn then. :D -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Intended purpose of MediaWiki:Common.js anno MW 1.19/RL 2.0
On Wed, Jun 8, 2011 at 18:08, Helder helder.w...@gmail.com wrote: Still talking about Wikibooks, there are scripts such as the one used to add a link to the sidebar providing access to a random bug (which is a workaround to another open bug[5]). I meant providing access to a random **book**. Helder ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r89399]: New comment added
User Platonides posted a comment on MediaWiki.r89399. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89399#c17880 Commit summary: rvv: r89398. Tim wants me to wait Comment: Yes, I think many scripts rely on this. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89399]: New comment added
User ^demon posted a comment on MediaWiki.r89399. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89399#c17881 Commit summary: rvv: r89398. Tim wants me to wait Comment: I see no problem with removing it from trunk when Tim's done merging stuff. There's a difference between dropping it in trunk and merging it to the 1.17 or 1.18 branches. If we did it now, at the *very earliest* we'd see it gone in 1.19. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89277]: New comment added, and revision status changed
User Catrope changed the status of MediaWiki.r89277.
Old Status: new
New Status: fixme
User Catrope also posted a comment on MediaWiki.r89277.
Full URL:
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/89277#c17882
Commit summary:
Added 'problem articles' view to dashboard; refactored dashboard code
(populateAFStatistics.php, primarily); Added new schema sql scripts as well as
sql migration script
Comment:
There's quite a bit wrong with this rev. I'll fix it because Arthur is in
fundraising land now.
Krinkle reports:
pre
Notice: Undefined variable: cur_ts in
/htdocs/SVN/mediawiki/trunk/extensions/ArticleFeedback/populateAFStatistics.php
on line 213
Notice: Undefined property: Page::$probematic in
/htdocs/SVN/mediawiki/trunk/extensions/ArticleFeedback/populateAFStatistics.php
on line 543
/pre
pre
+CREATE UNIQUE INDEX /*i*/ afs_page_ts_type ON /*_*/ article_feedback_stats(
afs_page_id, afs_ts, afs_stats_type_id );
+CREATE INDEX /*i*/ afs_ts_avg_overall ON /*_*/article_feedback_stats (afs_ts,
afs_orderable_data);
/pre
These indexes are insufficient. Making a note for myself to add proper indexing.
pre
+ if ( !$db-tableExists(
'article_feedback_stats_type' )) {
/pre
Typo in table name
pre
+ array_push( $problems, $page-page_id );
/pre
Per the PHP docs, just use code$problems[] = $page-page_id;/code
Problem articles data is built but never inserted.
Re-fetches data it just inserted, and does so from the slave, which is
guaranteed to fail in a replicated environment.
pre
+ array( 'aa_timestamp = ' . $this-dbr-addQuotes( $ts
)),
/pre
Needs code$this-dbr-timestamp()/code too.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89493]: Revision status changed
User Catrope changed the status of MediaWiki.r89493. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/89493#c0 Commit summary: Fix filepath (typo), crashes updater (follow-up r89277) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89751]: Revision status changed
User ^demon changed the status of MediaWiki.r89751. Old Status: new New Status: deferred Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89751#c0 Commit summary: Localisation updates for core and extension messages from translatewiki.net (2011-06-08 20:51:00 UTC) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89749]: Revision status changed
User ^demon changed the status of MediaWiki.r89749. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89749#c0 Commit summary: Localisation updates for ToolserverI18N messages from translatewiki.net (2011-06-08 20:30:00) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89283]: Revision status changed
User ^demon changed the status of MediaWiki.r89283. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89283#c0 Commit summary: Register alias file from r89164 for Translatewiki ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89432]: Revision status changed
User ^demon changed the status of MediaWiki.r89432. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89432#c0 Commit summary: Optional for Translatewiki (r89372) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89516]: Revision status changed
User ^demon changed the status of MediaWiki.r89516. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89516#c0 Commit summary: Tweaks to messages and extension credit Add extension to Translatewiki ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r87750]: Revision status changed
User Catrope changed the status of MediaWiki.r87750.
Old Status: new
New Status: ok
Full URL:
https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/87750#c0
Commit summary:
ArticleFeedback fixes for legacy skins
* CologneBlue skin ('cologneblue'): Previously absent (no #catlinks), now
appended to mw.util.$content
* Nostalgia skin ('nostalgia'): Previously absent (no #catlinks), now appended
to mw.util.$content
* Classic skin ('standard') is an exception, it has #catlinks on top, now
forced appending to mw.util.$content
* In all other cases, the bottom of the article, _before_ #catlinks is fine and
is kept as-is.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89673]: Revision status changed
User Catrope changed the status of MediaWiki.r89673. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/89673#c0 Commit summary: Adding 'articlefeedback-disable-preference' to preferences panel under 'Appearance / options' * (bug 29173) Create a preference to turn the Article feedback widget off ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88588]: New comment added
User ^demon posted a comment on MediaWiki.r88588. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88588#c17883 Commit summary: $wgArticle is deprecated! Possible removal in 1.20 or 1.21! * Encapsulate index.php in wfIndexMain() (similar to r77873) * Kill $wgArticle check in Exception, not necessary anymore * Kill $wgArticle in Setup, also not necessary * Add angry note about $wgArticle to rebuildFileCache. * Remove note about $wgArticle in Parser since it's dying anyway Comment: Actually, why not just remove it completely? Leaving it around for a release encourages people to keep using it. It was never widely used outside of core, and I've already filed a bug for the remaining problems. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89277]: New comment added
User Awjrichards posted a comment on MediaWiki.r89277. Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/89277#c17884 Commit summary: Added 'problem articles' view to dashboard; refactored dashboard code (populateAFStatistics.php, primarily); Added new schema sql scripts as well as sql migration script Comment: Thanks for catching these and taking care of them - I never had the chance to fully test before I had to hand this stuff over :( ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Extension bundling for 1.18
Casey Brown wrote: On Wed, Jun 8, 2011 at 11:22 AM, Mark A. Hershberger mhershber...@wikimedia.org wrote: Assuming that we are going to put *some* extensions in, we need to decide which ones. [..] Have a look at http://en.wikipedia.org/wiki/Special:Version or http://www.mediawiki.org/wiki/Category:Extensions_used_on_Wikimedia and see which you would recommend we include. I'd suggest that you also look at Suggestions for extensions to be merged into core on MediaWiki.org. The point of that page is to list extensions that we love and are frequently used. If they're not already in core, we should probably do the next best thing and bundle them. I'd also suggest reading bug 26261.[1] I'm kind of surprised this wasn't mentioned in the opening post given that most replies on this mailing list are echoing the bug's comments. MZMcBride [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=26261 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension bundling for 1.18
On Wed, Jun 8, 2011 at 1:30 PM, Roan Kattouw roan.katt...@gmail.com wrote: On Wed, Jun 8, 2011 at 10:25 PM, Rob Lanphier ro...@wikimedia.org wrote: This would be 1.19 at the earliest. 1.18 is already branched, and if we're aspiring to do much more frequent releases, the last thing we should do is to complicate a 1.18 release by trying to add more features into the branch. While this may not be a relatively small change, there are *lots* of features that are small changes. This argument completely misses the point. The (probably trivial) extra work is in the tarballing process and doesn't touch anything else. There's no way it can subtly break things. You're willing to say there are exactly *zero* fixes that would be needed to be done in trunk and merged into 1.18 as a result of making this change? I'm not going to dig my heels in on this one. However, I'd really like to encourage everyone to avoid piling non-critical into a release branch after it gets branched, and have the patience to wait for the following release. That's the only way we're ever going to speed up the release train. I'm assuming our tarball release process currently involves doing svn export on the phase3 directory of the release branch. After that, I have no idea what sort of post-processing (if any) we do (er, Tim does). Clearly, having some extensions in there is something that makes things a little more complicated. Probably not rocket science, but it is work. I would prefer that we have a plan and a developer lined up to do this work before saying this is something that we're going to do. Who is willing to take this on? I would very much prefer if this were a volunteer rather than a WMF staff member. Why don't we first ask Tim how complicated it would be, and get someone else to do it if it's more than 2-3 hours of work? I'm also not sure the scripts Tim uses to create a tarball are even in SVN anywhere, maybe he'd be willing to share them if they're not public already. Even if it's 2-3 hours of work, I still would prefer that a volunteer gets involved in this area. Tim in particular has an overabundance of 2-3 hour tasks. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension bundling for 1.18
I like to have these urgently added in the tarball by default: * TitleKey * Cite Tom signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension bundling for 1.18
On Thu, Jun 9, 2011 at 12:21 AM, Rob Lanphier ro...@wikimedia.org wrote: You're willing to say there are exactly *zero* fixes that would be needed to be done in trunk and merged into 1.18 as a result of making this change? I guess the worst that could happen is that one of the bundled extension breaks core in some way, in which case it's slightly worse because we bundle the extension. Other than that, core is unaffected. I'm not going to dig my heels in on this one. However, I'd really like to encourage everyone to avoid piling non-critical into a release branch after it gets branched, and have the patience to wait for the following release. That's the only way we're ever going to speed up the release train. I'm not particularly attached to it, and I think we can wait till 1.19 if we want to. I just didn't think your arguments made much sense. Even if it's 2-3 hours of work, I still would prefer that a volunteer gets involved in this area. Tim in particular has an overabundance of 2-3 hour tasks. Yeah, that's true. A brief assessment by Tim as to whether this is as easy as I think it is (for someone who speaks Python) would be nice though. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension bundling for 1.18
On Wed, Jun 8, 2011 at 6:33 PM, Roan Kattouw roan.katt...@gmail.com wrote: On Thu, Jun 9, 2011 at 12:21 AM, Rob Lanphier ro...@wikimedia.org wrote: You're willing to say there are exactly *zero* fixes that would be needed to be done in trunk and merged into 1.18 as a result of making this change? I guess the worst that could happen is that one of the bundled extension breaks core in some way, in which case it's slightly worse because we bundle the extension. Other than that, core is unaffected. This. I'm not going to dig my heels in on this one. However, I'd really like to encourage everyone to avoid piling non-critical into a release branch after it gets branched, and have the patience to wait for the following release. That's the only way we're ever going to speed up the release train. I'm not particularly attached to it, and I think we can wait till 1.19 if we want to. I just didn't think your arguments made much sense. Also this. I think it's a good idea, but not worth putting aside 1.17 or 1.18 work to make it happen. Even if it didn't happen until 1.20, I don't think it'd be a huge deal...we'd just be maintaining the status quo. In the long run, I think it makes zero difference whatsoever, as once Real Extension Management becomes a reality, it shouldn't matter at all whether the extension was in the tarball or not--and in fact, I would argue we should keep them *out* of the tarball at that point, to keep download size to a minimum and since hopefully installing extensions would've become painless. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension bundling for 1.18
Am 09.06.2011 00:37, schrieb Chad: Also this. I think it's a good idea, but not worth putting aside 1.17 or 1.18 work to make it happen. I also think we are _not_ in a hurry to add extensions _now_ We should - starting now - take out time to collect (on a MediaWiki page ) opinions what extensions could be candidates for a roll-out. signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension bundling for 1.18
Jeroen De Dauw wrote: As some might remember, I raised the question of the Validator extension [0] could be included in the tarball earlier this year [1]. This extensions goal is facilitating features in other extensions, which makes it somewhat unique, and is I think a good reason to include it in the tarball. It currently has 8 other extensions that are directly dependent on it, and at least a dozen more that are indirectly dependent on it, so having it in the tarball would make using it easier for extension devs. [0] http://www.mediawiki.org/wiki/Extension:Validator [1] http://www.mail-archive.com/wikitech-l@lists.wikimedia.org/msg11876.html Are you familiar with ExtensionFunctions.php? This extension kind of reminds me of it. I only briefly read through the docs, but it seems like the kind of code that should be in core, particularly if multiple extensions are relying on it. MediaWiki administration is already cumbersome; added dependencies should be killed when possible, not encouraged. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r89747]: New comment added
User Nikerabbit posted a comment on MediaWiki.r89747. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89747#c17885 Commit summary: followup r89740: remove wfMsgReplaceArgs, small fix to messages Comment: You don't need the array() either in the wfMsgForContent calls :) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r86044]: New comment added, and revision status changed
User Bawolff changed the status of MediaWiki.r86044. Old Status: new New Status: fixme User Bawolff also posted a comment on MediaWiki.r86044. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/86044#c17886 Commit summary: Follow-up r 86041 per CR and IRC: * Article constructor needs to be called with zero as second parameter * Run stylize.php over new files * Add Action::getLang() for consistency with other context accessors * Fix declaration of FormAction::alterForm(), doesn't need to be passed by reference * Fix inline use of Credits::getCredits() in SkinTemplate and SkinLegacy Comment: Not sure if this is right revision (but can't find the right one), but for the CreditsAction: The message for the subtitle should be mediawiki:creditspage, somewhere along the way it got changed to mediawikis:credits ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Showing stub links by default - is it possible in a Wikimedia project?
Leo Koppelkamm diebu...@gmail.com wrote in message news:banlktinsckfvpnrscska4svdgq9zgvu...@mail.gmail.com... If we proceeded to remove the feature, they could fairly easily add it into Popups or one of the other JS citadels. I don't see a way to do it in JS w/o lengthy expensive API checks.. Leo So they'll do it with lengthy API checks, just like the rest of the data Popups gathers. We tell them not to worry about performance, remember? The number of people who would use a JS implementation is probably small enough for it not to be particularly severe. --HM ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Extension bundling for 1.18
On Wed, Jun 8, 2011 at 3:21 PM, Rob Lanphier ro...@wikimedia.org wrote: On Wed, Jun 8, 2011 at 1:30 PM, Roan Kattouw roan.katt...@gmail.com wrote: This argument completely misses the point. The (probably trivial) extra work is in the tarballing process and doesn't touch anything else. There's no way it can subtly break things. You're willing to say there are exactly *zero* fixes that would be needed to be done in trunk and merged into 1.18 as a result of making this change? Trunk and 1.18 *and* 1.17 already have this ability; all that's required is to drop some directories into the tarball, and they'll be available for selection in the installer. If any extension doesn't install work successfully in this manner, don't put it in the tarball. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r89252]: New comment added
User Tim Starling posted a comment on MediaWiki.r89252. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89252#c17887 Commit summary: * MFT r89250. only the tableExists function ad 1.17 already supports user-dbname difference Comment: It's easier to add a $this-addQuotes() than to confirm that it is secure by following the data flow in every place where it is used and confirming that there's no way for user input to find its way into this function. That's why our security policy is to always escape, regardless of the data source. As for the release notes, I'm asking if there is some user-visible consequence of fixing tableExists(). For instance, does it avoid an error message on install or upgrade? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89741]: New comment added
User Tim Starling posted a comment on MediaWiki.r89741. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89741#c17888 Commit summary: 1.17: MFT r84739, r89707 Comment: Why are you not writing release notes? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r88946]: Revision status changed
User Tim Starling changed the status of MediaWiki.r88946. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/88946#c0 Commit summary: Fix Bug #28829 - “Failure to subscribe to mediawiki-announce is not reported to the user” Wasn't able to test an actual subscription failure, so I faked it. Error message showed. Tried double-subscribing an address and only got an emailed “privacy alert” from mailman. Doing a double-subscription manually didn't get any web-based error. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r89748]: Revision status changed
User Tim Starling changed the status of MediaWiki.r89748. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/89748#c0 Commit summary: MFT r89743 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] irc.wikimedia.org status
irc.wikimedia.org has been down for six hours without any information can someone please take a look and give us some information? John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] irc.wikimedia.org status
John wrote: irc.wikimedia.org has been down for six hours without any information can someone please take a look and give us some information? It seems up to me. According to the server admin log,[1] Mark started ircd on the host a few hours ago. MZMcBride [1] http://wikitech.wikimedia.org/index.php?diff=34424oldid=34423diffonly=1 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] irc.wikimedia.org status
http://status.wikimedia.org/8777/156492/IRC-RecentChanges has some pretty graphs. On Wed, Jun 8, 2011 at 5:54 PM, MZMcBride z...@mzmcbride.com wrote: John wrote: irc.wikimedia.org has been down for six hours without any information can someone please take a look and give us some information? It seems up to me. According to the server admin log,[1] Mark started ircd on the host a few hours ago. MZMcBride [1] http://wikitech.wikimedia.org/index.php?diff=34424oldid=34423diffonly=1 ___ 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
Re: [Wikitech-l] irc.wikimedia.org status
It's been fixed for three hours now. One thing to note is that the IP address for the server changed. The DNS entry's cache settings are for one hour, you should be able to access it without issues now. I just tried it and it's working for me. When was the last time you tried it? On Wed, Jun 8, 2011 at 5:49 PM, John phoenixoverr...@gmail.com wrote: irc.wikimedia.org has been down for six hours without any information can someone please take a look and give us some information? John ___ 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
