Page MenuHomePhabricator

Install VisualEditor and Citoid on Wikispore
Closed, ResolvedPublic

Event Timeline

Tgr added a comment.Nov 9 2019, 6:14 PM

The first attempt at this failed: wikispore-test has VE but existing content is not preserved (probably RESTBase is broken).
Vagrant seems to be in the middle of a Node migration (for some value of migration: some roles refuse to work without Node 10, some are still on Node 6; cf. T217113: MediaWiki-Vagrant should use the same Node.js version as Wikimedia production) which is probably one of the issues (maybe *the* issue).

Mvolz added a subscriber: Mvolz.Jan 10 2020, 3:23 AM

Just an FYI but although the VE vagrant role ideally should work, the citoid role has been broken for a while, see: T153214. If at all possible I recommend setting $wgCitoidFullRestbaseURL to https://en.wikipedia.org/api/rest_ as per https://www.mediawiki.org/wiki/Citoid#Citoid_extension in your LocalSettings.php

This will hopefully enable you to use citoid without having to run your own instance of it, although let me know if it doesn't work either because I have a slightly greater chance of fixing that than the vagrant role itself.

Tgr added a comment.Jan 11 2020, 9:07 AM

All node-based roles are very broken in vagrant right now, due to T217113: MediaWiki-Vagrant should use the same Node.js version as Wikimedia production and T164126: Rotate MediaWiki-Vagrant log files to prevent logs from eating up all disk space (the latter breaks the whole box in a hard-to-recover way; that's why wikispore-test is down right now). So this is blocked on either those or T239660: Integrate Parsoid/PHP with core as a composer library (which the Parsing team is planning to do soonish, not sure about the exact schedule).

Pharos added a subscriber: Pharos.Jan 11 2020, 2:44 PM

Is this viable now that T239660 is resolved?

Tgr added a comment.Jul 21 2020, 2:20 PM

I hope so. AIUI Parsoid got merged into core and the Parsoid configuration for a simple (non-RESTBase) setup got merged into VisualEditor, so after installing those two things should just work.

Tgr moved this task from Backlog to Next-up on the Wikispore board.Aug 10 2020, 6:27 PM
Tgr added a comment.Aug 10 2020, 8:05 PM

On wikispore-test.

Tgr added a comment.Aug 10 2020, 8:11 PM

VisualEditor uses $wgContentNamespaces to determine where it should be enabled but SpecialNamespaces does not set that. That should be fixed.

Tgr added a comment.Aug 22 2020, 5:17 PM

Task is mostly done, except for the $wgContentNamespaces issue. Not sure how to go about that, the namespace list is managed by the SpecialNamespaces extension, and there doesn't seem to be any straightforward way for it to define the value of a global. It sets a bunch of namespace-related globals from the CanonicalNamespaces hook, but that doesn't seem to work for content namespaces.

Tgr closed this task as Resolved.Aug 22 2020, 11:21 PM
Tgr claimed this task.
Tgr moved this task from Next-up to Done on the Wikispore board.
Zblace added a subscriber: Zblace.Sep 30 2020, 7:56 AM

If we would be to move content from namespaces of individual spores into Main space - would that be solution (and default setup)?

Tgr added a comment.Sep 30 2020, 8:12 PM

Not using namespaces would solve the problem we now have with namespaces, sure. It would make the spores hard to manage, though; that's why we wanted namespaces in the first place.

Zblace added a comment.Oct 1 2020, 5:53 AM

Hm...OK - I am starting to understand the problem.

Where was the discussion about what was the problem that was to be resolved by using namespaces?

Are we assuming that separation and distinction (via namespaces) among spores is essential from start?
I do not see how this is very important for current state of affairs and very near future...

Maybe this is something that can be resolved later on case-by-case basis where different spores have different needs, that might lead in direction or running more than one instance of MediaWiki?