Wikitech-l January 2011

wikitech-l@lists.wikimedia.org

94 participants
78 discussions

Introduce phpQuery into MediaWiki?
by Philip Tzou 06 Jan '11

06 Jan '11

According to its website, "phpQuery is a server-side, chainable, CSS3 selector driven Document Object Model (DOM) API based on jQuery JavaScript Library." I feel it will be very convenient if we introduce such jquery-like tools into MediaWiki since we do have the need to parse HTML text. For example, I can replace the awful regex part of LanguageConverter::autoConvert with phpQuery. So I want to ask is it possible to introduce phpQuery into MediaWiki? sincerely, Philip Tzou

3 2

SpecialPages and Related users and titles
by Daniel Friesen 06 Jan '11

06 Jan '11

The way you completely lose your page tabs when switching to Special:MovePage has been a bother to me for awhile... it's bad interface design to have a set of tabs linking to other pages with the same set of tabs, but to have a single one of them strangely point to a page where those tabs completely disappear. 1.18 has a new feature now. From a special page you can call $skin->setRelatedTitle and $skin->setRelatedTitle. Calling setRelatedTitle will mark a title as relevant to the current page, doing so will cause some parts of the ui (namely the page tabs) to display things relevant to that page. Calling setRelatedUser likewise will cause some parts of the ui (namely the toolbox) to display things that they would display if you were on the user's userpage. These methods are currently used by Special:MovePage (title), Special:Undelete (title), Special:Contributions (user), and Special:BlockIp (user). If you have another special page you feel is relevant enough to use these methods feel free to tweak it's code. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

5 7

References bookmarklet?
by David Gerard 06 Jan '11

06 Jan '11

http://davidgerard.co.uk/notes/2011/01/04/what-you-see-is-for-the-win/comme… Someone suggested this on my blog. It's an *excellent* idea and needs a button added for it in the present Vector editor. Jen says: Wednesday 5th January, 2011 at 10:28 pm (Edit) Re John Broughton’s idea for “a **single click** way of generating the standard text/code for a footnote”… Would there be any way to make a nice little bookmarklet so people could drag a URL onto the button, and it would copy a wiki-citation to the clipboard? - d.

1 0

Cleanup of too small categories
by Lars Aronsson 05 Jan '11

05 Jan '11

In the early years 2005-2007, lots of small articles were created in the Swedish Wikipedia, assuming that they would all grow with time (eventualism [1]) and the important thing was to have many articles. Some articles were marked as stubs or substubs, in a random and entirely subjective way. This changed in 2008, when we started to count the length of articles, to identify the shortest ones, and started to systematically extend or merge them into better articles. It's now much easier to identify a new article as being far too short, and to treat this as an urgent problem. Now, I'm feeling we're having the same problem with categories. Some people create lots of subcategories for ever more specialized subdivisions of a topic. Especially, "companies established in 1974" gets divided into subcategories for different businesses [2]. Many of the new categories have only very few members. But we have no principles for understanding whether this really is a problem and no tools to get an overview. We have no way to assess the harm of subdividing a category. If it was only me and my feeling, I would tell them to stop doing this. But this is not enough for a consensus decision. What tools are there to count the number of categories, sort them by the number of members (subcategories and articles), and to determine which branches of the category tree should be pruned? As for "law firms established in 1974", one can't remove that single category without reconsidering the entire "law firms by year of establishment" structure. So a tool should consider at least 2 levels. Which languages of Wikipedia have best organized category trees? I know the German Wikipedia is different. It is often hard to make interwiki links to its categories, but most of the rest seem to build on quite similar ideas. [1] http://meta.wikimedia.org/wiki/Eventualism [2] http://sv.wikipedia.org/wiki/Kategori:F%C3%B6retag_bildade_1974 -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

3 2

JavaScript access to uploaded file contents: SVGEdit gadget needs ApiSVGProxy or CORS
by Brion Vibber 05 Jan '11

