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 (
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
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
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,
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.
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
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
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
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:
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
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?
I am trying to get more steam behind proper support of our extension
community from both the mediawiki documentation and core developers.
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.
Olivier Finlay Beaton
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...
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
What would you advice to do if I wanted to verify the counter result?