Wikitech-l November 2011

wikitech-l@lists.wikimedia.org

127 participants
144 discussions

Start a nNew thread

New committer
by Tim Starling 07 Nov '11

07 Nov '11

* Olivier Beaton (finlay): Realnames extension. Creating in case he still wants it. -- Tim Starling

1 0

Bugzilla Weekly Report
by reporter 07 Nov '11

07 Nov '11

MediaWiki Bugzilla Report for October 31, 2011 - November 07, 2011 Status changes this week Bugs NEW : 289 Bugs ASSIGNED : 11 Bugs REOPENED : 37 Bugs RESOLVED : 146 Total bugs still open: 6540 Resolutions for the week: Bugs marked FIXED : 106 Bugs marked REMIND : 0 Bugs marked INVALID : 9 Bugs marked DUPLICATE : 19 Bugs marked WONTFIX : 6 Bugs marked WORKSFORME : 9 Bugs marked LATER : 0 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component MobileFrontend 17 OpenStackManager 8 Images and files 7 Site requests 5 General/Unknown 5 New Bugs Per Product MediaWiki 35 Wikimedia 23 MediaWiki extensions 57 Wikimedia Mobile 8 Security 2 Top 5 Bug Resolvers brion [AT] wikimedia.org 25 jeroen_dedauw [AT] yahoo.com 12 mah [AT] everybody.org 12 aschulz4587 [AT] gmail.com 10 preilly [AT] wikimedia.org 9

1 0

Bash scripts for standalone development installation in maintenance/dev/
by Daniel Friesen 06 Nov '11

06 Nov '11

A few days ago in #mediawiki ^demon made a comment about php 5.4 having a built-in webserver. After a little bit of looking at that we found that when MediaWiki was combined with a standalone copy of 5.4 and the webserver and sqlite support built-in it was possible to startup a quick and easy development instance of MediaWiki with nothing but the MW code and an isolated copy of php. (ie: no real extra dependencies besides what you'd expect on a unix-like OS setup to be able to compile something) I threw together some bash scripts that will download the latest php 5.4, configure and install it into maintenance/dev/php/, install an sqlite based install of MediaWiki, and startup php's built in development webserver on localhost. Anyone have a problem with these bash scripts being committed to /trunk/phase3/maintenance/dev/ for anyone checking out MW to use? -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

3 2

Core devs: What changes do extension devs needs to make from 1.17 to 1.18?
by Olivier Beaton 06 Nov '11

06 Nov '11

On September 22nd I started an initiative to document what extension authors should be doing when trying to support newer (and older!) versions of mediawiki. This culminated in [1] http://www.mediawiki.org/wiki/Manual:Extension_support Now that we have a new version coming out (1.18.0beta1, I would like to call core dev attention to two articles that need updating: [2] http://www.mediawiki.org/wiki/Manual:Extension_support/1.18/ExtUpgrading Is for extensions authors who have extensions in 1.17 and want to update them for 1.18. Please feel free to add anything you know of. While code samples for best-practices are encouraged, linking to manual pages where new documentation resides is the preferred method when possible. [3] http://www.mediawiki.org/wiki/Manual:Extension_support/1.17/ExtDowngrading Is for extension authors who are coding against 1.18, and want to support the large number of 1.17 already deployed who will take awhile to upgrade. A strong emphasis here would be on branching code that allows people to use the new "preferred" method while still retaining support for older methods (through the use of method_exists and the like). Code samples are more frequent here, but again please link to actual documentation for individual objects, methods, etc. One advantage of having itemized lists like this is that extension authors don't have to dig through all the changelogs (which often just have a short summary and links to bug reports), and changes are more clearly communicated to the community of developers. People who have requirements for supporting older wikis also have clear instructions on how to best go about it, and our "upgrade" instructions of the future quickly become our "downgrade" instructions of the past. Hopefully in the long run this will help communication between these two bodies. Thanks, Olivier Finlay Beaton

2 2

svn auto-props http://www.mediawiki.org/wiki/Subversion/auto-props#Setting_auto-props up to date ?
by Thomas Gries 06 Nov '11

06 Nov '11

Hi, is this list up to date ? http://www.mediawiki.org/wiki/Subversion/auto-props#Setting_auto-props

3 3

New committer
by Sumana Harihareswara 05 Nov '11

05 Nov '11

Alexander Gesinn (planetenxin) now has extensions access. "I'd like to commit a new and lightweight extension (UserAgent) that adds some magic words to retrieve User Agent ID and User Agent Version from HTTP_USER_AGENT. Further plans to maintain existing extensions." Welcome! -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation

5 4

failed to mkdir "/path_to_mw/images/tmp"
by Duy Trinh 05 Nov '11

05 Nov '11

Hi all! After building texvc and setting $wgUseTex = true in my LocalSettings.php I am running into a warning message: Warning: wfMkdirParents: failed to mkdir "/path_to_mw/images/tmp" mode 511 in /path_to_mw/includes/GlobalFunctions.php on line 2324 This warning also occurs after manually mkdir "tmp" in "images" -- there's also no change with both directories set to 777. What am I doing wrong? Any hint is greatly appreciated. Thanks a bunch -- Duy