05 Jan '11

I did a little more hacking on the SVGEdit extension this weekend: http://www.mediawiki.org/wiki/Extension:SVGEdit The extension now uses SVG-edit's iframe embedding API, which lets us host the actual editor widget on a separate domain from MediaWiki. This also means that it's a short step to being able to slap together the smaller MediaWiki-side JS/CSS code as a gadget, which could be deployed by wiki admins without requiring system-level access to install the extension: http://code.google.com/p/svg-edit/issues/detail?id=747 The primary holdup to being able to deploy it to Wikimedia sites is that scripts running in the MediaWiki context won't have direct access to the contents of files on upload.wikimedia.org. That means we can't load the current version of the file into the editor, which brings things to a nice halt. :( My SVGEdit wrapper code is currently using the ApiSVGProxy extension to read SVG files via the local MediaWiki API. This seems to work fine locally, but it's not enabled on Wikimedia sites, and likely won't be generally around; it looks like Roan threw it together as a test, and I'm not sure if anybody's got plans on keeping it up or merging to core. Since ApiSVGProxy serves SVG files directly out on the local domain as their regular content type, it potentially has some of the same safety concerns as img_auth.php and local hosting of upload files. If that's a concern preventing rollout, would alternatives such as wrapping the file data & metadata into a JSON structure be acceptable? Alternately, we could look at using HTTP access control headers on upload.wikimedia.org, to allow XMLHTTPRequest in newer browsers to make unauthenticated requests to upload.wikimedia.org and return data directly: https://developer.mozilla.org/En/HTTP_Access_Control That would allow the front-end code to just pull the destination URLs from imageinfo and fetch the image data directly. It also has the advantage that it would work for non-SVG files; advanced HTML5 image editing tools using canvas could benefit from being able to load and save PNG and JPEG images as well. https://bugzilla.wikimedia.org/show_bug.cgi?id=25886 requests this for bits.wikimedia.org (which carries the stylesheets and such). In the meantime I'll probably work around it with an SVG-to-JSONP proxy on toolserver for the gadget, which should get things working while we sort it out. -- brion vibber (brion @ pobox.com)

8 16

Secure login and interwiki link failures and best help pages?
by Billinghurst 05 Jan '11

05 Jan '11

Following on from a recent discussion here, I have been trying to watch the WMF world from a secure login. First statement is that it is problematic as so many links fail in the interwiki space. I cannot work out why some links to other wikis work fine and always take me to a secure server, whereas on other occasions I will only be offered a link to a normal http protocol within WMF. Interwikis in a standard form are very problematic, well at least in some places, eg. https://secure.wikimedia.org/wikisource/en/wiki/Author:Alfred_Tennyson both the direct link and the <=> links from [Extension:DoubleWiki Extension] The sister links on that page are similarly problematic Yet if I pop over to Commons, and go to a pages like https://secure.wikimedia.org/wikipedia/commons/wiki/Category:Alfred_Lord_Te… https://secure.wikimedia.org/wikipedia/commons/wiki/Alfred_Tennyson there do not seem the similar problems. Is it due to Commons being on the same path? [Note that I haven't done a forensic analysis, this is all through wanderings] Add to the issue is that so many of the local servers don't have a link to the secure servers as it is not a default configuration. Also something that creates difficulties is that the favicon is the same for all secure.wikimedia.org pages, and when one is working on four or five properties at a time and all the tabs show "[W] My Watchlist" it does get very confusing. If there was some differentiation that would be helpful. To add to that I am unable to find the information to try and understand more about the background to the issue. Any thought/guidance/pointers? ---------------------------------------------------------------- This message was sent using iSage/AuNix webmail http://www.isage.net.au/

2 1

Does anybody have the 20080726 dump version?
by Monica shu 04 Jan '11

04 Jan '11

7 24

MediaWiki security release 1.16.1
by Tim Starling 04 Jan '11

