GWicke

Previous page history was archived for backup purposes at User talk:GWicke/oldUserPage/LQT Archive 1 on 2015-07-10.

In light of the roadmap and the work you're doing, should Requests for comment/Page metadata be closed as an issue that's been decided, or are there still some metadata topics we should invite the community to discuss?

As a first step, we intend to separate page properties from content in HTML DOM. This requires little discussion with the wider community, as users don't normally interact with HTML directly. For wikitext users, nothing will change for now.

Removing page properties from the wikitext however will definitely require discussions. In templates, I expect them to stay as long as wikitext does. In the page itself we'll still need very good UIs for diffing and editing of these properties. We plan to work on diffing, and a page property edit UI is being developed as part of the VisualEditor. Right now this is still fairly far out though, so it is difficult to discuss specifics.

I think it makes most sense to just do the work that can make this an option. Once at least prototypes of the user experience are available we should be able to discuss specific options without too much hand waving.

Hi GW. Hope that the world is looking somewhat rosier. You know that I am not the most competent in coding, and I am looking to know if there is a convenient means to convert json from the RESTbase / PageView API into viewable webpages for the wikis. Is there some little interpreter or something that can help the clueless administrator to bring good data to viewing on wiki to share with fellow clueless coders? Thanks for any direction that you can give? Thanks.

Thanks to everyone who’s helped work on the Code of Conduct so far.

People have brought up issues they feel were missed when working on "Unacceptable behavior" and "Report a problem". Consultants have also suggested changes in these same sections.

These are important sections, so please take a look at the proposed changes. I apologize that this feedback arrived later than planned, but I think this will create a better document.

If you prefer to give your opinion privately, feedback via e-mail is welcome at conduct-discussionwikimedia.org.

Thanks. Mattflaschen-WMF via

Hi, Requests for comment/Allow styling in templates is being considered as one of the RFCs to be discussed at the RFC review on 2013-11-06 via IRC. You are receiving this notification because you edited or discussed this RFC. We hope to see you there.

This post was posted by Qgil-WMF, but signed as Qgil.

First I must says that TAssembly looks like a fantastic piece of work.

I don't follow however the code very well and so I was wondering how it limits the variable use to the model ones and refuse for example window global object. After looking more on the code it looks like the key function is rewriteExpression which prepend all access with c. (except when it is not a global member) I am right ?

I posted a question about Mathoid at Talk:Wikimedia Engineering/2014-15 Goals. Would you be able to answer there? Thanks in advance.

Just replied there. Thanks for letting me know!

Thanks for the prompt response!

Hallo Gabriel, unser nächster Stammtisch wird am 11. März im Walzwerk (Mission) stattfinden. Für die An- bzw. Abmeldung steht seit gestern die Seite Wikipedia:San Francisco zur Verfügung. Freue mich schon auf ein Wiedersehen :-) P.S. Bitte trag dich auch ein, wenn dir ein anderer Termin besser passen würde.

Danke, hab mich eingetragen. Bis dann!

Hi,

regarding your change http://www.mediawiki.org/w/index.php?title=Parsoid/Troubleshooting&diff=0&oldid=797441 :

I think, my text (which you now have deleted) talking about the password-protected wiki is still relevant, because the Parsoid needs to know the password (this is my current thinking; I haven't tried it yet for my wikis). So, if there is a problem with the password, Parsoid and the Visiual Editor will not work.

And this should be mentioned as one of the possibilities on the Troubleshooting page.

Currently parsoid just forwards the cookie header (if set) to the wiki. If you are using VisualEditor, see the relevant configuration options for cookie forwarding in the VE extension.

Thanks.

I changed the text on that page, but can you please adapt it a second time, so that it then will probably be perfect?

I made it clear that no change on the Parsoid side is needed. All that is needed is to configure the VE extension properly.

Gabriel, I think, this change of Parsoid is really a big step forward. As soon as I have the time, I will try to deploy the latest version to all my protected wikis, some of them are using AuthPlugin in a Kerberos-authenticated intranet - where the VE/Parsoid currently could not be used.

I will report later, if it really works (I am confident, it will...)

-))

Great that it makes Parsoid more useful to you ;) In the foundation people were very happy when VE was enabled on a few internal wikis.

Note that when a cookie is set, we are sending no-cache headers for security reasons. In production most Parsoid output comes from the Parsoid Varnish caches, but private wikis are forced to be re-rendered for each request. Eventually we'll store HTML and do the access right checks at that layer. At that point private wikis will be fast too.

Hi,

I'm stucked on this problem. I installed Parsoid on my distant server (node.js 0.10.15) from gandi.net, but when i start my server, workers loads and when they are ready, they report this error (for all):

events.js:72
       throw er; // Unhandled 'error' event
             ^
Error: bind EADDRINUSE
   at errnoException (net.js:901:11)
   at net.js:1073:26
   at Object.1:1 (cluster.js:587:5)
   at handleResponse (cluster.js:171:41)
   at respond (cluster.js:192:5)
   at handleMessage (cluster.js:202:5)
   at process.EventEmitter.emit (events.js:117:20)
   at handleMessage (child_process.js:318:10)
   at child_process.js:392:7
   at process.handleConversion.net.Native.got (child_process.js:91:7)
worker 867 died (8), restarting.
- worker(912) ready

Thanks for followed answers.

Some other service is using port 8000. This could be another Parsoid instance, or an unrelated service.

You can either stop that service, or change Parsoid's port by setting the VCAP_APP_PORT environment variable:

VCAP_APP_PORT=9000 node server.js

On gandi, i have a default server.js already using port 8080 (i set my parsoid server to 8080). So that's probably this. But gandi's server allow me access only on port 8080. I can't force ports usage.

On gandi's server, i have default directory, it's my root. In it, i have server.js by default. That server.js is ran automatically. VisualEditor catch this front-page's text and, when i save in VE, this text is saved in anyway.

I haven't rights before this directory, so how can i run my parsoid instance from this root ? Sorry for imperfections in my english.

You will need a free port to use by Parsoid. If your wiki is running on the same box, then that port does not even need to be accessible from the outside. If you can reach http://localhost:8000/ (assuming default port) from the wiki box, then you will be fine.

Just Log out completly and then try again... It works for me

Hi!

Is it ok to change http://mediawiki.org/rdf/ to https://mediawiki.org/rdf/ on Parsoid/MediaWiki DOM spec?

That should be fine, but we should also adjust the code to match at the same time.