[MediaWiki-CodeReview] [MediaWiki r85296]: New comment added
User Nikerabbit posted a comment on MediaWiki.r85296. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85296#c15686 Comment: You sure didn't give a lot of time to fix this... ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85296]: New comment added
User Siebrand posted a comment on MediaWiki.r85296. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85296#c15687 Comment: Isn't it good practice to support this without warnings for at least one release (1.18), have it whine the next release (1.19), and remove it in the 3rd (1.20)? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r79108]: New comment added
User Tim Starling posted a comment on MediaWiki.r79108. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/79108#c15688 Comment: I get pre Running test Interlanguage link, with prefix links... A database error has occurred. Did you forget to run maintenance/update.php after upgrading? See: http://www.mediawiki.org/wiki/Manual:Upgrading#Run_the_update_script Query: SELECT value,exptime FROM `parsertest_objectcache` WHERE keyname = 'testwiki-parsertest_:message-profiling' LIMIT 1 Function: SqlBagOStuff::get Error: 1146 Table 'testwiki.parsertest_objectcache' doesn't exist (127.0.0.1:3306) /pre unless this is patched out. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] Actions and Special Pages
In the beginning, there was Article.php. And the Article class had methods like Article::view(), Article::delete(), Article::protect(), etc. And the fundamental codeflow of Mediawiki consisted of something along the lines of: $article = new Article( $title ); $action = wfGetTheActionSomehow(); $article-$action(); Over time Article has grown and bloated to become our third largest class (after ZhConversion and Parser). Several of its action methods have been spun out to separate files (EditPage.php, ProtectionForm.php and HistoryPage.php, among others). It's long overdue that this process be carried through to its natural conclusion with all action methods spun out into some new structure. There are essentially two competing possibilities for structuring this, and they reflect the two parallel systems we have for doing things other than viewing to a wiki. One is action parameters, and the other is special pages. We have action=edit, or Special:MovePage, for instance; they have a similar function but different structure. We have action=delete to get rid of stuff, but then Special:Undelete to bring it back again. Special:Whatlinkshere and action=history are another pair of pages which have very similar principles (getting data that relates to a given page) but different implementations. For either case in the backend I would think we'd want to create an ActionPage base class and an EditActionPage from that, which looks internally rather like a SpecialPage construct, might even subclass it. I'd like to ask people's opinions about which they think would work better in the frontend for, say, editing or protecting. If people think it would be better as a special page we'd make http://foo.example.com/w/index.php?title=Baraction=edit a hard redirect to Special:Edit/Bar; that has the significant advantage of being able to be formed as an internal link. Conversely if we'd like to keep it an action it would make sense to redirect Special:MovePage/Bar back to ?title=Baraction=move. Or is something more exotic like [[Action:Edit/Bar]] a possibility? Thoughts? --HM ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Actions and Special Pages
On 04/04/2011 11:28 PM, Happy-melon wrote: For either case in the backend I would think we'd want to create an ActionPage base class and an EditActionPage from that, which looks internally rather like a SpecialPage construct, might even subclass it. We had this discussion in January. That's basically what I suggested, but there are some complications. http://lists.wikimedia.org/pipermail/wikitech-l/2011-January/051041.html -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Actions and Special Pages
On Mon, Apr 4, 2011 at 9:28 AM, Happy-melon happy-me...@live.com wrote: If people think it would be better as a special page we'd make http://foo.example.com/w/index.php?title=Baraction=edit a hard redirect to Special:Edit/Bar; that has the significant advantage of being able to be formed as an internal link. I've always thought this was the best way to do things. Be careful about overusing short URLs, though -- the only reason robots don't spider /w/index.php?title=Fooaction=edit right now is because it starts with /w/ instead of /wiki/. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85327]: New comment added, and revision status changed
User Raymond changed the status of MediaWiki.r85327. Old Status: new New Status: fixme User Raymond also posted a comment on MediaWiki.r85327. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85327#c15689 Comment: Seen on Translatewiki and on my local wiki: Warning: require_once(D:\F_Programmierung\xampp\htdocs\wiki2/includes/Init.php) [function.require-once]: failed to open stream: No such file or directory in D:\F_Programmierung\xampp\htdocs\wiki2\includes\WebStart.php on line 90 Fatal error: require_once() [function.require]: Failed opening required 'D:\F_Programmierung\xampp\htdocs\wiki2/includes/Init.php' (include_path='.;D:\F_Programmierung\xampp\php\PEAR') in D:\F_Programmierung\xampp\htdocs\wiki2\includes\WebStart.php on line 90 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Focus on sister projects
On 2 Apr 2011 at 16:08, Ryan Kaldari wrote: What do you guys think would be more useful: 1. Helping sister projects write up proposals for the Berlin Hackathon If it is going to get selected and have outcome for my favourite wiki, then yes ;-) 2. Creating The Complete Idiot's Guide to Writing MediaWiki Extensions and The Complete Idiot's Guide to Writing MediaWiki Gadgets (in jQuery) To me this has great great value, and I hope that when you say complete you mean COMPLETE!!! and I would hope that you would encourage and give examples of good documentation. Some of us are not natural programmers, though we can adapt scripts to suit our needs, and when given I find the explanations very useful. Regards, Andrew Whichever one you guys prefer, I'll pitch to my Engineering Project Managers as a project for myself. Ryan Kaldari On 4/2/11 12:29 PM, bawolff wrote: Message: 2 Date: Fri, 01 Apr 2011 18:40:00 -0700 From: Ryan Kaldarirkald...@wikimedia.org Subject: Re: [Wikitech-l] Focus on sister projects To: Conrad Irwinconrad.ir...@gmail.com Cc: Wikimedia developerswikitech-l@lists.wikimedia.org Message-ID:4d967e70.2080...@wikimedia.org Content-Type: text/plain; charset=windows-1252; format=flowed [...] As long as we're on the subject of wiktionary, I notice that there's a lot of custom Javascript there for handling specialized editing tasks like editing glosses, managing translations, etc. It seems like some of this functionality could be improved further and developed into full-fledged extensions (making it easy for other wiktionaries to use as well). Would you have any interest in working up a couple Wiktionary project proposals for the upcoming Hackathon in Berlin? Ryan Kaldari This isn't just true of wiktionary. Lots of sister projects have specialized work flow tools in js. Wikinews has review related tools in js and a hack that adds a second talk namespace, Wikisource has the proofread page extension, but still much of there workflow is written in js, I'm sure many other projects have specialized stuff that should be in php extensions. The issue is at the end of the day it is _significantly_ easier to write a js hack, then to manage to get a php extension written, reviewed and deployed. -bawolff ___ 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] Future: Love for the sister projects!
On 3 Apr 2011 at 10:56, Brion Vibber wrote: (Breaking this out from 'Focus on sister projects' thread.) I just want to give an official shout out, as Lead Software Architect for the Wikimedia Foundation, that Wikipedia's sister projects are important and that they need more love. Not only are they directly useful and interesting in various ways, but their explorations of additional subject areas, media, and organization styles is something that needs more attention as Wikimedia looks to its future beyond Wikipedia's first decade. The next decade can't just be ten years of doing the same things... Historically it's been difficult to get enough attention for review deployment of special-purpose extensions for those projects, so I'm highly interested in proposals that will help put more flexibility and power into the hands of their own motivated contributors: from easier self-configuration of sites to new plugin architectures that allow the use of new creative media tools without the explicit intervention of Wikimedia staff. In particular, I think there's some low-hanging fruit in the Gadgets system. Right now it's honestly pretty awkward to create a Gadget in the first place, and sharing code modules between wikis requires a lot of cut-and-pasting (which leads to divergent code bases, which makes maintenance nigh-impossible in the face of MediaWiki framework changes). Some things that would be very spiffy, and probably not that hard: * Provide a nice interface rather than forcing manual editing of MediaWiki: namespace message pages * Self-publishing: be able to do your user JS/CSS in modular Gadget-form, with easy sharing to other users. Don't require manual work to move something from 'my own custom JS' ro 'a user .js file that other people can use' to 'a Gadget that anyone can select in preferences'. * Cross-wiki gadget sharing: if we can avoid fragmenting common scripts, they'll be easier to maintain. Harder, but very interesting in the medium to long-term: * Security model for safe code sharing: we could devise an explicitly limited interface between the wiki page JS and gadgets hosted in an offsite iframe. A foreign gadget could add certain UI elements (tabs, toolbar buttons) to be triggered, and could open as an embedded view to provide things like image editing, drag-n-drop category rearrangement, custom visualizations or interactive diagrams. Some commentary. For WS projects, ThomasV has been utilising this model for his proofread page schema. Most of his javascript is placed in http://wikisource.org/wiki/Mediawiki... and the local stuff would be local customisations for language, eg. field names I would hope that as a model that this can be used, so that the guts of a script can be separated from the labelling. With regard to calling gadgets from elsewhere, often the issue is 1) which server, there is so much variability, and many started at WP. 2) knowing what available on servers, and this is a documentation issue. Trying to find available scripts on TS is just as problematic. Regards, Andrew ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85302]: New comment added, and revision status changed
User Happy-melon changed the status of MediaWiki.r85302. Old Status: fixme New Status: new User Happy-melon also posted a comment on MediaWiki.r85302. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85302#c15691 Comment: Heaven knows tt:D/tt Should be fixed in r85332 though. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85211]: New comment added, and revision status changed
User ^demon changed the status of MediaWiki.r85211. Old Status: fixme New Status: new User ^demon also posted a comment on MediaWiki.r85211. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85211#c15692 Comment: Merged the first 3. The last two look merged to me, The regexes in both trunk and REL1_17 are tt$attribFirst = '[:A-Z_a-z0-9]';/tt. I didn't merge anything to tests/phpunit since that was dropped in REL1_17. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Focus on sister projects
Maybe my brain just made a leap here, but is there a plan for implementing a web-based Javascript editor for MediaWiki?? This would be a hugely awesome feature. I've used jsFiddle (http://jsfiddle.net/) which is really slick - syntax color-coding, tabbing that works, a Tidy button(!), integrated jsLint(!). If not, hopefully, I've just created a self-fulfilling rumor :) Ryan Kaldari On 4/3/11 11:06 AM, Daniel Kinzler wrote: I think the JS editor stuff would also fit well enough with the topics of the Berlin hackathon in May... -- daniel On 03.04.2011 15:30, Sumana Harihareswara wrote: Would any of those be useful project ideas for Google Summer of Code students? If so, please add a bullet point or two: http://www.mediawiki.org/wiki/Summer_of_Code_2011 best, Sumana Harihareswara On 04/01/2011 10:11 PM, Conrad Irwin wrote: Ok — yes loading speeds are definitely something worth improving. WT:PREFS to become gadgets has been discussed ever since gadgets was released, it will happen one day :). Luckily that code is only loaded for people who are using WT:PREFS, so it should have minimal impact. I'd be pretty interested to — do you have a guideline as to the expected format. In particular I think the core of the editor, which provides a framework for javascript to load, edit, undo, redo, and save the page (with edit summaries) would be pretty useful everywhere. It's documented in the first half of http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_docs and there's a tutorial at http://en.wiktionary.org/wiki/User:Conrad.Irwin/editor_tutorial.js — but it could do with new-ification (in particular some jQuery would be nice, and there's probably a better javascript API wrapper than JsMwApi :). Conrad On Fri, Apr 1, 2011 at 6:40 PM, Ryan Kaldarirkald...@wikimedia.org wrote: Good idea. After the 1.17 deployment, I've been trying to go through and clean-up some of the Javascript cruft that has built up on the various wikis over the years. One of the main goals of 1.17 was improving page loading speeds by optimizing Javascript delivery. Of course if all the wikis are serving lots of old redundant Javascript, the optimization doesn't accomplish that much. On wiktionary specifically, the importScript and importExternalScript functions are redundant, and the Wiktionary:PREFS system should be retired now that Gadgets are available. I admit I was much too gung-ho in my clean-up regarding Wiktionary, and I intend to let the admins there handle it from here. As long as we're on the subject of wiktionary, I notice that there's a lot of custom Javascript there for handling specialized editing tasks like editing glosses, managing translations, etc. It seems like some of this functionality could be improved further and developed into full-fledged extensions (making it easy for other wiktionaries to use as well). Would you have any interest in working up a couple Wiktionary project proposals for the upcoming Hackathon in Berlin? Ryan Kaldari ___ 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 mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85080]: New comment added
User ^demon posted a comment on MediaWiki.r85080. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85080#c15693 Comment: Grabbed the ones mentioned in this rev, see r85343 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r83080]: New comment added
User Tbleher posted a comment on MediaWiki.r83080. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/83080#c15695 Comment: This change breaks the CommentBox extension, which has a special page to add comments to pages. The special page creates a FauxRequest which it submits to the API (see http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/Commentbox/SpecialAddComment_body.php?revision=84686view=markup , line 79). The FauxRequest needs a token parameter, but to create a token, one now needs an already constructed request. The code now fails with an invalid token error when logged in; it works fine when not logged in. When reverting this and the two followup revisions, the extension works fine. How should such a request be constructed using the new method? (The easiest way would probably be to change the token parameter in FauxRequest later; currently, there is now way to do this using the FauxRequest API however, and I don't have core commit access to do it myself) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85151]: New comment added, and revision status changed
User ^demon changed the status of MediaWiki.r85151. Old Status: fixme New Status: new User ^demon also posted a comment on MediaWiki.r85151. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85151#c15696 Comment: Yay for followups :D ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] writing phpunit tests for extensions
I had a bit of a documentation challenge approaching the problem of writing phpunit test for extensions, mostly because many of the extensions do this very differently and the manual did not have any recommendations. It appears many extension have custom bootstraping code ( somewhat hacky path discovery and manual loading of core mediawiki files, and don't necessarily register their tests in a consistent way.) I wrote up a short paragraph of what I would recommend here: http://www.mediawiki.org/wiki/Manual:Unit_testing#Writing_Unit_Test_for_Extensions If that makes sense, I will try and open up some bugs on the extensions with custom bootstraping code, and I would recommend we commit an example test tests/phpunit/suite.extension.xml file for exclusively running extension tests. Eventually it would be ideal to be able to 'just test your extension' from the core bootstraper (ie dynamically generate our suite.xml and namespace the registration of extension tests) ... but for now at least not having to wait for all the core tests as you write you extension tests and some basic documentation on how to do seems like a step forward. --michael ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HipHop
Hi Tim,
I have no problem running foo.php and test.php that you sent in hphpi, but
also it compiles and run without any problems with hphp. What command
exactly do you use to compile and then execute?
Inez
On Sun, Apr 3, 2011 at 5:38 PM, Tim Starling tstarl...@wikimedia.orgwrote:
On 03/29/2011 10:48 AM, Platonides wrote:
I was expecting this the week hip-hop hit. What would be required to
target hip-hop? How does that differ from working from Zend?
I've explored the issues and made some initial changes to my working
copy. I'm now waiting for it to compile, and once it's tested, I'll
commit it.
There is a list of things that differ here:
https://github.com/facebook/hiphop-php/blob/master/doc/inconsistencies
Unfortunately it seems to leave out the most important differences.
It seems incredible, and I'm hoping someone will correct me, but it
seems that file inclusion has to be completely different in HipHop.
Even the simplest script won't work. I put this in foo.php:
?php
class Foo {
static function bar() {
print Hello\n;
}
}
?
And this in test.php:
?php
include 'foo.php';
Foo::bar();
?
This gives HipHop Fatal error: Cannot redeclare class Foo at
runtime. All classes which are compiled exist from startup, and trying
to declare them produces this error. This means that it is no longer
possible to mix class and function declarations with code we want to
execute. My working copy has fixes for the most important instances of
this, such as in Setup.php and WebStart.php.
There are two exceptions to this. One is the interpreter. HipHop has
an interpreter, which is used for eval() and for include() on a file
with a fully-qualified path. We can use this to allow us to change
LocalSettings.php without recompiling.
If you want to do include() and have it execute compiled code, you
need to use a path which is relative to the base of the compiled code.
My working copy has some functions which allow this to be done in a
self-documenting way.
The other exception is volatile mode, which unfortunately appears to
be completely broken, at least in the RPMs that I'm using. It's so
broken that calling class_exists() on a literal string will break the
class at compile time, making it impossible to use, with no way to
repair it. My working copy has a wrapper for class_exists() which
doesn't suffer from this problem.
Another undocumented difference is that HipHop does not use php.ini or
anything like it, so most instances of ini_get() and ini_set() are
broken. The functions exist, but only have stub functionality. HipHop
has its own configuration files, but they aren't like php.ini.
When I'm ready to write all this up properly, the following page will
appear on mediawiki.org:
http://www.mediawiki.org/wiki/HipHop
-- Tim Starling
___
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 r85358]: Revision status changed
User ^demon changed the status of MediaWiki.r85358. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85358#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84929]: Revision status changed
User Catrope changed the status of MediaWiki.r84929. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/84929#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84627]: Revision status changed
User Catrope changed the status of MediaWiki.r84627. Old Status: new New Status: resolved Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/84627#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85144]: Revision status changed
User Catrope changed the status of MediaWiki.r85144. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85144#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r84637]: Revision status changed
User Catrope changed the status of MediaWiki.r84637. Old Status: new New Status: resolved Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/84637#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85276]: Revision status changed
User Catrope changed the status of MediaWiki.r85276. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85276#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85328]: Revision status changed
User Catrope changed the status of MediaWiki.r85328. Old Status: new New Status: deferred Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85328#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85048]: Revision status changed
User Catrope changed the status of MediaWiki.r85048. Old Status: new New Status: ok Full URL: https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:Code/MediaWiki/85048#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85361]: New comment added
User Nikerabbit posted a comment on MediaWiki.r85361. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85361#c15699 Comment: Did you add or remove BOM in trunk/extensions/TimedMediaHandler/TimedMediaHandler.hooks.php? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85361]: New comment added
User Mdale posted a comment on MediaWiki.r85361. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85361#c15700 Comment: not intentionally... What is BOM? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85361]: New comment added
User Nikerabbit posted a comment on MediaWiki.r85361. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85361#c15701 Comment: [[wikipedia:Byte order mark]] - and PHP doesn't like it. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85302]: New comment added, and revision status changed
User Platonides changed the status of MediaWiki.r85302. Old Status: new New Status: fixme User Platonides also posted a comment on MediaWiki.r85302. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85302#c15702 Comment: parserTests.php creates a new OutputPage. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85317]: Revision status changed
User Platonides changed the status of MediaWiki.r85317. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85317#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85373]: New comment added
User ^demon posted a comment on MediaWiki.r85373. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85373#c15703 Comment: Did you check it first? If so, you should bump the version in the README. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85376]: Revision status changed
User Reedy changed the status of MediaWiki.r85376. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85376#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r39635]: New comment added, and revision status changed
User Reedy changed the status of MediaWiki.r39635. Old Status: ok New Status: fixme User Reedy also posted a comment on MediaWiki.r39635. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/39635#c15704 Comment: Line 251 now in trunk has an undefined $name usage ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] writing phpunit tests for extensions
Michael Dale wrote: Eventually it would be ideal to be able to 'just test your extension' from the core bootstraper (ie dynamically generate our suite.xml and namespace the registration of extension tests) ... but for now at least not having to wait for all the core tests as you write you extension tests and some basic documentation on how to do seems like a step forward. --michael If your tests are in just one file, you can simply pass it as a parameter to tests/phpunit/phpunit.php ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85177]: New comment added
User Brion VIBBER posted a comment on MediaWiki.r85177. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85177#c15707 Comment: Passing a string doesn't work either -- the timezone parameter needs to be a DateTimeZone object. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] writing phpunit tests for extensions
On 04/04/2011 02:20 PM, Platonides wrote: Michael Dale wrote: Eventually it would be ideal to be able to 'just test your extension' from the core bootstraper (ie dynamically generate our suite.xml and namespace the registration of extension tests) ... but for now at least not having to wait for all the core tests as you write you extension tests and some basic documentation on how to do seems like a step forward. --michael If your tests are in just one file, you can simply pass it as a parameter to tests/phpunit/phpunit.php that's cool. We should add that info to the phpunit.php --help output, and to the unit testing wiki page. --michael ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Future: Love for the sister projects!
I think the source of the problems is the decentralizated process that wikimedia javascript have followed. Medium-size wikis will have 2-3 tech people. Small wikis will be lucky to have 1 js-savy sysop. Even wikis with no local expert may have just forked the Monobook.js from its mother project and never touch it again. There are also one-man javascript cathedrals that noone dares to touch now but have lots of users which will complaint if they stop working. I'm sure there are lots of versions of collapsible tables out there (and some old pages are not viewable with the newer ones...). There are diverging branches for each change. One user changes innerHTML to DOM while another added new features. Then a third one fixes an injection on its own copy, while the original version at enwiki is left unpatched. Even their goals are different. There's no way to coordinate all these efforts. There's no central mailing list where it can be shouted Hey! This javascript is now deprecated or This gadget is now much improved. Also, the place to put the javascript code (a superset of the link-or-copy disyuntive) is made non-trivial by the distribution of sysop rights. Some steps to take: * Finally create global gadgets. * Create a central wiki for javascript sharing [1] * Gather a list of tech users[2] and invite them to the new wiki and/or a mailing list. * ??? * Profit [1] A protected Script: namespace at meta would also work, with a new permission. Note that we would need to give to all these people access to edit some global javascript. [2] Make a list of users with more than 3 edits to Mediawiki:*.js on any project. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85385]: New comment added, and revision status changed
User Reedy changed the status of MediaWiki.r85385. Old Status: new New Status: fixme User Reedy also posted a comment on MediaWiki.r85385. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85385#c15709 Comment: empty? :P Also, should have more spaces on your if statement ;) ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85385]: New comment added
User Brion VIBBER posted a comment on MediaWiki.r85385. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85385#c15710 Comment: Oh poop, I still haven't retrained my muscle memory for our space style. ;) The empty() should be fine for arrays, but if it makes you feel better change it to check the count() or something. I'll re-add it to my internal blacklist :D ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Future: Love for the sister projects!
Very interesting! :-) I'm a beginner in js stuff, but I realized how much js can be useful in a number of ways (presently I am a very simple gadgets maker t help users engaged into proofreading into wikisource). I'm a little worried about additional server load coming from AJAX, and I suggest different policies between local js scripts (that, fix me if I'm wrong, don't imply any server load) and AJAX scripts, which raise performance issues. So, I can't wait for a js wiki but please, keep it simple! So simple that a beginner too could browse it,learn from it and publish anything without any embarrassment. Beginners often feel themselves really stupid and some good idea could be lost. Alex brollo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85385]: Revision status changed
User Reedy changed the status of MediaWiki.r85385. Old Status: fixme New Status: new Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85385#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r79108]: New comment added
User Tim Starling posted a comment on MediaWiki.r79108. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/79108#c15711 Comment: I'm not sure. It's stopped happening now. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85402]: New comment added
User Happy-melon posted a comment on MediaWiki.r85402. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85402#c15712 Comment: This is half of r79542. Is it worth merging the rest of that rev? ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85403]: New comment added
User Dantman posted a comment on MediaWiki.r85403. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85403#c15715 Comment: You can also drop code$wgUser-getSkin( $wgTitle ); // set skin title/code it's not needed. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Future: Love for the sister projects!
On Mon, Apr 4, 2011 at 6:22 PM, Platonides platoni...@gmail.com wrote: Some steps to take: * Finally create global gadgets. * Create a central wiki for javascript sharing [1] It seems like this always comes up for a number of different things -- global pages for interwiki transclusion and interlanguage extension, just to name two recent ones -- maybe it's about time we actually make this? :-) I guess a list of things we'd put on this wiki would be a good first step. * Gather a list of tech users[2] and invite them to the new wiki and/or a mailing list. https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors ? -- Casey Brown Cbrown1023 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85302]: New comment added, and revision status changed
User Happy-melon changed the status of MediaWiki.r85302. Old Status: fixme New Status: new User Happy-melon also posted a comment on MediaWiki.r85302. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85302#c15714 Comment: Fixed in r85403 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85402]: New comment added
User Reedy posted a comment on MediaWiki.r85402. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85402#c15713 Comment: Making it private and the whitespace? Probably not ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Some changes to $wgOut, $wgUser, Skin, and SpecialPage code patterns
On 11-04-04 02:40 PM, Platonides wrote: I like it. Specially the Linker change. It really looks the way to have it. I'm considering making the Parser get it's linker via $po-getLinker(); (either ParserOutput or ParserOptions, I need another look) The linker would be an input parameter, so it is a ParserOptions Yeah, I just couldn't remember which set of code that was when I wrote the e-mail... It's moot now anyways, since Linker is now used statically as Linker::* instead. ~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] Some changes to $wgOut, $wgUser, Skin, and SpecialPage code patterns
I second the idea of the static Linker class. It's far better than the subclass system. Skin modification of links should focus on CSS anyway, rather than trying to overload link generating code. Daniel Friesen-4 wrote: On 11-04-04 02:40 PM, Platonides wrote: I like it. Specially the Linker change. It really looks the way to have it. I'm considering making the Parser get it's linker via $po-getLinker(); (either ParserOutput or ParserOptions, I need another look) The linker would be an input parameter, so it is a ParserOptions Yeah, I just couldn't remember which set of code that was when I wrote the e-mail... It's moot now anyways, since Linker is now used statically as Linker::* instead. ~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 -- View this message in context: http://old.nabble.com/Some-changes-to-%24wgOut%2C-%24wgUser%2C-Skin%2C-and-SpecialPage-code-patterns-tp31305991p31320028.html Sent from the Wikipedia Developers mailing list archive at Nabble.com. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Linker, more on Skins, OutputPage, and context code patterns changes
Continuing with my changes to $wgOut, $wgUser, Skin, and SpecialPage patterns. The Linker is now static, $sk-link will still work, however you should not be requiring a Skin anymore to use linker methods. Please use Linker::link directly. The only exception is the method to create an editsection link, that method IS part of Skin itself now. Also there is some compat for hooks that were passed the linker as an instance, and `$parserOptions-getSkin();` However note that ParserOptions::getSkin no longer returns an actual Skin, it now returns a plain linker instance and makes a depreciated call. ((for reference the 'instance' of Linker which is static is actually a DummyLinker class which has a __call that forwards old method calls to static calls to the linker)) So nearly EVERY case you are currently grabbing a Skin for, you should no longer be fetching a skin. Now, if you really do need a skin, the the new way to get a skin is `$context-getSkin()`, OutputPage has a helper `$out-getSkin()` if you happen to be working on OutputPage related stuff and need to interact with the skin. `$wgUser-getSkin();` has some BackCompat to keep working, however please avoid using it, it uses the main RequestContext, not whatever the RequestContext for whatever context you are in is. Also, there is no equivalent to `$wgUser-getSkin( $title );`. Skin no longer has a mTitle of it's own, it gets the title used in the attached RequestContext, which is the same one that OutputPage uses, and is essentially the replacement to $wgTitle. So you don't need to work around bugs like that in Skin, nor in OutputPage anymore. Additionally that format was never actually used right, nearly every call to that was actually made in contexts where one was using the Linker methods (which don't use mTitle) and was not interacting with the skin. I started a page on the RequestContext object: http://www.mediawiki.org/wiki/Request_Context some extra I'm still contemplating skin setting and relation to context right now. I would like to make it possible to do something like `$context-setSkin( new DummyOfflineSkin );` but also want to avoid bugs where you try to set the same skin onto two contexts and get an error. I examined the code paths, and Skin doesn't actually make any RequestContext dependent calls except inside calls made from the Skin::outputPage( $out ); entrypoint which is called by OutputPage::output();, in other words theoretically I could avoid tying a Skin instance to any specific context by setting the context at the start of Skin::outputPage( $out ) ($out provides the RequestContext), and exiting that context when it's done. However there is one instance where this rule is broken, ApiParse which makes a direct call outside of that context when you use categoryhtml or languagehtml (which I wanted to stop from being released from the start). -- ~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 r84782]: New comment added
User Tim Starling posted a comment on MediaWiki.r84782. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84782#c15716 Comment: pre total processing time: 188 days 4520h 57m 51.00s gained time: 2 days 62h 32m 52.859375s /pre Too many hours! ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] Some changes to $wgOut, $wgUser, Skin, and SpecialPage code patterns
Brion Vibber wrote: I'd be kind of inclined to separate out the Skin and Linker worlds a bit further; really, the HTML formatting of links and such doesn't depend on the user (except in some edge cases like stub links which could in principle be done differently). The surrounding *skin* depends on the user settings, but having to dive into a User object to get a Linker feels messy, especially if we're rendering a wiki page to go into a common cache. IIRC the biggest remaining use case for link rendering actually being customized by skin was for the special skin used for creating static HTML dumps. If we had another way to do that, and normalized stub linking in some way (say, by always sticking a magic class on and letting CSS deal with it) it might be cleaner to avoid having to touch a Skin object unless you're actually doing final HTML output. (This may be a bigger project though. :D) I filed two bugs after reading this: * Avoid parser cache fragmentation[1] * Remove stub link formatting user preference from MediaWiki core[2] MZMcBride [1] https://bugzilla.wikimedia.org/show_bug.cgi?id=28424 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=28426 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Future: Love for the sister projects!
On Mon, Apr 4, 2011 at 9:05 PM, K. Peachey p858sn...@gmail.com wrote: I don't see why we need to spilt it off to another list No reason not to do it here on wikitech-l. Did you realize that that list already exists? There's also no reason not to use both of them, with the ambassadors list one being more of an announce list. People could send messages to both lists, and then most discussion would take place on wikitech-l. -- Casey Brown Cbrown1023 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Actions and Special Pages
Aryeh Gregor wrote: On Mon, Apr 4, 2011 at 9:28 AM, Happy-melon happy-me...@live.com wrote: If people think it would be better as a special page we'd make http://foo.example.com/w/index.php?title=Baraction=edit a hard redirect to Special:Edit/Bar; that has the significant advantage of being able to be formed as an internal link. I've always thought this was the best way to do things. Be careful about overusing short URLs, though -- the only reason robots don't spider /w/index.php?title=Fooaction=edit right now is because it starts with /w/ instead of /wiki/. I can't think of a reason that any of the Special namespace needs to be indexed. Most of it is already marked noindex in the meta tags, as far as I remember. Additional explicit exclusion in a robots.txt file is always a good idea, though. Some auto-generation of a robots.txt file might be nice (WordPress does this). It's easy enough to exclude based on the prefix Special:, but it's the localizations that ruin everything. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Actions and Special Pages
On 11-04-04 08:12 PM, MZMcBride wrote: Aryeh Gregor wrote: On Mon, Apr 4, 2011 at 9:28 AM, Happy-melonhappy-me...@live.com wrote: If people think it would be better as a special page we'd make http://foo.example.com/w/index.php?title=Baraction=edit a hard redirect to Special:Edit/Bar; that has the significant advantage of being able to be formed as an internal link. I've always thought this was the best way to do things. Be careful about overusing short URLs, though -- the only reason robots don't spider /w/index.php?title=Fooaction=edit right now is because it starts with /w/ instead of /wiki/. I can't think of a reason that any of the Special namespace needs to be indexed. Most of it is already marked noindex in the meta tags, as far as I remember. Additional explicit exclusion in a robots.txt file is always a good idea, though. Some auto-generation of a robots.txt file might be nice (WordPress does this). It's easy enough to exclude based on the prefix Special:, but it's the localizations that ruin everything. MZMcBride I don't really think that's a good reason to preclude being able to create special page based content. Eg: A forum extension that uses special pages. Our own Special:Code, etc... if we chose to allow those to be indexed. Side note, why don't we allow indexing of Allpages? That sounds like a sane way for Google to find all the pages on a small growing wiki that hasn't setup the best linking yet or generated an xml sitemap. What IS so evil about actions? Besides the implementation details which are just that... something we can make better. In fact something we could potentially make work better than SpecialPages would in this context. Personally, I like tacking on ?action=edit and especially purge. Prefixing Special:Edit/ doesn't sound nice to me. I know I fixed the issues with things like Special:Movepage not sharing the same UI tabs as the rest of the actions. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HipHop
On 03/30/2011 09:22 AM, Magnus Manske wrote: Plus, free C++ MediaWiki parser ;-) Seriously, there should be a way to turn the entire package into a (huge) library; maybe transpile it and then replace the C++ code for index.php with a manually written library interface? HipHop has a library generation feature. It even has an option to provide public interfaces with human-readable names. Offline readers, scientific analysis tools, etc. could profit massively from an always-current, fast C++ library... Speaking of fast, I did a quick benchmark of the [[Barack Obama]] article with templates pre-expanded. It took 22 seconds in HipHop and 112 seconds in Zend, which is not bad, for a first attempt. I reckon it would do better if a few of the regular expressions were replaced with tight loops. Also, browsing the generated source turns up silly things like: if (equal(switch2, (NAMSTR(s_ss34c5c84c, currentmonth goto case_2_0; if (equal(switch2, (NAMSTR(s_ss55b88086, currentmonth1 goto case_2_1; if (equal(switch2, (NAMSTR(s_ss0ccbf467, currentmonthname goto case_2_2; if (equal(switch2, (NAMSTR(s_ss513d5737, currentmonthnamegen goto case_2_3; if (equal(switch2, (NAMSTR(s_ss004d8db5, currentmonthabbrev goto case_2_4; if (equal(switch2, (NAMSTR(s_ssf9584d41, currentday goto case_2_5; 71 string comparisons in total, in quite a hot function. A hashtable would probably be better. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Actions and Special Pages
Daniel Friesen wrote:
What IS so evil about actions? Besides the implementation details
which are just that... something we can make better. In fact something
we could potentially make work better than SpecialPages would in this
context.
Personally, I like tacking on ?action=edit and especially purge.
Prefixing Special:Edit/ doesn't sound nice to me.
I know I fixed the issues with things like Special:Movepage not sharing
the same UI tabs as the rest of the actions.
I tack on purge/edit parameters fairly often as well. The biggest issue with
parameters versus Special pages is that one is easily internally linkable
currently (minus the pl_title restriction) and the other is not. There are
_countless_ uses of span class=plainlinks[{{fullurl:foo|action=edit}}
bar]/span right now which is unacceptably ugly. There needs to be a
cleaner syntax, particularly for edit links, but for most other actions as
well. Personally, I don't really care what syntax is chosen, it just needs
to be consistent.
MZMcBride
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] GSOC and networking
Hello, I was encouraged (hello, Sumana) to post a Google Summer of Code idea and solicit comments. So here goes. Perhaps entirely outside of the scope of GSOC, I think it would be a fun project to make wikipedia.org and wikimedia.org accessible over IPv6. Also, while creating an account to post to http://www.mediawiki.org/wiki/Summer_of_Code_2011 I noticed that my login was insecure, and that there was no SSL option. Adding a secure login feature would also be a cool project. Cheers, mc ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSOC and networking
On Tue, Apr 5, 2011 at 1:07 PM, Michael Costello mc3...@columbia.edu wrote: Perhaps entirely outside of the scope of GSOC, I think it would be a fun project to make wikipedia.org and wikimedia.org accessible over IPv6. I noticed that my login was insecure, and that there was no SSL option. Adding a secure login feature would also be a cool project. You can connect via the secure server[1] but that seems to be down atm(?), also I thought we did have IPV6 setup for the sites. [1]. https://secure.wikimedia.org/wikipedia/mediawiki/wiki/Special:UserLogin ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r85417]: New comment added
User Kaldari posted a comment on MediaWiki.r85417. Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85417#c15717 Comment: This is a less clunky fix for bug 27424. The other rev (r85415) was overkill. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r85387]: Revision status changed
User MaxSem changed the status of MediaWiki.r85387. Old Status: new New Status: ok Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/85387#c0 ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] HipHop: need developers
I need to get back to work on reviews and deployments and other such strategic things. I hope the work I've done on HipHop support is enough to get the project started. Initial benchmarks are showing a 5x speedup for article parsing, which is better than we had hoped for. So there are big gains to be had here, both for small users and for large websites like Wikimedia and Wikia. There's a list of things that still need doing under the to do heading at: http://www.mediawiki.org/wiki/HipHop I'll be available to support any developers who want to work on this. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
