Wikitech-l March 2011

wikitech-l@lists.wikimedia.org

122 participants
96 discussions

Jan history dumps (bz2 and 7z) now available
by Ariel T. Glenn 18 Mar '11

18 Mar '11

Well that, like many things about dumps, took longer than I would have liked but the January enwikipedia run is finally complete. Unless someone really really wants them (and then we might talk off list about it) I am not going to provide a single file for download of the history dumps; instead they are available in 15 pieces, both bzip2 and 7z compressed. The next run is under way; I expect it to take a while as well, as we are still working bugs out of the system. Please get your eyeballs on these, if you haven't picked them up already, and let me know of any issues with the contents. Thanks, Ariel

1 0

Update collapsed!
by Uwe Baumbach 17 Mar '11

17 Mar '11

Hello, Urgent helpis needed! We carry our genealogical wiki "GenWiki" http://genwiki.genealogy.net in version 1.14.1. We planned to update soon to 1.17.1. So we checked out to http://wiki-test.genealogy.net http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_17/phase3 and after clearing all conflicts we updated database with ./maintenance/update.php All seemed good because of no failures. Calling our test-wiki you will find Warning: mysql_real_escape_string() expects parameter 2 to be resource, null given in /data/wiki/wiki-test/includes/db/DatabaseMysql.php on line 316 Warning: mysql_real_escape_string() expects parameter 2 to be resource, null given in /data/wiki/wiki-test/includes/db/DatabaseMysql.php on line 316 Warning: mysql_query(): supplied argument is not a valid MySQL-Link resource in /data/wiki/wiki-test/includes/db/DatabaseMysql.php on line 23 All of these code snippets are in "core code", not in our extensions! Where/how to heal? We thaught, that code should be running at least? Switch back to 1.16.2? Wait for release of 1.17.x? -- I look forward to your answers... Uwe (Baumbach) U.Baumbach(a)web.de

4 3

ie9 webm components
by Michael Dale 16 Mar '11

16 Mar '11

http://blogs.msdn.com/b/ie/archive/2011/03/16/html5-video-update-webm-for-i… It appears to be a little rough around the edges, but should bode well for Wikimedia video support as IE 9 starts to be pushed out to windows machines and ideally we won't have ie7 and 8 for as long as we have had IE6 ;) If you have not already seen it, the TimedMediaHandler extension supports transcoding to both webm and ogg for mediawiki video assets: http://prototype.wikimedia.org/timedmedia/Main_Page I will integrate links to http://tools.google.com/dlpage/webmmf/ for IE9 users in the mwEmbed player once the components are working a bit more smoothly. peace, --michael

3 2

Special:ListFiles
by Magnus Manske 16 Mar '11

16 Mar '11

I found that [[Special:ListFiles]] is enabled on Commons. Very nice, especially the separation of author (though titled "User") and description. Too lazy to look it up - is this grabbed from the rendered HTML, or stored in the database? If it's the latter, is there a special page to list the files by author, instead of by uploader? Does it work for all authors, or "only" Commons users? Magnus

2 1

A good question
by Victor Vasiliev 16 Mar '11

16 Mar '11

Imagine a user approaches you and asks "What are significant changes between 1.16 and 1.17?" What would you answer? --vvv

5 4

secure/singer proxy errors
by William Allen Simpson 15 Mar '11

15 Mar '11

Secure basically fell over for awhile, generated nothing but proxy errors. I'm not sure that's what really happened. It may have been a complete inability to actually send or receive data, resulting in a timeout of some sort. Take a look at the Ganglia graphs. Free memory gone. Big spike in processes. Big drop in network activity!

5 12

New plans for the skin system
by Daniel Friesen 15 Mar '11

15 Mar '11

http://www.mediawiki.org/wiki/User:Dantman/Skinning_system/New_skin_layout I have some plans for a new way of laying out skins in a new skin system. The key changes being; The creation of new region block handling in the system (default skins typically just including a standard body region and messages region) to replace newtalk, sitenotice, the jsmessage div, bodytext, catlinks, and dataAfterContent (used by flaggedrevs, smw, and other extensions). And changes to what types of navigation we support and how dominant the location of the toolbox is. This new layout and system will likely be done using a planned xml/html based template syntax. http://www.mediawiki.org/wiki/User:Dantman/Skinning_system/Monobook_template http://www.mediawiki.org/wiki/User:Dantman/Skinning_system#xml.2Fhtml_templ… I've thought a lot about various template languages and template language vs. no template and ended up with the result that a xml/html based syntax is the best. The advantage it has over all other syntaxes is context sensitivity. As a simple advantage the fact we can differentiate between html context, attributes, and even css url contexts makes skins much cleaner. There are also various other parts of the syntax that cut down on excessive php blocks. Additionally the backwards compatibility, intelligent lang support, and autodetection of regions are not possible without the template syntax. Additionally the template system being built is designed differently than our QuickTemplate, it doesn't run keys of code which it does not need. This in particular means that things like the addition of support for alternative types of navigation can be added without the inefficiently of parsing navigation messages for navigation pieces which are not used, it also starts to cut out our limitation to pre-defined skin pieces. ---- http://www.mediawiki.org/wiki/User:Dantman/Skinning_system/Skin_examination I would also like to eventually eliminate our three skins using the legacy system (Nostalgia, Standard/Classic, Cologne Blue). They don't "properly" use our SkinTemplate system and require another 930+ lines of code dedicated to their support, full of code duplication which repeatedly gets in the way of new features because we insist that any change we make to the ui should be backported to also work with legacy code. The only arguments I've seen so far for their inclusion are: - There are people from en.wp using these skins, they'll riot if we get rid of any old skins - The quickbar is meant to collapse and nostalgia has no sidebar, these are good for users with small screens. Simple still fulfills the requirement of a functional skin without excess css and js and Simple is not using Legacy code so it's not part of the list trying to be killed off. On the first one I think we need some real stats from en.wp on what skin preferences active users have. On the second one, I've been thinking the best way to deal with users on small screens would be to build an alternative 'thin' version of Vector which is laid out somewhat like nostalgia with no sidebar and a top navigation. The opposing issue of increasingly wide monitors with less vertical space was brought up, so I also thought about making another fat/wide version of vector that tries to skim the content area as close as possible to the top of the screen. ---- If you're wondering what my ideal timeline was: - Minor improvement of footericons and footerlinks (1.18, done). - Improvements to SkinTemplate making it much easier to use (1.18, done) - Moving the whole legacy skin system out of the normal tree and dropping support for use of it outside MW (1.18, done). - Initial introduction of the new template based skin system, not quite making it the dominant system yet (ideally 1.18). - Dropping all legacy skins from the system (1.19) - Migration to the use of the new skin system throughout core and depreciation of SkinTemplate (1.19)-- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

