I've modified Mediawiki:Common.js to include the following:
document.getElementById("p1").innerHTML="New text!";
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.
What is the best practice for adding custom javascript code in
Mediawiki? While we're at it is there a real good tutorial on including
AJAX calls w/o needing an extension anywhere?
Thanks - Tod
If folks are looking for an easy introduction to working with
ResourceLoader, one way might be to help with bug 26306 "Cleanup extensions
that include jquery (and common plugins) themselves":
https://bugzilla.wikimedia.org/show_bug.cgi?id=26306
A number of extensions over the years have pulled in their own copies of
jQuery, or particular jQuery or jQuery.ui plugins which are now present in
MediaWiki core and available through ResourceLoader.
The extra copies -- which are usually horribly out of date! -- can generally
now be removed.
Here are commits I made on a couple extensions:
OpenID: needed conversion to RL, used the opportunity to clean up other
minification/spriting
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87845
Collection: most of the old modules had already been switched to RL but the
old files were still there. Cleaned up and swapped one more plugin for the
core copy
http://www.mediawiki.org/wiki/Special:Code/MediaWiki/87847
Don't be afraid to check out
http://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension_…
related doc pages on
mediawiki.org, or bug your fellows -- anything that's not clear now is
something that should be documented better, so don't be shy!
-- brion
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.
traceroute:
15 77 ms 56 ms 112 ms
te1-2-0d0.cir1.chicago2-il.us.xo.net[216.156.72.5]
16 55 ms 57 ms 60 ms 207.88.14.201.ptr.us.xo.net [207.88.14.201]
17 80 ms 83 ms 84 ms
te-3-0-0.rar3.washington-dc.us.xo.net[207.88.12.74]
18 86 ms 104 ms 99 ms te-3-0-0.rar3.atlanta-ga.us.xo.net[207.88.12.9]
19 103 ms 116 ms 87 ms te-4-0-0.rar3.miami-fl.us.xo.net[207.88.12.6]
20 85 ms 122 ms 91 ms 207.88.14.58.ptr.us.xo.net [207.88.14.58]
21 102 ms 93 ms 91 ms w006.z207088246.xo.cnc.net [207.88.246.6]
22 191 ms 207 ms * text.pmtpa.wikimedia.org [208.80.152.2]
23 * * 219 ms text.pmtpa.wikimedia.org [208.80.152.2]
and ping results
Pinging text.pmtpa.wikimedia.org [208.80.152.2] with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Reply from 208.80.152.2: bytes=32 time=164ms TTL=45
Ping statistics for 208.80.152.2:
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
John
After the question came up a few times, Ryan Kaldari and I decided to
document the official list of supported browsers and the information and
logic that surrounds this topic.
http://www.mediawiki.org/wiki/Supported_browsers
- Trevor
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
duplicates.
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
triage.
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
class.
This means you'll have to set $IP and set the MEDIAWIKI constant to true
before including bugzilla.php as I've done in
http://svn.wikimedia.org/svnroot/mediawiki/trunk/tools/bugzilla/client/main…
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
other data.
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
reviewers.
See everyone in Berlin, (everyone who is going to be there, anyway)
Mark.
Hello together!
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!
Heiko Nardmann
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.
http://hackpad.posterous.com/live-editing-mediawiki-with-hackpad
We learned a lot, particularly about where the points of agreement and
disagreement are between the Etherpad and MediaWiki ways of thinking
about editing.
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
* http://bugzilla.wikimedia.org/28845:
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
problem.
* 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
code.
* 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.