I'd like to make a call to a service on another server and present the
results in a mediawiki page. Does the current release of MW (1.16.5 I
think) have a built in proxy to support this ?
Thanks - Tod
On Mon, May 2, 2011 at 12:04 AM, Tim Starling <tstarling(a)wikimedia.org>wrote:
> Can someone please tell me, in precise technical terms, what is wrong
> with Wikia's WYSIWYG editor and why we can't use it?
>
> I have heard that it has bugs in it, but I have not been told exactly
> what these bugs are, why they are more relevant for Wikimedia than for
> Wikia, or why they can't be fixed.
>
> Years ago, we talked dismissively about WYSIWYG. We discussed the
> features that a WYSIWYG editor would have to have, pointing out how
> difficult they would be to implement and how we didn't have the
> manpower to pull off such a thing. Now that Wikia has gone ahead and
> implemented those exact features, what is the problem?
>
The most fundamental problem with Wikia's editor remains its fallback
behavior when some structure is unsupported:
"Source mode required
Rich text editing has been disabled because the page contains complex
code."
Here's an example of unsupported code, the presence of which makes a page
permanently uneditable by the rich editor until it's removed:
<table>
<tr><td>a</td></tr>
</table>
You can try this out now at http://communitytest.wikia.com/
It will at least let you edit other *sections* that don't contain anything
that scares it, but if the nasty bit is somewhere in what you want to edit,
it just doesn't recover.
There are some smart things in what they're doing: annotating the markup
ought to be a big help in hooking up the rendered HTML bits back to the
original source. The way they hold template invocations and plugins as
standalone placeholders within the rich text is pretty good (and could be a
bit better if it could display some content and provide even more advanced
invocation editing tools, which is all detail work).
But if it just gives up on entire pages, we've got a problem because to
handle Wikipedia we need to handle lllooonnnggg pages that tend to include
lots of complex templates which pull in funky code of their own.
At a minimum, assuming that other round-tripping problems are all resolved
and the treatment of templates and extensions can be improved, it would need
to be changed to recognize uneditable chunks and present them as a sort of
placeholders too -- like the templates you should be able to dive into
source and edit them if need be, but they ought not destroy the rest of the
page.
Beyond that let's flip the question the other way -- what do we *want* out
of WYSIWYG editing, and can that tool provide it or what else do we need?
I've written up some notes a few weeks ago, which need some more collation &
updating from the preliminary experiments I'm doing, and I would strongly
appreciate more feedback from you Tim and from everyone else who's been
poking about in parser & editing land:
http://www.mediawiki.org/wiki/Wikitext.next
And also some of Trevor's notes which I have poked at:
http://www.mediawiki.org/wiki/Visual_Editor_design
I've got some aggressive ideas about normalizing how we deal with template
expansion to work at the parse tree level; this can be friendlier to some
levels of caching, splitting portions of parsing between PHP and optimized
native code, or even mixing some things between pre-parsed text and
client-side work, but most importantly I'm interested in making sure we have
a relatively clean hierarchical relationship between parts of the document,
which we can use to much more reliably hook up parts of the rendered HTML
output:
* maintain an abstract parse tree that can be hooked up fully to both the
original source text *and* the live output DOM
* do section, paragraph, or table-cell editing inline directly on a view
page, with predictable replacements
It may well be that this is too expansive and we'll want to contract to
something that's more like Wikia's annotated parser output -- in most cases
it should give us similar information but it'll probably be harder to
replace parts of the page at runtime in JavaScript.
Another goal beyond editing itself is normalizing the world of 'alternate
parsers'. There've been several announced recently, and we've got such a
large array now of them available, all a little different. We even use mwlib
ourselves in the PDF/ODF export deployment, and while we don't maintain that
engine we need to coordinate a little with the people who do so that new
extensions and structures get handled.
A new visual editor that's built around a normalized, defined parser could
be a great help; other folks will be able to use compatible parsers instead
of mostly-similar parsers.
For the moment I'm mostly schooling myself on the current state of the world
and setting up experimental tools to aid in debugging extra
parser/editor-related goodies (eg the inspector tool I'm fiddling with at
http://en.wikipedia.org/wiki/User:Brion_VIBBER/vector.js ), but hope to get
some of these projects starting moving forward after Berlin.
-- brion
MediaWiki is currently developed in two branches, with everything going
to trunk, and a slower number of revisions getting also copied to the
stable branch.
That's also the way we want to continue working, having a trunk and a
stable branch.
Currently we store the release notes in a file called RELEASE-NOTES in
the phase3 root of each branch. This is a problem when adding a revision
for backport, since the release notes are not suitable to be added to
the trunk RELEASE-NOTES (they would go inside HISTORY)
but it needs to be added to REL1_X RELEASE-NOTES.
So we end up with release notes added in a different commit, or
revisions with merge conflicts for merging. Which is inconvenient.
Thus, I propose that, from the point we branch 1.18, we keep the stable
branch release notes in trunk, and add trunk release notes in a
different file. trunk and branch RELEASE-NOTES would effectively be the
same file (a revision modifing RELEASE-NOTES and not tagged for backport
would be a bug). This simple change would give us much cleaner merges.
When tagging a new branch, the trunk RELEASE-NOTES would move to
HISTORY, the trunk release notes file to RELEASE-NOTES and a new one
would be created for trunk.
Hi all,
Do we have plans to merge WikiEditor into core, and make it the
default (and only) editing toolbar?
If not, I'd like to propose that we do so at some point (perhaps for
1.18?). It's infinitely better than the old one, very useful,
extensible and really ought to be the only way forward for MediaWiki.
What do other people think?
—Andrew
--
Andrew Garrett
Wikimedia Foundation
agarrett(a)wikimedia.org
This morning I talked to Roan about his thoughts about branching 1.18
now that 1.17beta1 is out. He was in favor of it so I said I would ask
Tim what he thought and then (assuming Tim was OK with it) branch it.
So, after asking Tim for his POV and getting his OK, I went ahead and
created http://svn.wikimedia.org/mediawiki/branches/REL1_18/ to hold
phase3.
I recognize that I will have to be prepared to merge fixes that fix bugs
in 1.17 with the branch I've just created — but I'm anxious to get the
1.18 release on the road NOW.
Along with this, I'm going to be coordinating code review with the
developers and making sure we're aware of our respective areas of
responsibility. I think we're agreed that the keeping CR current is
necessary to have a timely 1.18 release and avoid delays.
Happy hacking!
Mark.
Dear developers,
last year I have posted a huge patch on https://bugzilla.wikimedia.org/show_bug.cgi?id=23506 , which
* makes code Java 1.5+ compatible
* changes to the Java 1.5 AWT layout (no other libraries are necessary)
* Switch over to full maven build
* Creates different flavours of packages (library, source, runnable jar)
* Refactored the directory structure ( /src -> /src/main )
* Includes the commons-compress libraries from apache
As I'd like to improve + package it I would like to know, if there is anyone working on that. I don't have too much time, I'd like to prevent double-work and I'd like to know if there is any interest to include those changes.
Best regards,
Johannes Weberhofer
--
Johannes Weberhofer
Weberhofer GmbH, Austria, Vienna
Hi Everyone,
Please join me in welcoming Asher Feldman to the Wikimedia Foundation
where he is our newest member of the Technical Operations team. He
will be starting in the San Francisco office on May 9, 2011, but you
may see him around before then. He uses the nick handle of binasher
in IRC.
Asher comes with a broad set of database and systems expertise and as a
Performance Engineer here, his focus will be on end-to-end stack tuning and
troubleshooting, to drive better web site performance, availability,
scalability and efficiency.
In his previous jobs, Asher has worked on building and supporting
high traffic web properties (e.g., Amazon and Flickr) and non-profits
as well (Kiva.org, where he overhauled their web infrastructure and
still assists in an advisory capacity.) In addition, he has held senior
systems roles in EDS, Barclays Global Investors and Ofoto (Kodak.)
Besides being a self professed 'geek', Asher is a fan of live and dj'd
music, epicurean of fine and local foods, caudata wrangler, knitter, and
a whiskey taster. He is the proud father of Hazel, who is an ardent fan
of Roald Dahl, loves growing and collecting crystals, and all things
related to the brothers Mario.
Do drop by 3rd Floor to say hi to him.
Thanks,
CT
With encouragement from folks on#mediawiki, I'm being bold and proposing that we deprecate getFullPath(). All it does is call getPath(), and there are only three in-tree consumers of it, as opposed to a bazillion consumers of getPath(): http://toolserver.org/~krinkle/wikimedia-svn-search/view.php?id=193&hash=d9…
Looking forward to seeing those of you who can make it to the Berlin
Hackathon 2011, 13-15 May:
http://www.mediawiki.org/wiki/Berlin_Hackathon_2011
One activity people love at these hackfests: fixing lots of bugs together.
Mark and I have marked about 40 bugs for Berlin, concentrating on
well-defined small standalone bugs with good steps-to-reproduce. If you
know of another bug with those characteristics, feel free to tag it.
https://bugzilla.wikimedia.org/buglist.cgi?keywords=bugsmash&list_id=5492
We're planning on hacking throughout -- if you have an idea for a project
you want people to sprint on, show up & tell people! We will allow for
really tiny presentations, preferably ones that end with either decisions or
"and therefore now we shall hack on foo." :-)
Thanks so much to Wikimedia's Germany chapter for organizing this!
See you there,
Sumana Harihareswara