headers
Abhishek Das | 26 Apr 2013 05:36
Picon
Gravatar

Collaborative Real-time Editing in VisualEditor

Hi!

I am Abhishek Das, a student developer from Indian Institute of Technology Roorkee, India. I have been
understanding MediaWiki's code and have started contributing by solving a few bugs marked easy. Here is
my user page: http://www.mediawiki.org/wiki/User:Abhshkdz


I have wide experience in building applications in PHP, MySQL & JavaScript (both client-side &
server-side: Node.js). You can see my Github profile here: https://github.com/abhshkdz. 


Recently, I have been working on a lot of real-time web applications using server set events, websockets as
well as Socket.IO. I have experience in building collaborative document editors. This is a video
conferencing with collaborative document editing application that I built during a 24-hour hackathon
and won it: https://github.com/abhshkdz/hackview. It uses webRTC for Peer-to-peer video
conferencing, and collaborative doc editing over shareJS. 

Few days back, I built an open-source version of WorkFlowy (http://workflowy.com) using Backbone.js and
Socket.IO: https://github.com/abhshkdz/HackFlowy. It has been gaining a lot of traction on Github
with lots of stars and forks. I'm really excited about this one :D.  The tasks get synced real-time
using socket.io and mysql is used as the database.

I wanted to implement a real-time collaborative editor in Wikimedia's VisualEditor as well. 

As pointed out by Sumana Harihareswara some work has already been done on this. I wanted to know what all is
under development at the moment and how I can contribute in making it perfect.

Looking forward to hearing from you soon.

Thanks
Abhishek Das
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sumana Harihareswara | 17 Mar 2013 13:58
Picon
Gravatar

IRC chats this week for Q&A about Lua scripting on wikis

Hi, all!

As you might have seen on the Wikimedia tech blog
<https://blog.wikimedia.org/2013/03/11/lua-templates-faster-more-flexible-pages/>
or the tech ambassadors list
<http://lists.wikimedia.org/pipermail/wikitech-ambassadors/2013-March/000171.html>,
we enabled Lua on all Wikimedia sites last week. Lua
<https://www.mediawiki.org/wiki/Lua> is a scripting language that
enables wiki editors to write faster and more powerful MediaWiki
templates.  We're pretty excited about this, partly because of the
promise of Lua + Wikidata
<https://blog.wikimedia.org/2013/03/14/what-lua-scripting-means-wikimedia-open-source/>.
 To enable Lua templating on your own wiki, install the Scribunto
extension <https://www.mediawiki.org/wiki/Extension:Scribunto>.

If you have questions about how to convert existing templates to Lua (or
how to create new ones), we'll be holding two support sessions on IRC
this week: one on Wednesday
<http://www.timeanddate.com/worldclock/fixedtime.html?hour=02&min=00&sec=0&day=20&month=03&year=2013>(for
Oceania, Asia & America) and one on Friday
<http://www.timeanddate.com/worldclock/fixedtime.html?hour=18&min=00&sec=0&day=22&month=03&year=2013>
(for Europe, Africa & America); see m:IRC office hours
<https://meta.wikimedia.org/wiki/IRC_office_hours> for details. If you
can't make it, you can also get help at mw:Talk:Lua scripting
<https://www.mediawiki.org/wiki/Talk:Lua_scripting>.

If you'd like to learn about this kind of event earlier in advance,
consider becoming a Tech ambassador
<https://meta.wikimedia.org/wiki/Tech/Ambassadors> by subscribing to the
mailing
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gabriel Wicke | 4 Mar 2013 21:01
Picon

Parsoid blog post & job opening

Hi,

we just published a blog post about Parsoid at

http://blog.wikimedia.org/2013/03/04/parsoid-how-wikipedia-catches-up-with-the-web/

We are also looking for somebody to join us in our Parsoid adventure:

http://hire.jobvite.com/Jobvite/Job.aspx?j=oIsbXfw2&c=qSa9VfwQ

Cheers,