2 1

Northern Soto Wikipedia
by Andre Engels 05 Nov '11

05 Nov '11

There seems to be a Northern Soto Wikipedia at http://nso.wikipedia.org, at least that's what http://incubator.wikimedia.org/wiki/Wp/nso claims. However, when I go to that site I see the following text: Unstub loop detected on call of $wgLang->getCode from MessageCache::get Backtrace: #0 /usr/local/apache/common-local/php-1.18/includes/StubObject.php(57): StubObject->_unstub('getCode', 5) #1 /usr/local/apache/common-local/php-1.18/includes/StubObject.php(147): StubObject->_call('getCode', Array) #2 [internal function]: StubUserLang->__call('getCode', Array) #3 /usr/local/apache/common-local/php-1.18/includes/cache/MessageCache.php(611): StubUserLang->getCode() #4 /usr/local/apache/common-local/php-1.18/includes/GlobalFunctions.php(1339): MessageCache->get('gadgets-definit...', true, false) #5 /usr/local/apache/common-local/php-1.18/extensions/Gadgets/Gadgets_body.php(510): wfEmptyMsg('gadgets-definit...', '<gadgets-def...') #6 /usr/local/apache/common-local/php-1.18/extensions/Gadgets/Gadgets_body.php(38): Gadget::loadStructuredList() #7 [internal function]: GadgetHooks::userGetDefaultOptions(Array) #8 /usr/local/apache/common-local/php-1.18/includes/Hooks.php(216): call_user_func_array('GadgetHooks::us...', Array) #9 /usr/local/apache/common-local/php-1.18/includes/GlobalFunctions.php(3621): Hooks::run('UserGetDefaultO...', Array) #10 /usr/local/apache/common-local/php-1.18/includes/User.php(1211): wfRunHooks('UserGetDefaultO...', Array) #11 /usr/local/apache/common-local/php-1.18/includes/User.php(2131): User::getDefaultOptions() #12 /usr/local/apache/common-local/php-1.18/includes/RequestContext.php(213): User->getOption('language') #13 /usr/local/apache/common-local/php-1.18/includes/StubObject.php(151): RequestContext->getLang() #14 /usr/local/apache/common-local/php-1.18/includes/StubObject.php(103): StubUserLang->_newObject() #15 /usr/local/apache/common-local/php-1.18/includes/StubObject.php(57): StubObject->_unstub('getCode', 5) #16 /usr/local/apache/common-local/php-1.18/includes/StubObject.php(147): StubObject->_call('getCode', Array) #17 [internal function]: StubUserLang->__call('getCode', Array) #18 /usr/local/apache/common-local/php-1.18/includes/cache/MessageCache.php(611): StubUserLang->getCode() #19 /usr/local/apache/common-local/php-1.18/includes/GlobalFunctions.php(1173): MessageCache->get('titleblacklist-...', true, false) #20 /usr/local/apache/common-local/php-1.18/includes/GlobalFunctions.php(1242): wfMsgGetKey('titleblacklist-...') #21 /usr/local/apache/common-local/php-1.18/extensions/TitleBlacklist/TitleBlacklist.hooks.php(85): wfMsgWikiHtml('titleblacklist-...', '.* <noedit> # T...', 'Andre Engels') #22 /usr/local/apache/common-local/php-1.18/extensions/TitleBlacklist/TitleBlacklist.hooks.php(106): TitleBlacklistHooks::acceptNewUserName('Andre Engels', Object(User), '') #23 [internal function]: TitleBlacklistHooks::centralAuthAutoCreate(Object(User), 'Andre Engels') #24 /usr/local/apache/common-local/php-1.18/includes/Hooks.php(216): call_user_func_array('TitleBlacklistH...', Array) #25 /usr/local/apache/common-local/php-1.18/includes/GlobalFunctions.php(3621): Hooks::run('CentralAuthAuto...', Array) #26 /usr/local/apache/common-local/php-1.18/extensions/CentralAuth/CentralAuthHooks.php(469): wfRunHooks('CentralAuthAuto...', Array) #27 /usr/local/apache/common-local/php-1.18/extensions/CentralAuth/CentralAuthHooks.php(253): CentralAuthHooks::attemptAddUser(Object(User), 'Andre Engels') #28 [internal function]: CentralAuthHooks::onUserLoadFromSession(Object(User), NULL) #29 /usr/local/apache/common-local/php-1.18/includes/Hooks.php(216): call_user_func_array('CentralAuthHook...', Array) #30 /usr/local/apache/common-local/php-1.18/includes/GlobalFunctions.php(3621): Hooks::run('UserLoadFromSes...', Array) #31 /usr/local/apache/common-local/php-1.18/includes/User.php(930): wfRunHooks('UserLoadFromSes...', Array) #32 /usr/local/apache/common-local/php-1.18/includes/User.php(272): User->loadFromSession() #33 /usr/local/apache/common-local/php-1.18/includes/User.php(3928): User->load() #34 /usr/local/apache/common-local/php-1.18/includes/User.php(2125): User->loadOptions() #35 /usr/local/apache/common-local/php-1.18/includes/RequestContext.php(213): User->getOption('language') #36 /usr/local/apache/common-local/php-1.18/includes/StubObject.php(151): RequestContext->getLang() #37 /usr/local/apache/common-local/php-1.18/includes/StubObject.php(103): StubUserLang->_newObject() #38 /usr/local/apache/common-local/php-1.18/includes/StubObject.php(57): StubObject->_unstub('getCode', 5) #39 /usr/local/apache/common-local/php-1.18/includes/StubObject.php(147): StubObject->_call('getCode', Array) #40 [internal function]: StubUserLang->__call('getCode', Array) #41 /usr/local/apache/common-local/php-1.18/includes/cache/MessageCache.php(611): StubUserLang->getCode() #42 /usr/local/apache/common-local/php-1.18/includes/GlobalFunctions.php(1173): MessageCache->get('pagetitle', true, false) #43 /usr/local/apache/common-local/php-1.18/includes/GlobalFunctions.php(1153): wfMsgGetKey('pagetitle', true, false, true) #44 /usr/local/apache/common-local/php-1.18/includes/GlobalFunctions.php(1071): wfMsgReal('pagetitle', Array) #45 /usr/local/apache/common-local/php-1.18/includes/OutputPage.php(773): wfMsg('pagetitle', 'Letlakala la Pe...') #46 /usr/local/apache/common-local/php-1.18/includes/Article.php(369): OutputPage->setPageTitle('Letlakala la Pe...') #47 /usr/local/apache/common-local/php-1.18/includes/Wiki.php(468): Article->view() #48 /usr/local/apache/common-local/php-1.18/includes/Wiki.php(239): MediaWiki->performAction(Object(Article)) #49 /usr/local/apache/common-local/php-1.18/includes/Wiki.php(624): MediaWiki->performRequest() #50 /usr/local/apache/common-local/php-1.18/includes/Wiki.php(531): MediaWiki->main() #51 /usr/local/apache/common-local/php-1.18/index.php(57): MediaWiki->run() #52 /usr/local/apache/common-local/live-1.5/index.php(3): require('/usr/local/apac...') #53 {main} I guess something has been set up incorrectly? -- André Engels, andreengels(a)gmail.com

