Wikitech-l September 2011

wikitech-l@lists.wikimedia.org

111 participants
128 discussions

On third-party users of MediaWiki and collaboration with upstream
by Jack Phoenix 27 Sep '11

27 Sep '11

Hi all, while MediaWiki has been and is developed primarily with Wikimedia Foundation's interests in mind, there are some big third-party users of MediaWiki out there; while Wikia and wikiHow are the biggest and most well-known, they certainly aren't the only ones. What's common to third-party users of MediaWiki is not just custom extensions, but sadly core changes, or as they're better known, core hacks -- unsupported changes to the core of the MediaWiki software. I think that everyone will agree with me when I say that we will want to reduce the amount of core hacking by third-parties and instead increase collaboration with us, the upstream developers of MediaWiki. Reducing the amount of core hacks is generally a good idea for third parties, because it will allow them to upgrade to the latest stable version of MediaWiki easily and things like new hooks can and in many cases are useful to other users of MediaWiki. For example, the MakeGlobalVariablesScript hook ( http://www.mediawiki.org/wiki/Manual:Hooks/MakeGlobalVariablesScript) was originally introduced by Wikia (under the name 'ExtendJSGlobalVars'); in r38397 I added the hook into core under its current name and right now there are many extensions using the hook, including ones used by Wikimedia Foundation sites (see http://www.mediawiki.org/wiki/Category:MakeGlobalVariablesScript_extensions). This is a fine example of how a third-party core hack became a part of the MediaWiki core and thus something useful to other users of MediaWiki, including the Wikimedia Foundation. Another factor to take into account is security. According to the Version lifecycle page on MediaWiki.org (see http://www.mediawiki.org/wiki/Version_lifecycle), "The release manager has also issued a strong recommendation that versions not listed above as current version or legacy version should not be used in a productive environment. They may contain critical security vulnerabilities and other major bugs, including the threat of possible data loss and/or corruption". For example, wikiHow is running MediaWiki 1.12.0, which was released on 21 March 2008 -- over three years ago. While I'm sure that the wikiHow developers have applied plenty of the more modern security patches, there's still a possibility that they may have missed one patch -- and even if not, MediaWiki 1.12.0 doesn't have all the cool new features that MediaWiki 1.17.0 has. :-) Essentially I'd like to see all major third-party users contributing code to the upstream version of MediaWiki and everyone keeping their copies of MediaWiki on the official MediaWiki Subversion repository at svn.wikimedia.org. Maybe we could have a branch for each third party under /mediawiki/branches/ or if that's unacceptable, then maybe even a whole new repository (like how we currently have mediawiki, mysql, pywikipedia and wikimedia -- see http://svn.wikimedia.org/viewvc), although I must admit that it sounds a bit overkill to me. I know from experience that many third parties have written some awesome code and that there are many other people interested in third-party code, but usually getting third-party code to run requires plenty of knowledge about PHP and MediaWiki as the extensions and core changes have usually been designed to work with one site or one farm. I want to change that and bring more extensions available to the general public -- after all, there are many people out there who run a MediaWiki wiki yet they aren't very PHP-savvy. The official MediaWiki Subversion repository is also well-known and it can also act as a "backup" of some kind. I'm sure that most people and companies have extensive backup systems in place, but everything is still possible. For example, the social wiki/blog hybrid site ArmchairGM, where the SocialProfile extension ( http://www.mediawiki.org/wiki/Extension:SocialProfile) and many other, equally cool and interesting extensions were developed, had its own codebase. While the main Wikia codebase has been open source for years, the ArmchairGM codebase was only recently (1 August 2011) open-sourced with the kind help of Sean Colombo -- and for a rather long while, it seemed that ArmchairGM's unique skin and the unique extensions had been lost; now that would've been a major loss for the open source community. Tens of thousands of lines of code, dozens of unique features and some pretty skins were nearly lost; I think that it's in everyone's best interest to prevent such incidents from happening and that is possible by keeping the code free and open. I've CC'd this message to Sean Colombo of Wikia, Jack Herrick and Reuben Smith of wikiHow, Joachim Bode of Twoonix Software GmbH and Markus Glaser of Hallo Welt! -- please let me know your thoughts about this idea and how your company would be able to contribute. Thanks and regards, -- Jack Phoenix MediaWiki developer

4 4

Decorification of features
by Olivier Beaton 27 Sep '11

27 Sep '11

I've started a Request for comment on MW for the decorification of MW features into extensions. I am not talking about removing features that we distribute to our users. Simply how we include them in the mediawiki software (core vs extensions) especially now that our new installer allows us to package extensions in the distribution. http://www.mediawiki.org/wiki/Requests_for_comment/decorify_into_extensions I would appreciate hearing the community's thoughts on this. Even if you feel we're not at that point yet, ask yourself when you will be, and if it's better to start on a different path now. - Olivier Finlay Beaton

8 14

originals via API, but thumbs local?
by Russell N. Nelson - rnnelson 27 Sep '11

27 Sep '11

I'm hoping that someone can answer this question off the cuff. Please don't do any research; that's my job. When I fetch an image via the API from a remote wiki using ForeignAPIRepo, the thumbnails end up with a local URL How do get it to use the remote thumbnail URL? E.g. as on this page: http://ersch.wikimedia.org/index.php/File:171296_494394106964_721816964_666… The original comes out of wikipedia/commons, but the thumbs are coming out of images/swift/thumb, which is not to my liking. Instead, I want the images to come out of wikipedia/commons/thumb. Alas, this says nothing about it: http://www.mediawiki.org/wiki/Manual:$wgForeignFileRepos

2 2

Phonegap and Wikimedia mobile apps
by Tomasz Finc 26 Sep '11

26 Sep '11

I've been asking around on IRC but thought it would be good to open up to a larger audience. Has anyone here used PhoneGap (http://www.phonegap.com/) for mobile app development? I'm eager to get your thoughts and potentially brainstorm some new ideas. I'll have a longer mail about this later but since its taken too long to draft it .. i thought i'd just send this snippet now to start the conversation. --tomasz

6 12

CodeReview tagging etiquette
by mhershberger＠wikimedia.org 26 Sep '11

26 Sep '11

Since we right in the middle of deploying the 1.18 codebase to our cluster, we need to make sure we're using tags in CodeReview in a consistent way. After some discussion, here is what we've come up with: 1.18 - This should be backported to the 1.18 tarball release. 1.18wmf1 - This revision should be pushed to the cluster ASAP. post118deploy - This revision should be pushed to the cluster, but it can wait until the dust settles. 1.18ok - old fixmes that aren't a problem if they're deployed as part of 1.18, but need to be fixed for 1.19. *** Do not use this tag for any revisions after the 1.18 branch *** point. We used this tag to remove fixmes from our list of *** 1.18 deployment blockers, while still leaving them marked *** "fixme" revert1.18 - Stuff that needs reverting in 1.18 reverted1.18 - Stuff that was reverted in 1.18 but exists in trunk Full list of tags: http://www.mediawiki.org/wiki/Code_review_tags Please avoid using the 1.18wmf1 tag unless it is directly related to a regression from 1.17 currently visible on the cluster, or it is a very major problem. If we can all use these tags consistently and conservatively it will reduce the amount of stress our engineers suffer during deployment. Thanks, Mark.

1 0

Re: [Wikitech-l] Counting revisions in 2011090
by melvin_mm 26 Sep '11

26 Sep '11

John <phoenixoverride <at> gmail.com> writes: > > mysql> select count(*) from archive; > +----------+ > | count(*) | > +----------+ > | 33263574 | > +----------+ > 1 row in set (8 min 47.50 sec) > > On Sun, Sep 25, 2011 at 5:13 PM, melvin_mm <melvin_mm <at> gmx.de> wrote: > > > Bryan Tong Minh <bryan.tongminh <at> gmail.com> writes: > > > Deleted revisions? > > > > If deleted revisions sum up to ~70.000.000 - could I add this > > information to > > http://en.wikipedia.org/wiki/Wikipedia:Database_download > > ? > > > > What would you advice to do if I wanted to verify the counter result? Ok, thanks! So in pages-meta-history, those ~33.000.000 archived / deleted revisions are not included. Probably this number consists of content from all Namespaces. What about the 37.000.000 revisions that are left now?

2 1

Bugzilla Weekly Report
by reporter 25 Sep '11

25 Sep '11

MediaWiki Bugzilla Report for September 19, 2011 - September 26, 2011 Status changes this week Bugs NEW : 217 Bugs ASSIGNED : 14 Bugs REOPENED : 32 Bugs RESOLVED : 173 Total bugs still open: 6090 Resolutions for the week: Bugs marked FIXED : 95 Bugs marked REMIND : 0 Bugs marked INVALID : 20 Bugs marked DUPLICATE : 27 Bugs marked WONTFIX : 18 Bugs marked WORKSFORME : 9 Bugs marked LATER : 7 Bugs marked MOVED : 0 Specific Product/Component Resolutions & User Metrics New Bugs Per Component Site requests 9 Semantic MediaWiki 8 BookManager 7 Babel 6 SemanticForms 4 New Bugs Per Product MediaWiki 22 Wikimedia 18 MediaWiki extensions 49 Wikimedia Mobile 3 Top 5 Bug Resolvers sam [AT] reedyboy.net 23 brion [AT] wikimedia.org 20 mah [AT] everybody.org 14 niklas.laxstrom [AT] gmail.com 11 tfinc [AT] wikimedia.org 10

1 0

Extension Support
by Olivier Beaton 25 Sep '11

25 Sep '11

I am trying to get more steam behind proper support of our extension community from both the mediawiki documentation and core developers. http://www.mediawiki.org/wiki/Manual:Extension_support This is a landing page for support, the idea is that core developers will document changes that affect extension devs in the subpages for each version, both in new classes/functions/variables exttensions should be using now (Upgrading), and if they use the new functions what they should be using if they want to support a version or two back (Downgrading). These should not read as full guides or documentation, but point people in the right direction to class reference pages and Manual: pages where more extensive documentation can be outlined. As time moves on, your documentation with supporting new versions will become the support docs for older versions, so not only does it help our current authors stay current, but it helps in bringing much older extensions (often unmaintained) up to date, and helps extension authors retain support a bit behind the bleeding edge. I hope that others around can show their support and help out with this task now and in the future. Thanks! Olivier Finlay Beaton

1 0

What is the best way to sync a remote (on the web) wiki with a localhost wiki
by Frank 25 Sep '11

25 Sep '11

I recently installed Mediawiki 1.16 on a wikifarm and also on a flash drive. What I would like to do is develop content on the localhost and then sync it with the global wiki. I have looked at both the WikiSync and Push extensions. Push would be my preference for a number of reasons but have been having problems getting it to work. Contacted the author and after a few emails he suggested I come here since he is not really doing development on that extension any more. Is there another way to do it that is relatively simple? Any help would be greatly appreciated... Frank

1 0

Re: [Wikitech-l] Counting revisions in 2011090
by melvin_mm 25 Sep '11

25 Sep '11

Bryan Tong Minh <bryan.tongminh <at> gmail.com> writes: > On Sun, Sep 25, 2011 at 9:09 PM, melvin_mm <melvin_mm <at> gmx.de> wrote: > > > > Are some revisions, e.g. minor edits not included in the dump? > > > Deleted revisions? > If deleted revisions sum up to ~70.000.000 - could I add this information to http://en.wikipedia.org/wiki/Wikipedia:Database_download ? What would you advice to do if I wanted to verify the counter result?

2 1

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