Gabriel

_______________________________________________
Wikitext-l mailing list
Wikitext-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitext-l
Permalink | Reply | 0 comments |
headers
Andrew Dunbar | 25 Feb 2013 13:03
Picon
Gravatar

Getting started hacking parsoid

I'd like to get involved in the parsoid effort.

I've been hanging out  in the IRC channel on freenode but there's usually just a dozen lurkers and no action.

In the mailing lists parsoid seems to be mentioned about as often in wikitext-l and wikitech-l - which one is best to ask questions of this nature?

I'd like to scratch my own itch rather than necessarily go after things on the todo list and roadmap.

Basically I'm interested in what parsoid can do for parsing wikitext markup into HTML (or other formats).

I want to use it without a mediawiki install and without an internet connection. I see there is already some kind of support for reading in articles from compressed dump files.

Any suggestions where I should start or where I can hang out to chat live with people who could help getting me involved?

Andrew Dunbar (hippietrail)

_______________________________________________
Wikitext-l mailing list
Wikitext-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitext-l
Permalink | Reply | 4 comments |
headers
C. Scott Ananian | 20 Feb 2013 00:52
Favicon

Size: Parsoid output vs Mediawiki markup

[Resending without the full list of articles, which caused the message to be bounced into moderation.]

Here are the results of a quick test I ran over the weekend, comparing a compressed excerpt from simple.wikipedia.org in mediawiki markup to the compressed parsoid representation of the same articles.  The list of articles is attached to this message. [Not any more.]

For the base case I used the processing pipeline for the OLPC's "Wikipedia activity", source code at github.com/cscott/wikiserver
It begins with a hand-written "portal page", then grabs all articles within two links of the portal page.  The original markup was taken from the simplewiki-20130112-pages-articles.xml dump.  Templates were then fully expanded, and just the selected articles were written.  Articles are separated by the character 0x01, a newline, the title of the article, a newline, the length of the article in bytes, a newline, and the character 0x02 and a newline.

For comparison, I took the list of articles included in the dump and wrote a small script to fetch them from parsoid, using the HEAD of the master branch from this weekend (2013-02-17, roughly).  I wrote the full parsoid HTML document (including top-level <html> tag, <head>, <base href>, and <body> but not including a <!DOCTYPE>) to a file, separating articles with the title of the article, a newline, the length of the article in bytes, and a newline.

Results, with and without compression:

# of articles: 3640
Mediawiki markup, uncompressed: 18M
Parsoid markup, uncompressed: 199M

Mediawiki markup, gzip -9 compressed: 6.4M
Parsoid markup, gzip -9 compressed: 26M

Mediawiki markup, bzip2 -9 compressed: 4.7M
Parsoid markup, bzip2 -9 compressed: 17M

Mediawiki markup, lzma -9 compressed: 4.4M
Parsoid markup, lzma -9 compressed: 15M

So there's currently a 10x expansion in the uncompressed size, but only 3-4x expansion with compression.
  --scott

--
                         ( http://cscott.net/ ) 

_______________________________________________
Wikitext-l mailing list
Wikitext-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitext-l
Permalink | Reply | 2 comments |
headers
C. Scott Ananian | 20 Feb 2013 00:50
Favicon

A grab bag of parsoid issues

For context: I've been working on replacing the html5 and jsdom modules (which depend on the native 'contextify' module) with the pure-javascript 'domino' implementation of DOM4.  This seems to be faster, cleaner, and fix some bug caused by jsdom's eccentric DOM handling.  Domino is (in my brief experience) more reliable and standards-compliant.


Here's a list of issues I came across in the process:

* There were 3 new failures in wt2html tests.  (There were also some new passes, so the number of correct tests increases on net.)  They are:

1) "expansion of multi-line templates in attribute values (bug 6255 sanity check 2)"
For reference, this test looks like:

