Re: [Wikitech-l] Bugzilla keywords for deployment queues?
On 04/11/10 00:35, K. Peachey wrote: They are under a plain text RCS now which is documented on wikitech. If you are talking about [[RCS]], it is 6 years old, written by myself. http://wikitech.wikimedia.org/history/RCS Always read the Wikitech pages with a critical view! -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] mod_pagespeed?
Though Wikimedia servers are quite efficient already, it might be worth checking this out: http://code.google.com/intl/de/speed/page-speed/docs/module.html Cheers, Magnus ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] mod_pagespeed?
2010/11/4 Magnus Manske magnusman...@googlemail.com: Though Wikimedia servers are quite efficient already, it might be worth checking this out: http://code.google.com/intl/de/speed/page-speed/docs/module.html You can have an automated program attempt to use the best practices mentioned there to optimize your site, or you can have humans implement those optimizations in MediaWiki. The latter is exactly what ResourceLoader is doing. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] mod_pagespeed?
On Thu, Nov 4, 2010 at 5:56 AM, Magnus Manske magnusman...@googlemail.com wrote: Though Wikimedia servers are quite efficient already, it might be worth checking this out: http://code.google.com/intl/de/speed/page-speed/docs/module.html From their site: mod_pagespeed includes several filter that optimize JavaScript, HTML and CSS stylesheets.. This is already being handled by the in-trunk-but-not-deployed ResourceLoader. It does all the combining and minification of Javascript and CSS. It also includes filters for optimizing JPEG and PNG images. I'm pretty sure we're not running Apache on the media servers, so the benefit here is moot. In general: cool, and probably useful for a lot of people. Probably not useful for WMF. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Selenium Smoke Test Framework
Hi All, More Test Cases could be add to the existing Selenium Test framework. The idea should be to test the main Wiki Editor functionalities and Page view/preview functionalities in a smoke test suite. The detailed administrative functionalities as User Preferences (more advanced features as Managing Watch-list, Advanced options in Editing, E-mail options) should be covered in a separate detailed test suite if necessary. Wiki Editor functionalities can be tested by automating Content Addition in a new wiki page. All the basic text editing can be performed and should be verified in page preview and saved page view. The same page can be tested for Content Editing by performing same editing functionalities in the previously saved page. The content changes can be verified in page preview and saved page view. Set Basic preferences can be tested separately and basic settings as Basic Information, Signature, Date Format, Skin can be tested. The applied preferences can be verified against the saved page. The other utility functionalities as Search for Pages, Move Page, My Watch-list, My Contributions, Delete Pages can be tested at the end of the test suite. Delete Page functionality can be used to delete all the newly created pages. So the smoke test suite can be of 4 main test suites; Add content to new Page (Wiki Editor for new page) Edit content (Edit content in existing page) Basic user preferences (Basic Information, Signature, Date Format, Skin) Extra features (search, move, delete, watch-list, contribution) All the above can be supported by some common functionalities as; User Login Search for Pages Search and copy Text Select applied skin Get Page Name and other attributes (Page Headings/Titles etc.) Get text atttributes (bold, italic, font size etc.) Regards, Jinesh De Silva Calcey Technologies - http://www.calcey.com/ www.calcey.com Voice: +94 11 2827560 Fax : +94 11 2827561 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Are deps files still needed?
I'm referring to the Foo.deps.php files which contain: // This file exists to ensure that base classes are preloaded before // filename is compiled, working around a bug in the APC opcode // cache on PHP 5, where cached code can break if the include order // changed on a subsequent page view. // see http://lists.wikimedia.org/pipermail/wikitech-l/2006-January/021311.html The referenced bug http://pecl.php.net/bugs/bug.php?id=6503 is marked as fixed in PHP 5.1.x. Can we remove those file or is there something else going on with this problem that we should be aware of? -Niklas -- Niklas Laxström ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla keywords for deployment queues?
Ashar Voultoiz wrote: On 04/11/10 00:35, K. Peachey wrote: They are under a plain text RCS now which is documented on wikitech. If you are talking about [[RCS]], it is 6 years old, written by myself. http://wikitech.wikimedia.org/history/RCS Always read the Wikitech pages with a critical view! I think that they are in the svn-private repository. I was surprised when I knew some easy checking steps for sync-file/scapping weren't taken, though. At least now sync-file does a php lint. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] mod_pagespeed?
Chad wrote: From their site: mod_pagespeed includes several filter that optimize JavaScript, HTML and CSS stylesheets.. This is already being handled by the in-trunk-but-not-deployed ResourceLoader. It does all the combining and minification of Javascript and CSS. It also includes filters for optimizing JPEG and PNG images. I'm pretty sure we're not running Apache on the media servers, so the benefit here is moot. In general: cool, and probably useful for a lot of people. Probably not useful for WMF. -Chad I think many of their changes would break MediaWiki caching system. We could reuse their image stripping module [1] on generating the thumbnails, although the mention that it may produce a XSS make me wary of such method. 1- http://code.google.com/intl/de/speed/page-speed/docs/filter-image-optimize.html ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Selenium Smoke Test Framework
Hi everyone, Some context here: Jinesh and the folks at Calcey are going to be pitching in on building out our Selenium test framework. I asked them to take a look here: http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/maintenance/tests/selenium/suites/MediawikiCoreSmokeTestCase.php?view=markup ...and then to suggest a plan of attack for building that out into a proper smoke test suite, as well as creating a larger battery of tests that we can run for comprehensive testing. If people have thoughts on the types of things that developers inadvertently break that something like Selenium would be appropriate for trying to detect, your thoughts would be greatly appreciated here. Jinesh, this looks like a great start. Comments inline: On Thu, Nov 4, 2010 at 4:34 AM, Jinesh De Silva jin...@calcey.com wrote: More Test Cases could be add to the existing Selenium Test framework. The idea should be to test the main Wiki Editor functionalities and Page view/preview functionalities in a smoke test suite. Yup, I agree, though one point we should probably clarify. The core smoke test should just test whether the plain editor works (without the WikiEditor extension). The WikiEditor extension should probably be tested as part of a suite of tests associated with all of the extensions we run in production. By the way, here's a list of the extensions we run on English Wikipedia: http://en.wikipedia.org/wiki/Special:Version ...as well as the full list of extensions we currently have available in production: http://svn.wikimedia.org/viewvc/mediawiki/branches/wmf/1.16wmf4/extensions/ I don't have a strong opinion about which of these we should try tackling first, but generally testing the extensions that are most heavily used seems like a good thing to me. The detailed administrative functionalities as User Preferences (more advanced features as Managing Watch-list, Advanced options in Editing, E-mail options) should be covered in a separate detailed test suite if necessary. Also agreed. Perhaps others on this list can let us know: which aspects of these features are the most fragile + impact a lot of people when they break? My instinct is not to worry too much about these for now. Wiki Editor functionalities can be tested by automating Content Addition in a new wiki page. All the basic text editing can be performed and should be verified in page preview and saved page view. The same page can be tested for Content Editing by performing same editing functionalities in the previously saved page. The content changes can be verified in page preview and saved page view. Set Basic preferences can be tested separately and basic settings as Basic Information, Signature, Date Format, Skin can be tested. The applied preferences can be verified against the saved page. The other utility functionalities as Search for Pages, Move Page, My Watch-list, My Contributions, Delete Pages can be tested at the end of the test suite. Delete Page functionality can be used to delete all the newly created pages. So the smoke test suite can be of 4 main test suites; Add content to new Page (Wiki Editor for new page) Edit content (Edit content in existing page) Basic user preferences (Basic Information, Signature, Date Format, Skin) Extra features (search, move, delete, watch-list, contribution) All the above can be supported by some common functionalities as; User Login Search for Pages Search and copy Text Select applied skin Get Page Name and other attributes (Page Headings/Titles etc.) Get text atttributes (bold, italic, font size etc.) This looks like a really good plan of attack. Anyone else care to weigh in? Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [WikiEN-l] Images loading slowly?
I was fine until now; https://secure.wikimedia.org/wikipedia/en/wiki/Fat_Man has the top image broken now consistently. I have checked on multiple computers, same results. Cc'ed wikitech-l. I'd post to IRC but I'm not able to access it at the moment... -george On Thu, Nov 4, 2010 at 12:28 PM, Alan Liefting alieft...@ihug.co.nz wrote: Some are not loading for me at all this morning. Alan On 5/11/2010 6:19 a.m., Charles Matthews wrote: I've noticed a very much slower rate of loading of images for several days now. It's affecting the work I can do. Is this a general experience, or is it perhaps my ISP? Charles ___ WikiEN-l mailing list wikie...@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l - No virus found in this message. Checked by AVG - www.avg.com Version: 10.0.1153 / Virus Database: 424/3235 - Release Date: 11/03/10 ___ WikiEN-l mailing list wikie...@lists.wikimedia.org To unsubscribe from this mailing list, visit: https://lists.wikimedia.org/mailman/listinfo/wikien-l -- -george william herbert george.herb...@gmail.com ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Selenium Smoke Test Framework
On Fri, Nov 5, 2010 at 10:33 AM, Rob Lanphier ro...@wikimedia.org wrote: If people have thoughts on the types of things that developers inadvertently break that something like Selenium would be appropriate for trying to detect, your thoughts would be greatly appreciated here. DB support for the other formats (aka, apart from just MySQL), if it installs, and some core functions work. -Peachey ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Cross wiki script importing
On 11/01/2010 09:29 AM, Tisza Gergő wrote:
Raimond Spekkingraimond.spekkingat gmail.com writes:
Try something like
importScriptURI('http://ml.wikipedia.org/w/index.php?title=Mediawiki:rules.jsaction=rawctype=text/javascript');
That will break HTTPS security though. I use this script on my home
wiki:
Here's another one from
http://commons.wikimedia.org/wiki/User:Ilmari_Karonen/monobook.js:
/**
* Load a script from another Wikimedia wiki. Based on importScript()
in wikibits.js.
* Does the right thing also when used via the secure server.
*
* Usage example: importScriptFromWiki(User:Ilmari
Karonen/replace.js, en, wikipedia);
*
* Leave the third parameter empty for wikis like meta or commons that
have .wikimedia.org
* host names but belong internally to the wikipedia group for
historical reasons!
*/
function importScriptFromWiki(page, lang, domain) {
if (wgServer == 'https://secure.wikimedia.org') {
if (!domain) domain = 'wikipedia';
var prefix = '/' + domain + '/' + lang;
} else {
if (!domain) domain = 'wikimedia';
var prefix = 'http://' + lang + '.' + domain + '.org';
if (prefix == wgServer) prefix = ;
}
var uri = prefix + '/w/index.php?title=' +
encodeURIComponent(page.replace(/
/g,'_')).replace(/%2F/ig,'/').replace(/%3A/ig,':') +
'action=rawctype=text/javascript';
return importScriptURI(uri);
}
--
Ilmari Karonen
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