8 10

HTML Tidy might be getting some "HTML5" support
by Bjoern Hoehrmann 05 Nov '11

05 Nov '11

Hello, Last I heard, many Wikimedia and other MediaWiki installations relied on HTML Tidy to some degree to cope with bad markup, like templates may generate. There is also some interest in using "HTML5" features in MediaWiki wikis, but combining the two is difficult as Tidy will choke on elements it does not know (since it does not know how to parse them) and configuring them with the new-*-tags options is troublesome. I made http://lists.w3.org/Archives/Public/www-archive/2011Nov/0006.html some patches to address that problem (and only that problem really, Tidy is not going to be a proper "HTML5" parser that parses documents exactly as a browser would) so that Tidy keeps working with old markup as usual, but doesn't choke on new elements, doesn't complain about new attributes and doesn't "break" conforming documents. Where new markup is malformed, Tidy is unlikely to repair it as sensibly as it does for old markup, and it may in fact make them even more malformed or otherwise break them. I do not care about that at this point, and there is nobody else contribu- ting code to the project of late. I am interested in polishing my patch and including this in the official repository, but I need people I can blame instead of myself when it does not work right, err, I mean, testers. I haven't heard from anyone with a MediaWiki background that they actually had some problem with Tidy plus "HTML5", but if that is just because deployment is slow, this is likely the best place to look for takers. Discussion is taking place on tidy-develop(a)lists.sourceforge.net but you can also use the bug tracker on sourceforge or mail me directly, ideally sending a copy to www-archive(a)w3.org so there is a publically archived copy I can refer others to if they would like to help out. Feedback on other things than the patch or "HTML5" support in general is welcome too of course. regards, -- Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

1 0

Search is central
by jidanni＠jidanni.org 05 Nov '11

05 Nov '11

"Search is central to the Wikipedia experience – both as a way of reaching the website as well as discovering content on Wikipedia." http://blog.wikimedia.org/2011/10/26/search-and-wikipedia/ Alas, Search is not central for these lists, $ GET http://lists.wikimedia.org/robots.txt # robots.txt for lists.wikimedia.org # # Disabled crawling for several lists 2005-11-26 to # discourage people from complaining about items they # post on public mailing lists being the first Google # search result about them. # # Disabled for all lists 2006-11-03, now that an internal # search has been set up using htdig. # # Note that list archives remain public. # User-agent: * Disallow: /pipermail/ Can they at least take that line about hitdg out.

2 1

← Newer
1
...
9
10
11
12
13
14
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l November 2011