!! test
Expansion of multi-line templates in attribute values (bug 6255 sanity check)
!! input
<div style="background:
#00FF00">-</div>
!! result
<div style="background: #00FF00">-</div>
!! end
!! test
Expansion of multi-line templates in attribute values (bug 6255 sanity check 2)
!! input
<div style="background: &#10;#00FF00">-</div>
!! result
<div style="background: &#10;#00FF00">-</div>
!! end

I'm not sure how this test ever passed in jsdom -- the inputs here are actually identical to an HTML parser, since hex-escape decoding happens very early.  But apparently the wikitext parser should defer processing of the &#10 somehow?  On the domino branch our HTML serialization now uses the upstream standard HTML5-serialization algorithm, which doesn't escape newlines.  (http://www.whatwg.org/specs/web-apps/current-work/multipage/the-end.html#serializing-html-fragments)  Note that the first test also involves whitespace normalization, which the PHP parser does (see https://www.mediawiki.org/wiki/Special:Code/MediaWiki/14689) but parsoid does not do.  (I've got a patch to do whitespace normalization in parsoid if there's interest, but it causes other tests to break.)

What's the plan to handle cases like this?  Is it really important to generate the &#10; in the output?

2) "Play a bit with r67090 and bug 3158"
This is a parsoid-only test which looks like:
!! test
Play a bit with r67090 and bug 3158
!! options
disabled
!! input
<div style="width:50% !important">&nbsp;</div>
<div style="width:50%&nbsp;!important">&nbsp;</div>
<div style="width:50%&#160;!important">&nbsp;</div>
<div style="border : solid;">&nbsp;</div>
!! result
<div style="width:50% !important">&nbsp;</div>
<div style="width:50% !important">&nbsp;</div>
<div style="width:50% !important">&nbsp;</div>
<div style="border&#160;: solid;">&nbsp;</div>
!! end

In standard HTML serialization, &#160; is encoded uniformly as &nbsp; so even if you wanted to be bug-compatible with the 'border :' style, you should be emitting a &nbsp; not a &#160; there.  The other two cases are whitespace normalization within attributes (again).  I'm guessing jsdom (incorrectly) did this by default whether you wanted it or not; you need to explicitly add attribute-normalization into the domino case if that's desired.  (But there's some other reason why the 'border :' case is failing now which needs to be chased down, unrelated to the &#160; vs &nbsp; issue.)

3) "Parsoid-only: Table with broken attribute value quoting on consecutive lines"
!! test
Parsoid-only: Table with broken attribute value quoting on consecutive lines
!! options
disabled
!! input
{|
| title="Hello world|Foo
| style="color:red|Bar
|}
!! result
<table>
<tr>
<td title="Hello world">Foo
</td><td style="color: red;">Bar
</td></tr></table>
!! end

jsdom used to insert the extraneous semicolon at the end of the 'style' attribute.  domino does not.  I believe this test case is broken and the extraneous semicolon should be removed.

* Other observed bugs & failures:
TypeError: Cannot assign to read only property 'ksrc' of #<KV>
    at AttributeExpander._returnAttributes (/home/cananian/Projects/OLPC/Narrative/mediawiki/Parsoid/js/lib/ext.core.AttributeExpander.js:71:20)
    at AttributeTransformManager.process (/home/cananian/Projects/OLPC/Narrative/mediawiki/Parsoid/js/lib/mediawiki.TokenTransformManager.js:1017:8)
    at AttributeExpander.onToken (/home/cananian/Projects/OLPC/Narrative/mediawiki/Parsoid/js/lib/ext.core.AttributeExpander.js:46:7)
    at AsyncTokenTransformManager.transformTokens (/home/cananian/Projects/OLPC/Narrative/mediawiki/Parsoid/js/lib/mediawiki.TokenTransformManager.js:568:17)
    at AsyncTokenTransformManager.onChunk (/home/cananian/Projects/OLPC/Narrative/mediawiki/Parsoid/js/lib/mediawiki.TokenTransformManager.js:356:17)
    at SyncTokenTransformManager.EventEmitter.emit (events.js:96:17)
    at SyncTokenTransformManager.onChunk (/home/cananian/Projects/OLPC/Narrative/mediawiki/Parsoid/js/lib/mediawiki.TokenTransformManager.js:904:7)
    at PegTokenizer.EventEmitter.emit (events.js:96:17)
    at PegTokenizer.process (/home/cananian/Projects/OLPC/Narrative/mediawiki/Parsoid/js/lib/mediawiki.tokenizer.peg.js:88:11)
    at ParserPipeline.process (/home/cananian/Projects/OLPC/Narrative/mediawiki/Parsoid/js/lib/mediawiki.parser.js:360:21)

