Wikitech-l April 2011

wikitech-l@lists.wikimedia.org

99 participants
94 discussions

Status of mobile site (again)
by church.of.emacs.ml 21 Apr '11

21 Apr '11

Hi, since it has been two months since the topic has been brought up on this list... what's the current status of the mobile site? There has been a job opening[1], which closed a few days ago, are there any news on that yet? One example, to show how broken the mobile page really is: On many languages, clicking on an image always returns an error instead of the file description page.[2] The problems with the mobile site are not about aesthetics or minor bugs, but about core features / use cases that are broken. A fix (either bug fixes or a re-write[3]) is needed ASAP. Regards, Tobias / User:Church of emacs [1] http://wikimediafoundation.org/wiki/Job_openings/Software_Developer_%28Mobi… [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=27719 [3] https://bugzilla.wikimedia.org/show_bug.cgi?id=25558

2 1

New window for external link
by Tod 21 Apr '11

21 Apr '11

What would be the easiest way to provide a popup or a new window that would allow a user to switch out to an external URL? I'd like to provide the ability for the user to perform a search against an internal search engine but on a new page. Thanks !

4 4

Re: [Wikitech-l] facebook like box in mediawiki
by bawolff 20 Apr '11

20 Apr '11

> Message: 1 > Date: Tue, 19 Apr 2011 13:01:27 +0100 > From: David Gerard <dgerard(a)gmail.com> > Subject: Re: [Wikitech-l] facebook like box in mediawiki > To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > Message-ID: <BANLkTinLGpC3v0+=H-cOC7Sk+r7uEZHh-A(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 18 April 2011 09:51, Raul Kern <raunator(a)gmail.com> wrote: > > > how to add facebook like box to chapters mediawiki homepage: > > http://et.wikimedia.org > > > Wikinews has a social networking template that (presumably) passes > privacy muster: > > http://en.wikinews.org/wiki/Template:Social_bookmarks > > This works with some JavaScript, I'm not sure of the details. But the > important thing is that it doesn't tell Facebook anything more than > that you came to Facebook from the page you're posting to Facebook > about. > [...] > > > - d. That's correct. It only uses JS to make shorter links ( http://en.wikinews.org/wiki/?curid=1234 style) for twitter. No data is passed to facebook. Its just an image that's hyperlinked in essence. -bawolff

1 0

Server issues
by John 19 Apr '11

19 Apr '11

I have been getting a lot of the Wikimedia Foundation Error messages on en.wp while viewing/editing and there have been reports of similar issues on commons and the secure server. There have been multiple reports reports in -tech with no acknowledgment my sysadmins of this issue so im dropping a note on the mailing list John

2 1

MediaWiki security release 1.16.4
by Tim Starling 19 Apr '11

19 Apr '11

Our patch for the Internet Explorer 6 XSS issue (bug 28235) released two days ago in 1.16.3 was insufficient to fix that bug. The original reporter, Masato Kinugawa, pointed out the flaw on bug 28507. So we are doing another release, which contains a second attempt at fixing the issue. Apologies to everyone for the inconvenience. Big thanks go to Masato Kinugawa for helping to keep MediaWiki secure. Thanks also to Roan Kattouw who helped me test the patch this time around, so that we can hopefully avoid a repeat. It is necessary to upgrade MediaWiki to avoid an XSS vulnerability for Internet Explorer clients, version 6 and earlier. Also, if you used the Apache configuration I suggested in the previous release announcement, you should update it to: RewriteEngine On RewriteCond %{QUERY_STRING} \.[a-z0-9]{1,4}(#|\?|$) [nocase] RewriteRule . - [forbidden] We missed the fact that there can be more than one question mark in a URL. In certain circumstances, IE 6 will use a file extension immediately before a question mark character, regardless of how many question marks precede it. For example, with the URL: http://example.com/a?b?c.html?d?e IE 6 will see the file extension as ".html". ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.tar.gz Patch to previous version (1.16.3): http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.patch.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.tar.gz.sig http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.4.patch.gz.sig Public keys: https://secure.wikimedia.org/keys.html

8 12

april en history dumps incomplete
by Ariel T. Glenn 19 Apr '11

19 Apr '11

The April run of the english history dumps is incomplete. There is at least one file that will need to be regenerated. When it's ready I'll send an email update. I expect a delay of 4-5 days for that. Ariel

1 2

Bug Triage Meeting notes
by mhershberger＠wikimedia.org 19 Apr '11

19 Apr '11

Instead of waiting until Wednesday like I did last week, this week I'll get right to it. The bug triage was at Noon PDT, so our European developers (Sam, Roan, etc.) were able to participate this week. Last week was a call for Parser bugs and ended up being a tour of golden oldies. This week, I tried to keep it more up-to-date and current. I feel like I mostly succeeded. Without further delay, the results of the triage: When using existing DB user, grants aren't added to new tables http://bugzilla.wikimedia.org/28375: Bumped to highest priority since it is tarball blocker Fatal Error if logged in http://bugzilla.wikimedia.org/28439: LQT bug. Low priority since Andrew is currently rewriting this. Caching problems with mobile_main_page http://bugzilla.wikimedia.org/22014 Pinged Tomasz… opening new bug on Canonical URL redirection. related canonical URL redirection issue: https://bugzilla.wikimedia.org/27935 After much discussion created https://bugzilla.wikimedia.org/28602 - Canonicalize URLs Old version seen immediately after edit http://bugzilla.wikimedia.org/27891 Tim gave this the first fix, but it might need another. Vector EditWarning breaks page caching. Edits get erased when navigating back and forth http://bugzilla.wikimedia.org/22680 Assigned to Roan When $wgSpamRegex is triggered be sure to return to editing and not throw the users work away http://bugzilla.wikimedia.org/25985 Slated for 1.18 fix High REOPENED When inserting text in iframe mode (using toolbar, special characters or dialogs) the edit window scrolls http://bugzilla.wikimedia.org/23052 Current bug was fixed, Bug was hijacked. Split off new issue into Bug #28603 Toolbar buttons don't correctly insert lists lucene search for simple text misses some results http://bugzilla.wikimedia.org/25404 Searching is not working on Korean Wikinews and others. http://bugzilla.wikimedia.org/25586 Ops is aware, new search indexer will be set up soon. All should be fine in a few days Normal NEW deformed layout of ogg player options in new gallery http://bugzilla.wikimedia.org/27982 merge queue in IE9 #p-personal portlet links are shown vertically in RTL wikis with Vector http://bugzilla.wikimedia.org/28438 Kaldari will get IE9 set up for testing and fix this one. Upload stash API allows some kinds of resource exhaustion http://bugzilla.wikimedia.org/26063 This a low-risk threat that can be handled by MW or cron garbage collection. Languagelinks aren't working on talk pages http://bugzilla.wikimedia.org/26085 WONTFIX for reasons outlined in the bug. Opened https://bugzilla.wikimedia.org/28604 based on discussion. See comment 12: https://bugzilla.wikimedia.org/26085#c12 Special:Undelete doesn't use ar_page_id http://bugzilla.wikimedia.org/26123 Specifically responding to comment #3: non issue since we sort by time. A file redirect from a foreign File Repo overrides local wiki page (instead of vice versa) http://bugzilla.wikimedia.org/28299 Best decribed in #c2: https://bugzilla.wikimedia.org/show_bug.cgi?id=28299#c2 If it's _not_ affecting page views / editing it may not actually be an issue; if it is, those things need fixing. self unblock with username does not work under 1.17 http://bugzilla.wikimedia.org/28352 Apparently fixed in trunk. I’ll find the revision. Or find someone to find the revision. "Block::purgeExpired" Database returned error "1205: Lock wait timeout exceeded;" http://bugzilla.wikimedia.org/28485 Article::updateCategoryCounts 1213 Deadlock found when trying to get lock http://bugzilla.wikimedia.org/28543 1205: Lock wait timeout exceeded; try restarting transaction http://bugzilla.wikimedia.org/28499 Roan looked at this and saw it focused around a single user on a single wiki. Trying to get another person to look at this one. Escape asterisks (*) in {{PAGENAME}} http://bugzilla.wikimedia.org/28588 Parser bug with a workaround: {{#tag:nowiki|{{PAGENAME}}}} tagged for newparser Edit notices display "edit" tab instead of "view source" even if the editor cannot edit them http://bugzilla.wikimedia.org/28589 Not bumping up priority or assigning IE upload fails silently on Enter key from wpDestFile http://bugzilla.wikimedia.org/25885 Neil will investigate, Replace MD5 password hashing with WHIRLPOOL http://bugzilla.wikimedia.org/28419 Letting Tim set priority since this is his idea. printable version centered images are not centered http://bugzilla.wikimedia.org/28573 Kaldari will do it Remove stub link formatting user preference from MediaWiki core http://bugzilla.wikimedia.org/28426 Get some stats from wmf wikis (presumably fairly popular on small wikis). Roan's running it. Configure which sections of the sidebar navigation menu are expanded/collapsed by default http://bugzilla.wikimedia.org/25394 Parsing the sidebar even more, perhaps wait untill the GUI Special:Sidebar thing is ready (GSoC) so we can store cleanly in db I did ask for UI bugs from the wikitech-l last week and got two from Amir, one of which I included. Discussion during the Triage mirrored discussion on the list last week, and we decided this one was a very low priority fix: diff radio buttons in revision history are not vertically aligned when "Justify paragraphs" is enabled http://bugzilla.wikimedia.org/28359 The other bug I included (from those mentioned on the list) was MZ McBride's. Trevor proposed an improved 404 page last August but no one was taken the time to put it up. Priyanka said she would take charge of the “shell” aspects of this bug: Redesign the wmf non-mediawiki 404 error page http://bugzilla.wikimedia.org/17316 Full notes from the triage are at: http://etherpad.wikimedia.org/BugTriage Mark.

1 0

facebookyzation
by Stefan Werthmann 18 Apr '11

18 Apr '11

facebookyzation the whole net could be a very bad idea ;-). c u stevie

2 1

Linker, more on Skins, OutputPage, and context code patterns changes
by Daniel Friesen 18 Apr '11

18 Apr '11

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]

5 8

https://github.com/mediawiki/ is now up again
by Ævar Arnfjörð Bjarmason 17 Apr '11

17 Apr '11

It's been re-cloned and is being updated every 10 minutes. Note that this was a non-fast-forward updates, so "git pull" on existing checkouts won't work, you'll have to re-clone. On the plus side this is now being cloned directly from svn, e.g. this is the latest commit: git-svn-id: svn+ssh://svn.wikimedia.org/svnroot/mediawiki/trunk@86256 dd0e9695-b195-4be7-bd10-2dea1a65a6b6 This means that using this to bootstap your own git-svn checkout (to use for further development) should be possible now, but I don't have instructions for how to do that, patches to http://www.mediawiki.org/wiki/Git#Rebuilding_SVN_metadata welcome. Note that this is still out of date: http://gitorious.org/mediawiki I don't know who maintains it, but if there's demand for having one on gitorious I'd be happy to update that one too. It's just a matter of adding a couple of extra pushes here: https://github.com/avar/mediawiki-mirror/blob/master/mediawiki-mirror.sh#L22

2 2

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

2026

2025

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