I've modified Mediawiki:Common.js to include the following:
I then created a page called testPage and inserted:
<p id="p1">Hello World!</p>
I'm expecting the text to change upon load but nothing is happening.
Prior to the <p> tag addition I had an alert that was working as
expected so at least I know Common.js is working.
Mediawiki? While we're at it is there a real good tutorial on including
AJAX calls w/o needing an extension anywhere?
Thanks - Tod
For about the last 12 hours I have been unable to reliably connect to WMF
wikis. Ive tried both Firefox and IE8 both without success. Pages either
load and proceed to hang forever, or partial page contents are loaded. There
have been multiple reports in -tech about this from multiple people
spanning at least half the globe.
15 77 ms 56 ms 112 ms
16 55 ms 57 ms 60 ms 220.127.116.11.ptr.us.xo.net [18.104.22.168]
17 80 ms 83 ms 84 ms
18 86 ms 104 ms 99 ms te-3-0-0.rar3.atlanta-ga.us.xo.net[22.214.171.124]
19 103 ms 116 ms 87 ms te-4-0-0.rar3.miami-fl.us.xo.net[126.96.36.199]
20 85 ms 122 ms 91 ms 188.8.131.52.ptr.us.xo.net [184.108.40.206]
21 102 ms 93 ms 91 ms w006.z207088246.xo.cnc.net [220.127.116.11]
22 191 ms 207 ms * text.pmtpa.wikimedia.org [18.104.22.168]
23 * * 219 ms text.pmtpa.wikimedia.org [22.214.171.124]
and ping results
Pinging text.pmtpa.wikimedia.org [126.96.36.199] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Reply from 188.8.131.52: bytes=32 time=164ms TTL=45
Ping statistics for 184.108.40.206:
Packets: Sent = 4, Received = 1, Lost = 3 (75% loss),
Approximate round trip times in milli-seconds:
Minimum = 164ms, Maximum = 164ms, Average = 164ms
Hope this helps someone figure out the problem
I've talked a bit on IRC about how I'm using the Bugzilla API to create
various reports. Some people have shown interest — IIRC, MZMcBride said I
should create a graph or report showing which bugs have how many
I haven't done that, but I did create an example Bz API client that I
adapt and can use for writing reports on, for example, our weekly bug
I took advantage of the MWHttpRequest built into MediaWiki, rather than
depending on one of the plethora of PHP-based HTTP client code bases
(like the one available at http://snoopy.sf.net/) and I modified the
JSON RPC client at http://jsonrpcphp.org/ to use the MWHttpRequest
This means you'll have to set $IP and set the MEDIAWIKI constant to true
before including bugzilla.php as I've done in
The sample code I've committed in main.php is supposed to show all
normal or higher priority bugs in bugzilla after their assignee's
emails. This sort of report was useful for me this past week when I
sent nagging emails to MW developers.
Also, after talking to robla today, I went ahead and downloaded a 23mb mbox
file from gmane.org (since one wasn't available from wikimedia.org) and
I'll be working on charting our most prolific bug closers, as well as
Another thing I've been working on is getting more people involved in
code review so that our 1.18 won't be delayed becase of the lack of code
See everyone in Berlin, (everyone who is going to be there, anyway)
Is it possible to have a version control system, e.g. Subversion or Git, as
the backend for MediaWiki instead of a DBMS ?
So far I did not found anything in this direction ...
If not possible: is this due to data model mismatches or "just" missing man
power to have it implemented?
Thanks in advance!
Last week I collaborated with some local hackers on putting realtime
collaborative editing into MediaWiki. That is, where a number of people
can be editing the same article at once, and seeing each others' changes
in real time.
We've been using Etherpad a lot at the WMF so we wanted to see what
would happen if this style of editing were brought to wikis.
I had some friends of friends who have an Etherpad-derivative startup
called Hackpad. We got together and decided to do a sprint for a couple
of days on this idea.
The resulting interface is good proof of concept! Check out their blog post.
We learned a lot, particularly about where the points of agreement and
disagreement are between the Etherpad and MediaWiki ways of thinking
FYI: parts of Hackpad are integrated with Facebook. One of Hackpad's
innovations was to add authentication to Etherpad, particularly
Facebook's auth. You won't have to log in to use this demo but it still
pings their servers. This doesn't herald any new turn of Wikimedia
towards Facebook. Also, the article may be bunched onto one line and be
all in bold -- this is an artifact of Hackpad using the first line of an
article as the headline.
Hackpad has promised to me they'll be publishing some relevant changes
they made to Etherpad for this project, so other Etherpad hackers can do
the same thing.
I've been talking with Trevor & Brion about doing an extension+gadget to
make it easier to invoke a "remote" web-based editor with MediaWiki. The
current WikiEditor sort of has an iframe-crossing API already built into
it, so that might be a place to start.
Neil Kandalgaonkar ) <neilk(a)wikimedia.org>
The Berlin Hack-a-thon (http://hexm.de/2o) and a variety of CSS-related
bugs possibly caused by the recent IE fixes dominated the discussion
durin this week's bug triage. Here's the bugs we discussed and a quick
summary of the decided course of action.
== Bugsmash ==
* http://bugzilla.wikimedia.org/11415: __EDITPARENTSECTION__
I brought up this old enhancement request since it looks like it has
a lot of people chiming in still.
It seems a little hairy, but would make a good candidate for our
upcoming Berlin Hack-a-thon. (i.e. “bugsmash” tag)
* http://bugzilla.wikimedia.org/28819: Deleted revision links should
use "rev_id" not "page/timestamp"
* http://bugzilla.wikimedia.org/28820: Diffs using rev_id should work
when one or both revisions are deleted
* http://bugzilla.wikimedia.org/18104: Schema request change so
deleted edits are identified by revisionID
Brion created thesee bugs which could each be resolved somewhat
independently and suggested them for bugsmash in triage
* http://bugzilla.wikimedia.org/28829: Failure to subscribe to
mediawiki-announce is not reported to the user
PostgresInstaller::canCreateAccounts() gives the wrong result
* http://bugzilla.wikimedia.org/20814: Enable $wgCrossSiteAJAXdomains for wikimedia sites
This isn't going to happen with the code as it exists right
now. Tim has updated the bug with a comment outlining the
problems and I asked him on IRC to create a new bug specifically
addressing the problems that need to be addressed in MediaWiki
before this can be done.
* http://bugzilla.wikimedia.org/28839: Interwiki may circumvent blacklist
Someone can do a SMOP that would find abusable interwiki links.
== CSS errors ==
* http://bugzilla.wikimedia.org/28891: Regression? Clicking on
non-existing image link does not redirect to upload anymore
* http://bugzilla.wikimedia.org/28840: Diffs not displaying
correctly in IE because mediawiki thinks the …
* http://bugzilla.wikimedia.org/28857: Sometimes there's "undefined"
in a Resource loader CSS request
Tim said Roan probably has a patch for this particular bug.
Need to get it applied (if it hasn't been already) and tested.
I've emailed Roan.
* http://bugzilla.wikimedia.org/28851: Display problem on ku.wikipedia
This is likely be caused one of the other general CSS-breakage
or RL-breakage issues. I'll recheck after the other CSS bugs
(above) have been fixed.
== Other problems ==
* http://bugzilla.wikimedia.org/28889: out of memory error when
deleting messages on commons
Fairly isolated since it only happens with a couple of specific
messages on the Commons, which does a lot of customization.
Lowered the priority but asked for other instances of the
* http://bugzilla.wikimedia.org/28827: High NEW PHP Catchable fatal
error: Argument 1 passed to RequestContext::setTitle() must be
an instance of Title, null given
Translatewiki brought this one up because no one had been able
to deal with it yet on IRC. We asked translatewiki for
traceback and I assigned to dantman since he was working on this
* http://bugzilla.wikimedia.org/28842: user rights issue with vector and new editor
Tim is on top of this one and thinks it is an extension problem.
* http://bugzilla.wikimedia.org/28843: Customizable cite error
My description wasn't clear enough — asked Happy-Melon to help
me clarify it.