starting parsing of Game
*********** ERROR: cs/s mismatch for node: A s: 3808; cs: 3821 ************
completed parsing of Game in 1491 ms

* [[File:]] tag parsing for images appears to be incomplete:
  a) alt= and class= are not parsed
  b) 'thumb' and 'right' should result in <img class="thumb tright" /> or some such, but there doesn't appear to be an indication of either option in the parsoid output.

* I'd like to see title and revision information in the <head>

* Interwiki links are not converted to relative links when the "interwiki" is actually the current wiki.  (Maybe this isn't really a bug.)

Let's discuss these a bit and I'll file bugzilla tickets for the bits we can agree are actually bugs. ;)
  --scott

--
                         ( http://cscott.net/ )
 

_______________________________________________
Wikitext-l mailing list
Wikitext-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitext-l
Permalink | Reply | 4 comments |
headers
Sumana Harihareswara | 16 Feb 2013 19:48
Picon
Gravatar

VisualEditor update

Earlier this month, the Visual Editor team gave an update on their
progress and their goals for 2013.  Check it out:

https://meta.wikimedia.org/wiki/File:VisualEditor-Parsoid_-_2013-02_Metrics_deck.pdf

https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/2013-02-07
has the video on Commons & YouTube.  Significantly: the Visual Editor
*should* be able to work in Internet Explorer and to handle core basic
templates, such as {{cite web}}, by 1 July 2013.
--

-- 
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation

_______________________________________________
Wikitext-l mailing list
Wikitext-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitext-l
Permalink | Reply | 2 comments |
headers
- - | 29 Jan 2013 10:08
Favicon
Gravatar

Re: No response to VisualEditor from Parsoid

Hi Inez, hi Subbu

That's it!
I didn't know about prefix as I could not find anything about that variable at
http://www.mediawiki.org/wiki/Parsoid. Maybe you should add that to the page.

But that alone didn't help! The thing that made it work was "$wgGroupPermissions['*']['read'] = false;" I
had it on FALSE and when I changed it to TRUE, everything worked! Splendid, thank you.

Will it be possible to use Parsoid in the future with the variable being FALSE?

Stadtpirat!

> 
> Message: 2
> Date: Fri, 25 Jan 2013 11:39:49 -0800
> From: Subramanya Sastry <ssastry <at> wikimedia.org>
> To: wikitext-l <at> lists.wikimedia.org
> Subject: Re: [Wikitext-l] No response to VisualEditor from Parsoid
> Message-ID: <5102DF85.7030002 <at> wikimedia.org>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> 
> In addition to what Inez suggested, another place to check based on
> #mediawiki-parsoid discussion about this report.   -Subbu.
> 
> ...
> <RoanKattouw> Does he have $wgGroupPermissions['*']['read'] === false
> perhaps?
> <marktraceur> Hm, that might be it
> <RoanKattouw> Does he have a current version of MW?
> <marktraceur> RoanKattouw: The permissions thing is exactly right
> <marktraceur> RoanKattouw: I didn't ask about the version
> <RoanKattouw> The perms thing will do it
> ...
> <RoanKattouw> The API refuses to do pretty much everything if you're
> logged out and have denied anons read rights
> <RoanKattouw> Actually, I'm pretty sure the only modules available in
> that case are help and login :)
> ...
> 
>> Hi,
>>
>> In your localsettings.js (for Parsoid) you should have
>> "parsoidConfig.setInterwiki( 'skwiki', 'http://skwiki'; );" instead of
>> what you have now.
>>
>> Also try setting $wgVisualEditorParsoidURL = 'http://skwiki:8000'; and
>> $wgVisualEditorParsoidPrefix = 'skwiki' (make sure that nothing is
>> overwritten in extensions/VisualEditor/VisualEditor.php).
>>
>> Inez
>>
>> On Fri, Jan 25, 2013 at 3:25 AM, - - <stadtpirat11 <at> ymail.com> wrote:
>>>
>>> Hi,
>>>
>>> I just asked this in IRC, but in case I need to go before I get a reply, I will ask you here:
>>>
>>> This really starts to bug me! I have no idea why Parsoid (and the VisualEditor) is not working! My wiki is
working and the address is http://skwiki/w/Hauptseite ("Main_Page" is "Hauptseite" in German). I see
the api page when I go to http://skwiki/api.php and I see the Parsoid page when I go to http://skwiki:8000.
But I get errors when I click the VisualEditor link on http://skwiki/w/VisualEditor:Sandbox (no response).
>>>
>>> - The wiki is located at /usr/local/var/www/mediawiki/.
>>> - The webserver is configured to have the docroot for http://skwiki at /usr/local/var/www/mediawiki/
>>> - It also internally rewrites "/w/(.+)" to "index.php?title=$1"
>>> - /usr/local/var/www/mediawiki/extensions/Parsoid/js/api/localsettings.php is http://pastebin.com/BhB07BKY
>>> - /usr/local/var/www/mediawiki/LocalSettings.php is http://pastebin.com/Y1wLnwiL
>>>
>>> When I click the WYSIWYG-button at http://skwiki/w/VisualEditor:Sandbox, I get the following
response in the web browser
>>>
>>>> {"error":{"code":"parsoidserver","info":"Error contacting the Parsoid server"}}
>>> and node js throws an error:
>>>
>>>> /usr/local/var/www/mediawiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:25
>>>>          var nkeys = Object.keys( names );
>>>>                             ^
>>>> TypeError: Object.keys called on non-object
>>>>      at Function.keys (native)
>>>>      at Object.WikiConfig (/usr/local/var/www/mediawiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:25:21)
>>>>      at MWParserEnvironment.switchToConfig (/usr/local/var/www/mediawiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:215:21)
>>>>      at ApiRequest.processListeners.processSome (/usr/local/var/www/mediawiki/extensions/Parsoid/js/lib/mediawiki.ApiRequest.js:53:4)
>>>>      at process.startup.processNextTick.process._tickCallback (node.js:244:9)
>>> I really would like to get this working!
>>>
>>> Thanks,
>>>
>>> Stadtpirat
>>>
>>> ---------- Forwarded message ----------
>>> From: - - <stadtpirat11 <at> ymail.com>
>>> To: "wikitext-l <at> lists.wikimedia.org" <wikitext-l <at> lists.wikimedia.org>
>>> Cc:
>>> Date: Fri, 25 Jan 2013 03:06:21 -0800 (PST)
>>> Subject: WG: No response to VisualEditor from Parsoid
>>> Hi,
>>>
>>>
>>> I just asked this in IRC, but in case I need to go before I get a reply, I will ask you here:
>>>
>>> This really starts to bug me! I have no idea why Parsoid (and the VisualEditor) is not working! My wiki is
working and the address is http://skwiki/w/Hauptseite ("Main_Page" is "Hauptseite" in German). I see
the api page when I go to http://skwiki/api.php and I see the Parsoid page when I go to http://skwiki:8000.
But I get errors when I click the VisualEditor link on http://skwiki/w/VisualEditor:Sandbox (no response).
>>>
>>> - The wiki is located at /usr/local/var/www/mediawiki/.
>>> - The webserver is configured to have the docroot for http://skwiki at /usr/local/var/www/mediawiki/
>>> - It also internally rewrites "/w/(.+)" to "index.php?title=$1"
>>> - /usr/local/var/www/mediawiki/extensions/Parsoid/js/api/localsettings.php is http://pastebin.com/BhB07BKY
>>> - /usr/local/var/www/mediawiki/LocalSettings.php is http://pastebin.com/Y1wLnwiL
>>>
>>> When I click the WYSIWYG-button at http://skwiki/w/VisualEditor:Sandbox, I get the following
response in the web browser
>>>
>>>> {"error":{"code":"parsoidserver","info":"Error contacting the Parsoid server"}}
>>> and node js throws an error:
>>>
>>>> /usr/local/var/www/mediawiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:25
>>>>          var nkeys = Object.keys( names );
>>>>                             ^
>>>> TypeError: Object.keys called on non-object
>>>>      at Function.keys (native)
>>>>      at Object.WikiConfig (/usr/local/var/www/mediawiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:25:21)
>>>>      at MWParserEnvironment.switchToConfig (/usr/local/var/www/mediawiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:215:21)
>>>>      at ApiRequest.processListeners.processSome (/usr/local/var/www/mediawiki/extensions/Parsoid/js/lib/mediawiki.ApiRequest.js:53:4)
>>>>      at process.startup.processNextTick.process._tickCallback (node.js:244:9)
>>> I really would like to get this working!
>>>
>>> Thanks,
>>>
>>>
>>> Stadtpirat
Permalink | Reply | 3 comments |
headers
- - | 25 Jan 2013 12:25
Favicon
Gravatar