04 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I would like to announce the release of MediaWiki 1.16.1, which is a security and maintenance release. Wikipedia user PleaseStand pointed out that MediaWiki has no protection against "clickjacking". With user or site JavaScript or CSS enabled, clickjacking can lead to cross-site scripting (XSS), and thus full compromise of the wiki account of any user who visits a malicious external site. Clickjacking affects all previous versions of MediaWiki. Our fix involves denying framing on all pages except normal page views and a few selected special pages. To be protected, all users need to use a browser which supports X-Frame-Options. For information about supported browsers, see: <https://developer.mozilla.org/en/the_x-frame-options_response_header> For more information about this vulnerability and the related patch, see: <https://bugzilla.wikimedia.org/show_bug.cgi?id=26561> Other changes in MediaWiki 1.16.1: * (bug 24981) Allow extensions to access SpecialUpload variables again * (bug 24724) list=allusers was out by 1 (shows total users - 1) * (bug 24166) Fixed API error when using rvprop=tags * For wikis using French as a content language, Special:Téléchargement works again as an alias for Special:Upload. * (bug 25167) Correctly load JS fixes for IE6 (fixing a regression in 1.16.0) * (bug 25248) Fixed paraminfo errors in certain API modules. * The installer now has improved handling for situations where safe_mode is active or exec() and similar functions are disabled. * (bug 19593) Specifying --server in now works for all maintenance scripts. * Fixed $wgLicenseTerms register globals. Full release notes: http://svn.wikimedia.org/svnroot/mediawiki/tags/REL1_16_1/phase3/RELEASE-NO… ********************************************************************** Download: http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.1.tar.gz Patch to previous version (1.16.0), without interface text: http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.1.patch.gz Interface text changes: http://download.wikimedia.org/mediawiki/1.16/mediawiki-i18n-1.16.1.patch.gz GPG signatures: http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.1.tar.gz.sig http://download.wikimedia.org/mediawiki/1.16/mediawiki-1.16.1.patch.gz.sig http://download.wikimedia.org/mediawiki/1.16/mediawiki-i18n-1.16.1.patch.gz… Public keys: https://secure.wikimedia.org/keys.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0ixHAACgkQgkA+Wfn4zXmOcgCePqvDrlaw1FZLbtOfx/3tEIID GQkAn3eSSdTbBCOqXLvXNiG4Vm0kXl7r =haR1 -----END PGP SIGNATURE-----

1 0

Re: [Wikitech-l] Does anybody have the 20080726 dump version?
by Huib Laurens 04 Jan '11

04 Jan '11

Okay, I emailed to Anthony how he can upload it. after he is done the content will be at: http://dump.huiblaurens.nl When the date is online I will make sure I have a copy of it somewhere else on a server so it won't get lost. Best, Huib

3 5

Re: [Wikitech-l] Introduce phpQuery into MediaWiki?
by Brion Vibber 04 Jan '11

04 Jan '11

phpQuery itself builds on the DOM module already in PHP, so be aware that using it for this purpose is equivalent to using DOM & Xpath functions already available. For one thing this means that HTML will have to be run through the libxml2 HTML parser (which I have found is very sketchy with perfectly legal implied close tags and such). In addition to memory and performance concerns of parsing the whole document into a DOM tree and reserializing it, you might not get back the structure you put in... hopefully no surprises but keep an eye out. -- brion On Jan 3, 2011 1:49 AM, "Philip Tzou" <philip.npc(a)gmail.com> wrote: > > According to its website, "phpQuery is a server-side, chainable, CSS3 > selector driven Document Object Model (DOM) API based on jQuery JavaScript > Library." > > I feel it will be very convenient if we introduce such jquery-like tools > into MediaWiki since we do have the need to parse HTML text. For example, I > can replace the awful regex part of LanguageConverter::autoConvert with > phpQuery. > > So I want to ask is it possible to introduce phpQuery into MediaWiki? > > sincerely, > > Philip Tzou > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l

2 1

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