Wikitech-l January 2011

wikitech-l@lists.wikimedia.org

94 participants
75 discussions

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 04 Jan '11

04 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 03 Jan '11

03 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

Missing Section Headings
by Marc Riddell 03 Jan '11

03 Jan '11

Hello, I have been a WP editor since 2006. I hope you can help me. For some reason I no longer have Section Heading titles showing in the Articles. This is true of all Headings including the one that carries the Article subject's name. When there is a Table of Contents, it appears fine and, when I click on a particular Section, it goes to that Section, but all that is there is a straight line separating the Sections. There is also no button to edit a Section. If I edit the page and remove the "== ==" markers from the Section Titles, the Title then shows up, but not as a Section Heading. Also, I don't have any Date separators on my Want List. This started 2 days ago. Any thoughts? Thanks, Marc Riddell [[User:Michael David]]

9 10

Re: [Wikitech-l] Missing Section Headings
by Brion Vibber 03 Jan '11

03 Jan '11

The fix is to stop using IE for Mac -- it's been unmaintained for almost a decade and is wildly broken in so many ways that it's pretty much useless for everyday web browsing. -- brion On Jan 3, 2011 9:58 AM, "Platonides" <Platonides(a)gmail.com> wrote:

4 4

ERR_INVALID_REQ when trying upload a file with API
by Jan Luca 03 Jan '11

03 Jan '11

Hi, when I try to upload a file with the API (Request: http://toolserver.org/~jan/files/APIUploadREQError.txt), I get the following error: Request: [unknown method] [no URL], from <my IP> via amssq35.esams.wikimedia.org (squid/2.7.STABLE7) to [unknown host] ([unknown]) Error: ERR_INVALID_REQ, errno [No Error] at Sun, 02 Jan 2011 09:43:01 GMT Can you help me? Best regards, Jan

2 2

en.wiki dump status
by John 03 Jan '11

03 Jan '11

according to http://dumps.wikimedia.org/backup-index.html the last dump was 2010-11-10 04:30:28 is that page broken or are dumps still halted?

1 0

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