No response to VisualEditor from Parsoid


Hi,

I just asked this in IRC, but in case I need to go before I get a reply, I will ask you here:

This really starts to bug me! I have no idea why Parsoid (and the VisualEditor) is not working! My wiki is
working and the address is http://skwiki/w/Hauptseite ("Main_Page" is "Hauptseite" in German). I see
the api page when I go to http://skwiki/api.php and I see the Parsoid page when I go to http://skwiki:8000.
But I get errors when I click the VisualEditor link on http://skwiki/w/VisualEditor:Sandbox (no response).

- The wiki is located at /usr/local/var/www/mediawiki/.
- The webserver is configured to have the docroot for http://skwiki at /usr/local/var/www/mediawiki/
- It also internally rewrites "/w/(.+)" to "index.php?title=$1"
- /usr/local/var/www/mediawiki/extensions/Parsoid/js/api/localsettings.php is http://pastebin.com/BhB07BKY
- /usr/local/var/www/mediawiki/LocalSettings.php is http://pastebin.com/Y1wLnwiL

When I click the WYSIWYG-button at http://skwiki/w/VisualEditor:Sandbox, I get the following response
in the web browser

> {"error":{"code":"parsoidserver","info":"Error contacting the Parsoid server"}}

and node js throws an error:

> /usr/local/var/www/mediawiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:25
>         var nkeys = Object.keys( names );
>                            ^
> TypeError: Object.keys called on non-object
>     at Function.keys (native)
>     at Object.WikiConfig (/usr/local/var/www/mediawiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:25:21)
>     at MWParserEnvironment.switchToConfig (/usr/local/var/www/mediawiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:215:21)
>     at ApiRequest.processListeners.processSome (/usr/local/var/www/mediawiki/extensions/Parsoid/js/lib/mediawiki.ApiRequest.js:53:4)
>     at process.startup.processNextTick.process._tickCallback (node.js:244:9)

