[MediaWiki-CodeReview] [MediaWiki r99200]: New comment added, and revision status changed
User Siebrand changed the status of MediaWiki.r99200.
Old Status: new
New Status: fixme
User Siebrand also posted a comment on MediaWiki.r99200.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99200#c23914
Commit summary:
MoodBar feedback dashboard: Implement a means to hide individual comments. For
now, does *not* include actual implementations of the forms to actually show
and hide individual items, just the logic for when an item is actually hidden
Comment:
{{messagedocumentation}}
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99131]: New comment added
User Saper posted a comment on MediaWiki.r99131. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99131#c23915 Commit summary: * Cleaned up cancel button on review form to only show on diffs * Review form HTML/CSS cleanup Comment: r99182 removes the Cancel link in trunk ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Preliminary git module splitup notes (MediaWiki core extensions)
On 11-10-06 10:43 PM, Victor Vasiliev wrote: On Wed, Oct 5, 2011 at 5:33 AM, Brion Vibber br...@pobox.com wrote: You can check out extensions as separate repositories directly into subfolders within core's 'extensions' dir for a ready-to-run system. But, you *do* need to do either manually or scripted iteration over them to pull updates or commit across repos. Git's submodules might be a useful way to help automate checkouts, but they introduce their own complications for maintenance. That does not sound like The Bright Git Future. --vvv ;) No, The Bright Git Future is when I can commit from my server, pull the changes to my local working copy, and push them to the central repo from there. Since I develop on my servers, but don't trust them with my private keys. I currently do this with absolute hacks involving ssh up on both working copies, piping svn diff through ssh into patch, commit, then another svn up. The fact I have unfinished code lying around in my working copies just makes things even more fun (I always make use of git's lovely index which lets me pick piece by piece what parts of the diff to actually commit). Not to mention that the svn diff trick has issues if I have a new file. This of course leads to lovely commits like: This: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/96668 And this: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/96273 Humorous ones like this: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/97180 ^_^ And this kind of lovely commit: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/85242 By the way, when we switch to get I'll finally be able to get rid of half the reason I make some commits without bothering to test them ;). Since it will no longer be a huge hassle to make the change in a place I can actually test it. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Preliminary git module splitup notes (MediaWiki core extensions)
On Fri, Oct 7, 2011 at 3:48 PM, Daniel Friesen li...@nadir-seen-fire.com wrote: I currently do this with absolute hacks involving ssh up on both working copies, piping svn diff through ssh into patch, commit, then another svn up. The fact I have unfinished code lying around in my working copies just makes things even more fun (I always make use of git's lovely index which lets me pick piece by piece what parts of the diff to actually commit). Not to mention that the svn diff trick has issues if I have a new file. I also use two working copies (one read-only for development and one for commiting). This is mostly due to lack of svn stash and local branches (I have at least two large patches on my local copy I'm forced to manually unmerge by editing svn diffs). --vvv ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fundraiser banner causes mixed-content problems in HTTPS pages
Here's part of the long tail of making everything fully compliant with HTTPS page delivery. I've noticed that there seem to be mixed-content problems with HTTPS-loaded Wikipedia pages which display the fundraiser banner. At least part of the problem seems to be this image: http://upload.wikimedia.org/wikipedia/foundation/3/3d/CNbasicButtonParts.png which is apparently loaded by the banner via a URL hard-coded into the central notice CSS. Can anyone else verify this? Is there any simple and efficient way of fixing this in a way that will just work in other similar cases, other than writing custom javascript for this special case, or using the data: URI scheme? -- Neil ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Wikipedia Android app – Support Wikipedia version
(Cross-posting this to fundraising mailing list, as I suspect not many Fundraisers read Wikitech-l) Summary: WMF is going to release an Android Wikipedia app shortly (other mobile OS will get an app, too) On 10/07/2011 03:25 AM, Tomasz Finc wrote: One good question that Brion just asked me was when we plan to release this app to the Android market. How about making a free version and an (identical!) Support Wikipedia version that has absolutly the same features, but costs $2 that go to WMF as a donation? :) Why we should do this: It's an extremly simple way for users to donate money. No entering of credit card or bank account information necessary, just select one app instead of another. Very rough estimate: 20M total downloads, 0.5% download the Support Wikipedia version for $2, that's $200k. Sounds like something we should experiment with. -- Tobias 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] Fundraiser banner causes mixed-content problems in HTTPS pages
On 07/10/11 13:46, Roan Kattouw wrote: On Fri, Oct 7, 2011 at 2:39 PM, Neil Harrisn...@tonal.clara.co.uk wrote: Is there any simple and efficient way of fixing this in a way that will just work in other similar cases, other than writing custom javascript for this special case, or using the data: URI scheme? Yes, use a protocol-relative URL: //upload.wikimedia.org/wikipedia/foundation/3/3d/CNbasicButtonParts.png Oh! I hadn't thought of that because it was a cross-domain load. Of course it does, that'll just work. -- N. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r93246]: Revision status changed
User MaxSem changed the status of MediaWiki.r93246. Old Status: fixme New Status: reverted Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/93246 Commit summary: (bug 15641) prevent blocked administrators from accessing deleted revisions. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99195]: New comment added
User G.Hagedorn posted a comment on MediaWiki.r99195. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99195#c23916 Commit summary: Reverted r83757, ipaddress msg in used by GlobalBlocking Comment: Should it not be defined in extension GlobalBlocking then? Else please consider tagging for 1.18 as well. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99211]: New comment added
User Siebrand posted a comment on MediaWiki.r99211. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99211#c23917 Commit summary: Revert r93246: besides the problems pointed out at CR, it also causes bug 31403, wreaking havoc on large wikis Comment: The original commit touched 11 files. This revert touches 8, and is the only follow-up. Are you sure it's a complete revert? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98889]: Revision status changed
User Siebrand changed the status of MediaWiki.r98889. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98889 Commit summary: Followup r98578 convert nulls to string ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98779]: Revision status changed
User Siebrand changed the status of MediaWiki.r98779. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98779 Commit summary: Fix for this fatal: PHP Fatal error: Call to a member function getText() on a non-object in /www/w/extensions/Translate/utils/TranslationHelpers.php on line 896 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98626]: Revision status changed
User Siebrand changed the status of MediaWiki.r98626. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98626 Commit summary: Swap page_id to rt_page, which is in an index. No more filesorts. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98624]: Revision status changed
User Siebrand changed the status of MediaWiki.r98624. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98624 Commit summary: Updated README, I really should get into habit of doing this always ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98793]: Revision status changed
User Siebrand changed the status of MediaWiki.r98793. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98793 Commit summary: Add ApiExlorer (r98191) to translatewiki.net ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98191]: New comment added, and revision status changed
User Siebrand changed the status of MediaWiki.r98191. Old Status: new New Status: fixme User Siebrand also posted a comment on MediaWiki.r98191. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98191#c23918 Commit summary: Adding ApiExplorer extension which uses the API to dynamically generate API documentation on Special:ApiExplorer. Depends on the JavascriptAPI extension (currently in Wikia codebase). Would be nice to make this extension able to be aware of the examples that api.php submits even to let it submit the examples. Comment: This extension uses some very outdated concepts and should be updated. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99211]: New comment added
User MaxSem posted a comment on MediaWiki.r99211. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99211#c23919 Commit summary: Revert r93246: besides the problems pointed out at CR, it also causes bug 31403, wreaking havoc on large wikis Comment: The changes to SkinTemplate and SpecialUpload were removed before me (careless conflict resolution?). Thanks for noticing that SpecialUndelete is not like them - reverted. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r97822]: Revision status changed
User Siebrand changed the status of MediaWiki.r97822. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97822 Commit summary: FU r97819: Move commented out message to the end of the 'en' section. It seems sync-groups.php of Tranlate is confused about it and ignores further messages until a new language section begins ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r97820]: Revision status changed
User Siebrand changed the status of MediaWiki.r97820. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97820 Commit summary: FU r97819/r97061: Add missing messaga 'grouppage-linkadmin' ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r97619]: Revision status changed
User Siebrand changed the status of MediaWiki.r97619. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97619 Commit summary: Followup r97618: Make new message optional instead ignore for translatewiki.net (per r97566) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98792]: Revision status changed
User Siebrand changed the status of MediaWiki.r98792. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98792 Commit summary: Tweak message file remove redundant description line from extensionCredits ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Wikipedia Android app – Support Wikipedia version
- Original Message - From: church.of.emacs.ml church.of.emacs...@googlemail.com How about making a free version and an (identical!) Support Wikipedia version that has absolutly the same features, but costs $2 that go to WMF as a donation? :) Why we should do this: It's an extremly simple way for users to donate money. No entering of credit card or bank account information necessary, just select one app instead of another. I concur. On a separate topic, it would probably be useful if someone built nightlies of the repo, so that those of us who are good usability test types but not necessarily coders or set up to build can contribute too; the original announcement didn't sound like that was in the plans. Is it practical? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r97061]: New comment added, and revision status changed
User Siebrand changed the status of MediaWiki.r97061.
Old Status: new
New Status: fixme
User Siebrand also posted a comment on MediaWiki.r97061.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97061#c23920
Commit summary:
phase II social tools: LinkFilter, allows users to submit links and privileged
users to approve them. Tested and built against MW 1.16.0, ResourceLoader
support is there but it hasn't been tested so it probably is buggy (i.e. using
addModules() instead of addModuleScripts()/addModuleStyles()), but I'll fix
that later.
Requires PHP 5.3+.
Comment:
{{messagedocumentation}}
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r97819]: Revision status changed
User Siebrand changed the status of MediaWiki.r97819. Old Status: deferred New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97819 Commit summary: Some message tweaks, Add extension per r97061 to translatewiki.net ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84534]: New comment added
User Happy-melon posted a comment on MediaWiki.r84534. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84534#c23921 Commit summary: (hopefully) last bit of heavy lifting in Block.php: now that we've internalised most of the variables, untangle their twisted connections to the database layer and remove various now-unused protected methods and variables. Comment: http://pastebin.com/ikAauVQs is the patch I would suggest to resolve the problem, but I do not have a working CentralAuth system set up to test it on. Would anyone mind having a look? It's basically the same method as the orgiginal patch, but a) suggests a long-term plan to resolve the issue more cleanly, and b) makes an attempt to find the steward's local id and uses it if possible. I think these blocks would be displayed wrongly in Special:BlockList (both with and without this patch), although since their entire purpose is to ''not'' be displayed, that's not a major concern. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Fundraiser banner causes mixed-content problems in HTTPS pages
I've let the fundraising production team (the folks responsible for building banners and landing pages) know about this issue and have asked them to use protocol relative URLs from now on. Thanks for bringing it up! Arthur On Fri, Oct 7, 2011 at 6:22 AM, Neil Harris n...@tonal.clara.co.uk wrote: On 07/10/11 13:46, Roan Kattouw wrote: On Fri, Oct 7, 2011 at 2:39 PM, Neil Harrisn...@tonal.clara.co.uk wrote: Is there any simple and efficient way of fixing this in a way that will just work in other similar cases, other than writing custom javascript for this special case, or using the data: URI scheme? Yes, use a protocol-relative URL: //upload.wikimedia.org/wikipedia/foundation/3/3d/CNbasicButtonParts.png Oh! I hadn't thought of that because it was a cross-domain load. Of course it does, that'll just work. -- N. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Arthur Richards Software Engineer Fundraising/Features/Offline/Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Fundraiser banner causes mixed-content problems in HTTPS pages
From Jon Søby (one of the production coordinators): Fixed now in MediaWiki:Centralnotice-shared-button-2010http://meta.wikimedia.org/w/index.php?title=MediaWiki%3ACentralnotice-shared-button-2010action=historysubmitdiff=2971651oldid=2269883, which is used by the story banner at least. Already fixed in MediaWiki:Centralnotice-shared-button-2011http://meta.wikimedia.org/w/index.php?title=MediaWiki:Centralnotice-shared-button-2011, which will be used for new banners. On Fri, Oct 7, 2011 at 8:11 AM, Arthur Richards aricha...@wikimedia.orgwrote: I've let the fundraising production team (the folks responsible for building banners and landing pages) know about this issue and have asked them to use protocol relative URLs from now on. Thanks for bringing it up! Arthur On Fri, Oct 7, 2011 at 6:22 AM, Neil Harris n...@tonal.clara.co.ukwrote: On 07/10/11 13:46, Roan Kattouw wrote: On Fri, Oct 7, 2011 at 2:39 PM, Neil Harrisn...@tonal.clara.co.uk wrote: Is there any simple and efficient way of fixing this in a way that will just work in other similar cases, other than writing custom javascript for this special case, or using the data: URI scheme? Yes, use a protocol-relative URL: //upload.wikimedia.org/wikipedia/foundation/3/3d/CNbasicButtonParts.png Oh! I hadn't thought of that because it was a cross-domain load. Of course it does, that'll just work. -- N. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Arthur Richards Software Engineer Fundraising/Features/Offline/Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 -- Arthur Richards Software Engineer Fundraising/Features/Offline/Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia Android app – Support Wikipedia version
Hoi. One distinct advantage of daily builds is that you use these to distribute improved localisations... Will this app come to translatewiki.net ? If so, it does make sense to build this functionality that is similar to what is offered by thr localisationupdate extrnsion. Thanks, GerardM 2011/10/7 Jay Ashworth j...@baylink.com - Original Message - From: church.of.emacs.ml church.of.emacs...@googlemail.com How about making a free version and an (identical!) Support Wikipedia version that has absolutly the same features, but costs $2 that go to WMF as a donation? :) Why we should do this: It's an extremly simple way for users to donate money. No entering of credit card or bank account information necessary, just select one app instead of another. I concur. On a separate topic, it would probably be useful if someone built nightlies of the repo, so that those of us who are good usability test types but not necessarily coders or set up to build can contribute too; the original announcement didn't sound like that was in the plans. Is it practical? 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r99214]: Revision status changed
User MaxSem changed the status of MediaWiki.r99214. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99214 Commit summary: Follow-up r98191: * remove unneeded wfLoadExtensionMessages() call. * added two FIXMEs. * simplify extension description * simplify 'apiexplorer-intro' ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99206]: New comment added
User MaxSem posted a comment on MediaWiki.r99206. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99206#c23922 Commit summary: Fix some egregious XSS vulnerabilities in EmbedVideo. Still quite a lot of code smells in here, but it certainly looks *less* dangerous... Comment: Isn't it being maintained [https://github.com/Whiteknight/mediawiki-embedvideo.git at GutHub] now? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99206]: New comment added
User Happy-melon posted a comment on MediaWiki.r99206. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99206#c23923 Commit summary: Fix some egregious XSS vulnerabilities in EmbedVideo. Still quite a lot of code smells in here, but it certainly looks *less* dangerous... Comment: I believe so, yes. I just threw this together in SVN because someone was asking about it on IRC and it was a very simple change to make; and I couldn't be bothered to jump through whatever hoops were needed to send it to git when I could commit it to SVN straight away. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99206]: New comment added
User MaxSem posted a comment on MediaWiki.r99206. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99206#c23924 Commit summary: Fix some egregious XSS vulnerabilities in EmbedVideo. Still quite a lot of code smells in here, but it certainly looks *less* dangerous... Comment: We might need to delete one of them. Because it's easier, I propose to ditch our copy:P ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99206]: New comment added
User Happy-melon posted a comment on MediaWiki.r99206. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99206#c23925 Commit summary: Fix some egregious XSS vulnerabilities in EmbedVideo. Still quite a lot of code smells in here, but it certainly looks *less* dangerous... Comment: Surely this is one of the innumerable issues which will be magically resolved by the Great Git Migration...? tt:P/tt Might as well leave it until then, I say. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] Improving tests post-1.18 deployment: We need acceptance tests!
This week I've been watching [[WP:VPT]] and copying relevant issues into bug reports on Bugzilla. You can see the reports here: https://bugzilla.wikimedia.org/29876 I would like to make these bug reports more profitable, though. As Brion has said (http://en.wikipedia.org/w/index.php?diff=454166570), we don't really have good acceptance tests to ensure that we produce consistent behavior with each release. To begin to solve this, please help me tag relevant bugs need-unittest or need-parsertest and then look for that tag and help write tests. If we do this right, the 1.19 release will be a *lot* smoother. Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia Android app – Support Wikipedia version
2011/10/7 Gerard Meijssen gerard.meijs...@gmail.com Hoi. One distinct advantage of daily builds is that you use these to distribute improved localisations... Will this app come to translatewiki.net ? If so, it does make sense to build this functionality that is similar to what is offered by thr localisationupdate extrnsion. We're working on getting the localization infrastructure set up: https://bugzilla.wikimedia.org/show_bug.cgi?id=31467 Should end up on TWN soon. :) -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia Android app – Support Wikipedia version
2011/10/7 church.of.emacs.ml church.of.emacs...@googlemail.com How about making a free version and an (identical!) Support Wikipedia version that has absolutly the same features, but costs $2 that go to WMF as a donation? :) Why we should do this: It's an extremly simple way for users to donate money. No entering of credit card or bank account information necessary, just select one app instead of another. This would be pretty straightforward to do, I think. Very rough estimate: 20M total downloads, 0.5% download the Support Wikipedia version for $2, that's $200k. Note that the app-store middlemen take a 30% transaction fee, so we'd get $140k and Google or Amazon (or Apple if we do an iPhone version same way) gets $60k. 30% sounds high but probably isn't much worse than individual $2 credit card payments. :) -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia Android app – Support Wikipedia version
2011/10/7 Jay Ashworth j...@baylink.com On a separate topic, it would probably be useful if someone built nightlies of the repo, so that those of us who are good usability test types but not necessarily coders or set up to build can contribute too; the original announcement didn't sound like that was in the plans. Is it practical? I think that would be pretty easy to set up; stuck a note in BZ so we don't forget: https://bugzilla.wikimedia.org/show_bug.cgi?id=31498 -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia Android app – Support Wikipedia version
2011/10/7 Brion Vibber br...@pobox.com: Note that the app-store middlemen take a 30% transaction fee, so we'd get $140k and Google or Amazon (or Apple if we do an iPhone version same way) gets $60k. 30% sounds high but probably isn't much worse than individual $2 credit card payments. :) I wonder if it's possible to do a deal to get more of the store cut ... I'm sure the fundraisers will give it a go. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wikipedia Android app – Support Wikipedia version
How about we negotiate 0% transaction charge and they match the donation. It shows their support and is chump change to them. On Oct 7, 2011 9:47 AM, Brion Vibber br...@pobox.com wrote: 2011/10/7 church.of.emacs.ml church.of.emacs...@googlemail.com How about making a free version and an (identical!) Support Wikipedia version that has absolutly the same features, but costs $2 that go to WMF as a donation? :) Why we should do this: It's an extremly simple way for users to donate money. No entering of credit card or bank account information necessary, just select one app instead of another. This would be pretty straightforward to do, I think. Very rough estimate: 20M total downloads, 0.5% download the Support Wikipedia version for $2, that's $200k. Note that the app-store middlemen take a 30% transaction fee, so we'd get $140k and Google or Amazon (or Apple if we do an iPhone version same way) gets $60k. 30% sounds high but probably isn't much worse than individual $2 credit card payments. :) -- 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
Re: [Wikitech-l] Wikipedia Android app – Support Wikipedia version
Phone Gap build might be able to do this for us. If not I'm sure were could rig something up. On Oct 7, 2011 9:52 AM, Brion Vibber br...@pobox.com wrote: 2011/10/7 Jay Ashworth j...@baylink.com On a separate topic, it would probably be useful if someone built nightlies of the repo, so that those of us who are good usability test types but not necessarily coders or set up to build can contribute too; the original announcement didn't sound like that was in the plans. Is it practical? I think that would be pretty easy to set up; stuck a note in BZ so we don't forget: https://bugzilla.wikimedia.org/show_bug.cgi?id=31498 -- 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
[Wikitech-l] Bug 31424 - Anecdotal evidence of IE 8 problems
Hi everyone, We need your help. We have a number of reports on the various village pumps, helpdesks, Twitter, and such that IE8 users are experiencing crashes merely by visiting our site. Here's the bug report: https://bugzilla.wikimedia.org/show_bug.cgi?id=31424 Given the frequency and diversity of reports, there is almost certainly something to this, even though we don't yet have a solid repro case that a developer can actually use to fix this. Here's what we need. If you are actually seeing crashes, we would love to know exact browser version (e.g. IE 8.0.7601.17514), exact operating system version, all plugins installed and their exact versions, and how much RAM your machine has. Please report your findings either in the bug report above, or if you're more comfortable on-wiki, then here: http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#If_you_can_make_IE_crash_pretty_reliably_we_need_your_help. Thanks! Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r99213]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r99213. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99213 Commit summary: Follow-up r99211: forgot to revert one file ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99211]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r99211. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99211 Commit summary: Revert r93246: besides the problems pointed out at CR, it also causes bug 31403, wreaking havoc on large wikis ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98845]: Revision status changed
User Raindrift changed the status of MediaWiki.r98845. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98845 Commit summary: add comments, remove one commented out line, remove spurious return that causes linting errs (it should use callbacks, returns nothing) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98846]: Revision status changed
User Raindrift changed the status of MediaWiki.r98846. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98846 Commit summary: return empty array for number of files in non-FileAPI browsers; improved comment docs ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99211]: New comment added
User Aaron Schulz posted a comment on MediaWiki.r99211. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99211#c23927 Commit summary: Revert r93246: besides the problems pointed out at CR, it also causes bug 31403, wreaking havoc on large wikis Comment: That revision does not appear to even be in 1.18wmf1. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99204]: New comment added
User Nikerabbit posted a comment on MediaWiki.r99204.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99204#c23928
Commit summary:
* Follow-up r99112: use $user instead of $wgUser.
* Introduce $wgTranslateNewsletterPreference was introduced (default: false).
Setting this to true, will once again add the Do not send me e-mail
newsletters preference.
Comment:
=== true is redundant with booleans, and instead of indenting the whole thing
inside if, you could do if ( !$foo ) { return true; }
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99205]: New comment added
User Nikerabbit posted a comment on MediaWiki.r99205. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99205#c23929 Commit summary: Update EmbedVideo to latest version from github (https://github.com/Whiteknight/mediawiki-embedvideo) Comment: Ewww! This is exactly what we don't want. Translators keep translating the extension, which is develop elsewhere and doesn't even use them. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99222]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r99222. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99222 Commit summary: * Use local context instead of global variables, made static function in CreditsAction non-static so that they can use the context * Added missing Action::msg() method ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Google's cached pages are much faster than wiki*edia's
On Thursday, October 6, 2011, IAlex ialex.w...@gmail.com wrote: Le 7 oct. 2011 à 06:21, Chad a écrit : Well we do serve the logged out cookie. What real purpose that serves, I don't know :) It's to bypass the browser cache, and to not let the user see a page with it's user name at the top when he just logged out. Couldn't deleting cookies have the same effect? If we do want to set or keep cookies on logout, do they need to be included in X-Vary-Options and bypass squid caching? We could also consider loading login/userbar stuff via javascript and allow logged in users to take advantage of squid caching provided care was taken for active editors. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bug 31424 - Anecdotal evidence of IE 8 problems
I updated the bug, but it looks like this was the issue: http://bugs.jquery.com/ticket/9823 So, now we must upgrade or downgrade (carefully!) - Trevor On Fri, Oct 7, 2011 at 10:40 AM, Rob Lanphier ro...@wikimedia.org wrote: Hi everyone, We need your help. We have a number of reports on the various village pumps, helpdesks, Twitter, and such that IE8 users are experiencing crashes merely by visiting our site. Here's the bug report: https://bugzilla.wikimedia.org/show_bug.cgi?id=31424 Given the frequency and diversity of reports, there is almost certainly something to this, even though we don't yet have a solid repro case that a developer can actually use to fix this. Here's what we need. If you are actually seeing crashes, we would love to know exact browser version (e.g. IE 8.0.7601.17514), exact operating system version, all plugins installed and their exact versions, and how much RAM your machine has. Please report your findings either in the bug report above, or if you're more comfortable on-wiki, then here: http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28technical%29#If_you_can_make_IE_crash_pretty_reliably_we_need_your_help . Thanks! Rob ___ 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 r84057]: New comment added, and revision status changed
User MaxSem changed the status of MediaWiki.r84057. Old Status: resolved New Status: fixme User MaxSem also posted a comment on MediaWiki.r84057. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84057#c23930 Commit summary: bug 28040 Turkish: properly handle dotted and dotless i As mentioned by Bawolff on code review, r83970 only handled case change of the first character lacking full strings support. This patch override the uc and lc methods for the Turkish language (tr) using preg_replace() which know about unicode. Other possible choices would have been: - strtr() = outputs garbage - mbstring = can not know we handle turkish and transform i to I! I have amended the RELEASE-NOTES to reflect this patch. Some new tests are added as well to cover the regular functions as well as the specific Turkish overriding. Result in testdox: LanguageTr [x] Change case of first char being dotted and dotless i [x] Language tr lower casing override [x] Language tr upper casing override [x] Upper casing of a string with dotted and dot less i [x] Lower casing of a string with dotted and dot less i Comment: Causes bug 31490 - lcfirst and ucfirst parser functions do not work ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84057]: New comment added
User Brion VIBBER posted a comment on MediaWiki.r84057.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84057#c23931
Commit summary:
bug 28040 Turkish: properly handle dotted and dotless i
As mentioned by Bawolff on code review, r83970 only handled case change
of the first character lacking full strings support.
This patch override the uc and lc methods for the Turkish language (tr)
using preg_replace() which know about unicode. Other possible choices
would have been:
- strtr() = outputs garbage
- mbstring = can not know we handle turkish and transform i to I!
I have amended the RELEASE-NOTES to reflect this patch.
Some new tests are added as well to cover the regular functions as
well as the specific Turkish overriding. Result in testdox:
LanguageTr
[x] Change case of first char being dotted and dotless i
[x] Language tr lower casing override
[x] Language tr upper casing override
[x] Upper casing of a string with dotted and dot less i
[x] Lower casing of a string with dotted and dot less i
Comment:
Specifically it looks like it breaks case-insensitive matching of magic words
that contain the letter 'i' or 'I'.
So nowiki{{ucfirst:x}}/nowiki doesn't match with the 'ucfirst' keyword
anymore, whereas 'UCFIRST' or 'ucfırst' do.
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98191]: New comment added
User SColombo posted a comment on MediaWiki.r98191. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98191#c23932 Commit summary: Adding ApiExplorer extension which uses the API to dynamically generate API documentation on Special:ApiExplorer. Depends on the JavascriptAPI extension (currently in Wikia codebase). Would be nice to make this extension able to be aware of the examples that api.php submits even to let it submit the examples. Comment: Updated in r99229. Thanks for the i18n fixes and the @fixmes :) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98191]: Revision status changed
User SColombo changed the status of MediaWiki.r98191. Old Status: fixme New Status: new Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98191 Commit summary: Adding ApiExplorer extension which uses the API to dynamically generate API documentation on Special:ApiExplorer. Depends on the JavascriptAPI extension (currently in Wikia codebase). Would be nice to make this extension able to be aware of the examples that api.php submits even to let it submit the examples. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84718]: New comment added
User Platonides posted a comment on MediaWiki.r84718. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84718#c23933 Commit summary: Move WatchlistEditor.php to /specials since inside it is essentially a complete special page. Make it subclass SpecialPage and do all the usual stuff. Rewrite it to use HTMLForm and other exciting things, and give it a good general clean up. Comment: Bug 31502 blames this for removing the TOC ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84765]: New comment added
User Bryan posted a comment on MediaWiki.r84765. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84765#c23934 Commit summary: (bug 28070) Fix watchlist RSS for databases that store timestamps in a real timestamp field by using Database::timestamp(). Tested by Dan Nessett on 1.16. Not tested on trunk, but no reason why it should not work. Comment: Follow-up in r99236, but that one requires an intermediate revision r99138. Alternatively the timestamp() call should be changed to timestampOrNull() ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] More on testing
Because of the interest on [[WP:VPT]] in making deployments of MW on the cluster go more smoothly, I've forked the discussion to a sub-page: http://hexm.de/87 Please check it out and contribute! Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r84057]: New comment added
User MaxSem posted a comment on MediaWiki.r84057. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84057#c23935 Commit summary: bug 28040 Turkish: properly handle dotted and dotless i As mentioned by Bawolff on code review, r83970 only handled case change of the first character lacking full strings support. This patch override the uc and lc methods for the Turkish language (tr) using preg_replace() which know about unicode. Other possible choices would have been: - strtr() = outputs garbage - mbstring = can not know we handle turkish and transform i to I! I have amended the RELEASE-NOTES to reflect this patch. Some new tests are added as well to cover the regular functions as well as the specific Turkish overriding. Result in testdox: LanguageTr [x] Change case of first char being dotted and dotless i [x] Language tr lower casing override [x] Language tr upper casing override [x] Upper casing of a string with dotted and dot less i [x] Lower casing of a string with dotted and dot less i Comment: We could normalize magic words by passing them through lc() and then uc() in LocalisationCache, but I don't know what else this revision could potentially break. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99234]: New comment added
User Nikerabbit posted a comment on MediaWiki.r99234. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99234#c23937 Commit summary: New version: 2.3-alpha Comment: It's not undocumented anymore? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99242]: Revision status changed
User Meno25 changed the status of MediaWiki.r99242. Old Status: new New Status: deferred Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99242 Commit summary: Localisation updates for ToolserverI18N messages from translatewiki.net ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99241]: Revision status changed
User Meno25 changed the status of MediaWiki.r99241. Old Status: new New Status: deferred Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99241 Commit summary: Localisation updates for core and extension messages from translatewiki.net ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99234]: New comment added
User Yaron Koren posted a comment on MediaWiki.r99234. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99234#c23938 Commit summary: New version: 2.3-alpha Comment: Well, it's sort of documented. :) It's documented in the code, but I'm not planning to mention it in the actual extension documentation. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Google's cached pages are much faster than wiki*edia's
On 11-10-07 11:17 AM, Asher Feldman wrote: On Thursday, October 6, 2011, IAlex ialex.w...@gmail.com wrote: Le 7 oct. 2011 à 06:21, Chad a écrit : Well we do serve the logged out cookie. What real purpose that serves, I don't know :) It's to bypass the browser cache, and to not let the user see a page with it's user name at the top when he just logged out. Couldn't deleting cookies have the same effect? If we do want to set or keep cookies on logout, do they need to be included in X-Vary-Options and bypass squid caching? We could also consider loading login/userbar stuff via javascript and allow logged in users to take advantage of squid caching provided care was taken for active editors. - Logged in user visits [[Main Page]] we send them a Last-Modified header - User re-visits [[Main Page]], they send us an If-Modified-Since, and we send them back a 304 - User logs out and the cookie is set - User re-visits [[Main Page]], they send us an If-Modified-Since, because the logout cookie is set we ignore it and send back a 200 so that they don't re-use that previous cache that had their username in the header. - ...as a side effect even after their cache has been re-freshed with a proper anon view we still continue to ignore their requests for a 304. It is needed the way we do things right now. But I do agree it's a little off. Bypassing squids for an anon doesn't really have much purpose. And rather than this cookie hack I think the proper way to deal with the browser's cache would be with a proper ETag. Instead of Last-Modified + Cookie we have an ETag set that includes the user's user id and perhaps user_touched. Then when they log out because the ETag is different their browser doesn't re-use the cache it had. We could deal with the lack of current ETag data by putting Last-Modified in the ETag with the extra pieces. The idea of user_touched was so that things like user demotion wouldn't leave delete links in their interface. Though that may be excessive. Then again using user_touched also would make sure that a newtalk message shows up so it may be proper. For the anon ETag we would probably use something like 'anon' if $wgShowIPinHeader is on and the ip address otherwise (so that a change in dynamic ip won't leave the old ip in their header). ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r99224]: New comment added
User תומר א. posted a comment on MediaWiki.r99224. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99224#c23939 Commit summary: Follow-up r98430, use dedicated error message for filename too long error. Adds 'filename-toolong' message. Comment: I verified this bug in r99224 and it works well for me. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84057]: New comment added
User Szoszv posted a comment on MediaWiki.r84057. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84057#c23940 Commit summary: bug 28040 Turkish: properly handle dotted and dotless i As mentioned by Bawolff on code review, r83970 only handled case change of the first character lacking full strings support. This patch override the uc and lc methods for the Turkish language (tr) using preg_replace() which know about unicode. Other possible choices would have been: - strtr() = outputs garbage - mbstring = can not know we handle turkish and transform i to I! I have amended the RELEASE-NOTES to reflect this patch. Some new tests are added as well to cover the regular functions as well as the specific Turkish overriding. Result in testdox: LanguageTr [x] Change case of first char being dotted and dotless i [x] Language tr lower casing override [x] Language tr upper casing override [x] Upper casing of a string with dotted and dot less i [x] Lower casing of a string with dotted and dot less i Comment: so, do not work special pages (özel sayfalar). http://tr.wikipedia.org/wiki/Special:SpecialPages or http://tr.wikipedia.org/wiki/%C3%96zel:%C3%96zelSayfalar ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] Request for developers: the Video extension
Hi all, as you may know, MediaWiki supports video embedding (from sites such as YouTube, for example) only via separately installable extensions. Many of these extensions are parser hooks (such as youtube), and as such they are a bit difficult to use for the average editor and many video embedding extensions are also very hacky and may even contain cross-site scripting (XSS) vulnerabilities. What's the solution? A video extension that supports multiple different providers, is easy to use and is secure. So far none of the existing extensions really match all the given criteria. Until now, that is. Earlier today I committed the Video extension ( http://www.mediawiki.org/wiki/Extension:Video) into the official MediaWiki Subversion repository at http://svn.wikimedia.org/. The Video extension was originally written by David Pean, who is best known for his work on the social tools (http://www.mediawiki.org/wiki/Social_tools), back in 2007 for ArmchairGM (http://en.wikipedia.org/wiki/Wikia#ArmchairGM) and it saw limited use outside ArmchairGM, but the code was never finished. For example, while you could add videos to the wiki, there was no way to delete a video, which would've been a rather easy way for a vandal to troll the wiki. During the past summer, I improved various social extensions (see http://www.mediawiki.org/wiki/Social_tools/Phase_II), including Video. I added support for deleting (and partially for undeleting) videos and I wrote plenty of new provider classes. While the Video extension is in pretty good shape now, it's not yet ready and it needs *your* help! Like I wrote earlier, the deletion of videos is possible, but undeletion support is not as functional, due to the way how Special:Undelete does things. [[Video:Foo]] links can't yet be tracked via Special:WhatLinksHere. And, of course, I'm not sure if Video supports your favorite provider yet. :-) If you are a developer who's interested in video support or you know a developer who'd be interested in helping out, please see http://www.mediawiki.org/wiki/Extension:Video and http://www.mediawiki.org/wiki/Commit_access (if you don't yet have SVN write access). Thanks and regards, -- Jack Phoenix MediaWiki developer ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [Fundraising] Wikipedia Android app – Support Wikipedia version
+∞ This is a fantastic idea. On Fri, Oct 7, 2011 at 10:10 AM, Tomasz Finc tf...@wikimedia.org wrote: How about we negotiate 0% transaction charge and they match the donation. It shows their support and is chump change to them. On Oct 7, 2011 9:47 AM, Brion Vibber br...@pobox.com wrote: 2011/10/7 church.of.emacs.ml church.of.emacs...@googlemail.com How about making a free version and an (identical!) Support Wikipedia version that has absolutly the same features, but costs $2 that go to WMF as a donation? :) Why we should do this: It's an extremly simple way for users to donate money. No entering of credit card or bank account information necessary, just select one app instead of another. This would be pretty straightforward to do, I think. Very rough estimate: 20M total downloads, 0.5% download the Support Wikipedia version for $2, that's $200k. Note that the app-store middlemen take a 30% transaction fee, so we'd get $140k and Google or Amazon (or Apple if we do an iPhone version same way) gets $60k. 30% sounds high but probably isn't much worse than individual $2 credit card payments. :) -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Fundraising mailing list fundrais...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/fundraising -- Arthur Richards Software Engineer Fundraising/Features/Offline/Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r99245]: New comment added
User Jack Phoenix posted a comment on MediaWiki.r99245. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99245#c23941 Commit summary: Video, *the* Video extension. Some things haven't yet been implemented, see my wikitech-l post for details. Comment: The mailing list post in question can be found here: http://lists.wikimedia.org/pipermail/wikitech-l/2011-October/055602.html I also sent it to MediaWiki-l, but it's not yet showing up in the archives, most probably caused by the fact that I'm not a member of MediaWiki-l and thus it got queued. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99245]: New comment added, and revision status changed
User Siebrand changed the status of MediaWiki.r99245.
Old Status: new
New Status: fixme
User Siebrand also posted a comment on MediaWiki.r99245.
Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99245#c23942
Commit summary:
Video, *the* Video extension. Some things haven't yet been implemented, see my
wikitech-l post for details.
Comment:
{{messagedocumentation}}
___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84057]: New comment added
User Hashar posted a comment on MediaWiki.r84057. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84057#c23943 Commit summary: bug 28040 Turkish: properly handle dotted and dotless i As mentioned by Bawolff on code review, r83970 only handled case change of the first character lacking full strings support. This patch override the uc and lc methods for the Turkish language (tr) using preg_replace() which know about unicode. Other possible choices would have been: - strtr() = outputs garbage - mbstring = can not know we handle turkish and transform i to I! I have amended the RELEASE-NOTES to reflect this patch. Some new tests are added as well to cover the regular functions as well as the specific Turkish overriding. Result in testdox: LanguageTr [x] Change case of first char being dotted and dotless i [x] Language tr lower casing override [x] Language tr upper casing override [x] Upper casing of a string with dotted and dot less i [x] Lower casing of a string with dotted and dot less i Comment: We should probably revert this revision on live wikis pending a proper fix. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r97335]: Revision status changed
User Siebrand changed the status of MediaWiki.r97335. Old Status: resolved New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97335 Commit summary: Forgot to press Ctrl-S: r97334 (was: Per initial commit r96356) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99247]: Revision status changed
User Awjrichards changed the status of MediaWiki.r99247. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99247 Commit summary: fixing scope issues for form_placeholders.js ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99250]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r99250. Old Status: new New Status: fixme User Brion VIBBER also posted a comment on MediaWiki.r99250. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99250#c23944 Commit summary: Bug 31445: Section edit links do not show Always generate the mw:editsection placeholders. Remove them if not used. Update the ParserOutput if fetching from ParserCache Comment: This outputs mw:sectionedit tags on printable view, seems to repeat the section name in headings. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99252]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r99252. Old Status: new New Status: fixme User Brion VIBBER also posted a comment on MediaWiki.r99252. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99252#c23945 Commit summary: Forgot to commit this file in r99250. Comment: I still see doubled section titles on printable view: pre h2A nice section span class=mw-headline id=A_nice_section A nice section /span/h2 /pre ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Wikipedia Android app – Support Wikipedia version
2011/10/7 Tomasz Finc tf...@wikimedia.org Phone Gap build might be able to do this for us. If not I'm sure were could rig something up. I think rather than have two identical versions in the Market, which would no doubt confuse a great many people, I would strongly suggest that we implement a pay what you want sliding scale for our apps on both iPhone and Android. If X app store doesn't support it, then I'd suggest we set up our own app repository in addition at something like apps.wikipedia.org. (We should probably be doing that anyway to promote this work.) http://en.wikipedia.org/wiki/Pay_what_you_want Steven ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r99236]: Revision status changed
User Aaron Schulz changed the status of MediaWiki.r99236. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99236 Commit summary: Follow-up r84765, use timestampOrNull ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99253]: New comment added
User Jpostlethwaite posted a comment on MediaWiki.r99253. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99253#c23946 Commit summary: Adding transaction type code and optional parameters for unit testing. Comment: TwoStepAmount.php was not supposed to be committed with debugging information. Debug code was removed. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Git migration planning
Thanks for bringing this up Tomasz - I meant to send a reply about this earlier this week but it fell off my radar. For those that don't know, the Wikimedia repo holds WMF-related resources that are not directly MediaWiki related. The fundraising team and fundraising analytics relies on this repo extensively. It would be a huge win for us if this repo was migrated to Git along with the Mediawiki repo. On Thu, Oct 6, 2011 at 12:46 PM, Tomasz Finc tf...@wikimedia.org wrote: We also want to move over the generic Wikimedia repot. --tomasz On Wed, Oct 5, 2011 at 7:41 AM, Rob Lanphier ro...@wikimedia.org wrote: On Tue, Oct 4, 2011 at 9:21 AM, Merlijn van Deen valhall...@arctus.nl wrote: Currently, svn.wikimedia.org also hosts other repositories, most notably the pywikipedia repository. Is the plan to keep svn.wikimedia.org and svn-based code review online after the switch, or will the pywikipedia repository also have to switch? We're not in a big hurry to shut down our svn services, and pywikipedia is not really tangled up in the MediaWiki codebase, so I don't imagine we'll be rushing to convert it to git. I imagine there will come a day when we want to get out of the svn business, but we have a few months (at least) to figure out our strategy there. In the short term, pywikipedia in svn can peacefully coexist with MediaWiki + extensions in git. Rob ___ 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 -- Arthur Richards Software Engineer Fundraising/Features/Offline/Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r97213]: New comment added, and revision status changed
User Jpostlethwaite changed the status of MediaWiki.r97213. Old Status: new New Status: ok User Jpostlethwaite also posted a comment on MediaWiki.r97213. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97213#c23947 Commit summary: Adds the ability to get the order status from GC. Comment: Will need to add unit testing for this code. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99254]: New comment added, and revision status changed
User Brion VIBBER changed the status of MediaWiki.r99254. Old Status: new New Status: ok User Brion VIBBER also posted a comment on MediaWiki.r99254. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99254#c23948 Commit summary: We don't need anything from the marker. The title is outside. Comment: Ok this seems to resolve the breakages from r99250 r99252. Yay! ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99252]: Revision status changed
User Brion VIBBER changed the status of MediaWiki.r99252. Old Status: fixme New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99252 Commit summary: Forgot to commit this file in r99250. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99250]: Revision status changed
User Brion VIBBER changed the status of MediaWiki.r99250. Old Status: fixme New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99250 Commit summary: Bug 31445: Section edit links do not show Always generate the mw:editsection placeholders. Remove them if not used. Update the ParserOutput if fetching from ParserCache ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r97102]: Revision status changed
User Jpostlethwaite changed the status of MediaWiki.r97102. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97102 Commit summary: implement basic iframe solution, add some comments ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98926]: New comment added
User Awjrichards posted a comment on MediaWiki.r98926. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98926#c23949 Commit summary: MFT r96211 Comment: Not really - I probably didn't even realize it was only a prop change and just wanted consistency between what was in trunk and deployment. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r97779]: Revision status changed
User Jpostlethwaite changed the status of MediaWiki.r97779. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97779 Commit summary: adding allowClickjacking() so that we can include the special page in an iframe ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r97833]: Revision status changed
User Jpostlethwaite changed the status of MediaWiki.r97833. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97833 Commit summary: Card #282 - tiny bug fix. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98486]: Revision status changed
User Awjrichards changed the status of MediaWiki.r98486. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98486 Commit summary: Enabled User::isValidEmailAddr() validator. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98915]: Revision status changed
User Awjrichards changed the status of MediaWiki.r98915. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98915 Commit summary: Removed GatewayForm::fnValidateForm(). GatewayForm::validateForm() is now the preferred method to validate forms. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98476]: Revision status changed
User Awjrichards changed the status of MediaWiki.r98476. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98476 Commit summary: Added GatewayForm::validateForm() so certain elements can be validated. The old method GatewayForm::fnValidateForm() always validates credit cards. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r97579]: Revision status changed
User Jpostlethwaite changed the status of MediaWiki.r97579. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/97579 Commit summary: Wraps up the basic requirements for fundraiser cards #280 and #300. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99257]: Revision status changed
User Awjrichards changed the status of MediaWiki.r99257. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99257 Commit summary: reverted accidently commited test code from r99256 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98293]: Revision status changed
User Jpostlethwaite changed the status of MediaWiki.r98293. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98293 Commit summary: output the skin override style ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r99256]: Revision status changed
User Awjrichards changed the status of MediaWiki.r99256. Old Status: new New Status: resolved Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99256 Commit summary: fixing scope issues for more resourceloaderified js ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98291]: Revision status changed
User Jpostlethwaite changed the status of MediaWiki.r98291. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98291 Commit summary: oops, follow-up to r98290, style not script ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98290]: Revision status changed
User Jpostlethwaite changed the status of MediaWiki.r98290. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98290 Commit summary: skinoverride to hide interface elements ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98581]: New comment added, and revision status changed
User Jpostlethwaite changed the status of MediaWiki.r98581. Old Status: new New Status: ok User Jpostlethwaite also posted a comment on MediaWiki.r98581. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98581#c23950 Commit summary: Various bug squashings after my last big commit. Also moved all the runHooks commands to inside the gateway adapter object. Still testing all the hook types. r98498 Comment: Many of these changes appear to code clean up. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98826]: Revision status changed
User Jpostlethwaite changed the status of MediaWiki.r98826. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98826 Commit summary: More bug squashing surrounding the extras in DonationInterface. r98498 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98830]: Revision status changed
User Jpostlethwaite changed the status of MediaWiki.r98830. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98830 Commit summary: Correcting the pfp gateway identifier in Donation Interface. r98498 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r98833]: Revision status changed
User Jpostlethwaite changed the status of MediaWiki.r98833. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98833 Commit summary: Found a bug that truncated some values during key-value array translation of a response from a namevalue-type gateway, if any of the values contain the character '='. This does actually come back from payflowpro: They send XML back as a value in the FPS_PREXMLDATA key if the transaction was flagged by their fraud protection. (Awesome) r98498 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