4 4

Fwd: Peering
by Huib Laurens 15 Mar '11

15 Mar '11

Hello, The foundationsite says in the article peering that the foundation is looking for free rack-space / routers. What kind of facilities do they want? Is there a more detailed pages with the wishes en needs for the foundation, or can that be geven here on the list? Best, Huib

2 1

Re: [Wikitech-l] [Mediawiki-l] Best practice for integrating a parser tag and another hook callback?
by Daniel Friesen 14 Mar '11

14 Mar '11

On 11-03-14 10:53 AM, Daniel Barrett wrote: > What is the recommended way to get a parser tag like<foo> and another hook callback to communicate or have a shared state? Here's a simple use case: > > 1. Use a<foo> parser tag to generate some wikitext > 2. Use the SkinAfterBottomScripts hook to inject that wikitext at the bottom of the page > > In this case, what's the best way for the callbacks for<foo> and SkinAfterBottomScripts to share information (in this case, the generated wikitext)? I can think of a few places that<foo> could put its generated wikitext for SkinAfterBottomScripts to access : > > Method 1: Put the two callbacks in the same class and create a static variable to hold the wikitext. I don't like this method because it feels like an ancient "shared memory" solution (with all the usual pitfalls& risks). > > Method 2: Create a custom property in the ParserOutput object ($parser->mOutput) and hang the generated wikitext there. This feels a little better, but unfortunately the parameter list for the SkinAfterBottomScripts hook doesn't include a Parser or ParserOutput object, so it can't access the data. (Theoretically one could use $wgParser, but when I tried this, something in between deleted my custom property.) > > This is just one example. The real question is: what's the best practice for sharing data/state between two callbacks in a MediaWiki extension? > > Thank you very much. > DanB Method 1 is doomed to fail in situations where we fetch from the parser cache. Which is ideally most of the visitor page views. You may be able to use a combination of the ParserCache and it's setProperty, OutputPageParserOutput, and BeforePageDisplay. iirc I used something like that in the Description2 extension. SkinAfterBottomScripts looks annoying without an $out param though. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

1 0

Re: [Wikitech-l] [openZIM dev-l] [Offline-l] openZim export now part of collections extension
by Tomasz Finc 13 Mar '11

13 Mar '11

On Mar 10, 2011, at 10:53 AM, Samuel Klein wrote: > Hello, > > On Wed, Mar 9, 2011 at 5:16 AM, Manuel Schneider > <manuel.schneider(a)wikimedia.ch> wrote: >> CCing Wikimedia CH as the main sponsor of openZIM... >> >> On 09.03.2011 06:50, Tomasz Finc wrote: >>> Today we enabled openZim (http://openzim.org/Main_Page) export to the existing PediaPress collections extension on English Wikipedia and numerous others. In addition to PDF and ODF, you will now see a new export option when browsing the Download section of the Manage Book interface. You can then easily take these files and use them with the Kiwix offline reader (http://kiwix.org/index.php/Main_Page). > > This is really excellent. Thanks for the update. Do we track how > much each export option is used? > >> It is really surprising that this all happened quietly in the background ;-) > > I am not surprised, but this does make my day :) We've actually been posting about this quite actively in http://techblog.wikimedia.org/2011/02/february-wmf-engineering-update/ http://techblog.wikimedia.org/2011/01/update-on-offline-wikimedia-projects/ http://techblog.wikimedia.org/2011/01/wmf-engineering-update/ http://techblog.wikimedia.org/2010/12/december-2010-wmf-engineering-update/ and on mailing lists https://intern.openzim.org/pipermail/dev-l/2011-January/000549.html and we engaged with multiple community members to help us test the extension in its early form. If there was some other form of communication that was missed then please let me know and I'll make sure to include it for further projects. --tomasz

3 3

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 March 2011