I really would like to get this working!

Thanks,

Stadtpirat
Favicon Gravatar
From: - - <stadtpirat11 <at> ymail.com>
Subject: WG: No response to VisualEditor from Parsoid
Date: 2013-01-25 11:06:21 GMT
Hi,

I just asked this in IRC, but in case I need to go before I get a reply, I will ask you here:

This really starts to bug me! I have no idea why Parsoid (and the VisualEditor) is not working! My wiki is
working and the address is http://skwiki/w/Hauptseite ("Main_Page" is "Hauptseite" in German). I see
the api page when I go to http://skwiki/api.php and I see the Parsoid page when I go to http://skwiki:8000.
But I get errors when I click the VisualEditor link on http://skwiki/w/VisualEditor:Sandbox (no response).

- The wiki is located at /usr/local/var/www/mediawiki/.
- The webserver is configured to have the docroot for http://skwiki at /usr/local/var/www/mediawiki/
- It also internally rewrites "/w/(.+)" to "index.php?title=$1"
- /usr/local/var/www/mediawiki/extensions/Parsoid/js/api/localsettings.php is http://pastebin.com/BhB07BKY
- /usr/local/var/www/mediawiki/LocalSettings.php is http://pastebin.com/Y1wLnwiL

When I click the WYSIWYG-button at http://skwiki/w/VisualEditor:Sandbox, I get the following response
in the web browser

> {"error":{"code":"parsoidserver","info":"Error contacting the Parsoid server"}}

and node js throws an error:

> /usr/local/var/www/mediawiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:25
>         var nkeys = Object.keys( names );
>                            ^
> TypeError: Object.keys called on non-object
>     at Function.keys (native)
>     at Object.WikiConfig (/usr/local/var/www/mediawiki/extensions/Parsoid/js/lib/mediawiki.WikiConfig.js:25:21)
>     at MWParserEnvironment.switchToConfig (/usr/local/var/www/mediawiki/extensions/Parsoid/js/lib/mediawiki.parser.environment.js:215:21)
>     at ApiRequest.processListeners.processSome (/usr/local/var/www/mediawiki/extensions/Parsoid/js/lib/mediawiki.ApiRequest.js:53:4)
>     at process.startup.processNextTick.process._tickCallback (node.js:244:9)

I really would like to get this working!

Thanks,

Stadtpirat


_______________________________________________
Wikitext-l mailing list
Wikitext-l <at> lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitext-l
Permalink | Reply | 2 comments |
headers
Sumana Harihareswara | 19 Nov 2012 19:02
Picon
Gravatar

Anyone want to give a talk to London Lua?

http://www.londonlua.org/

I emailed a bit with Justin from London Lua and he expressed interest in
having a Wikimedian present, either in person or remotely, about what
Wikimedia's going to be doing with Lua.  There is already the video tutorial

https://commons.wikimedia.org/wiki/File:Berlin_Hackathon_2012_-_Lua_introduction_%28Tim_Starling%29.ogv

and the written tutorial

https://www.mediawiki.org/wiki/Lua_scripting/Tutorial

in case you want materials to use.  And if it would take a little money
for you to get to London, the Wikimedia Foundation might be able to
reimburse travel expenses:
https://meta.wikimedia.org/wiki/Participation:Support
--

-- 
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
Permalink | Reply | 0 comments |
headers
Daniel Kinzler | 8 Oct 2012 21:02
Picon
Favicon
Gravatar

Re: [Wikitech-l] Merging the ContentHandler into master

On 08.10.2012 19:12, Siebrand Mazeland (WMF) wrote:
> On Mon, Oct 8, 2012 at 6:33 PM, Daniel Kinzler <daniel <at> brightbyte.de> wrote:
>> As discussed last week with Rob, I have no prepared a merge request that
>> introduces the ContentHandler into MediaWiki core. This is a major building
>> block for the Wikidata project. I hope the merge will be completed soon, since
>> this will grow stale fast.

I would like to add a heads up:

This change deprecates some heavily used core functions and hooks, like
Revision::getText() and the ArticleSaveComplete hook. They are replaced with
equivalent functions that use Content objects instead of text. This means that a
lot of extensions will generate warnings and thus fail tests as soon as this is
in core. Once it is merged, we can start fixing these problems.

-- daniel

PS: The deployment target for this is, as far as i know, 1.21wmf2. Please check
with RobLa.
Permalink | Reply | 1 comment |

Gmane