- Mentioned In
- T231911: Basic configuration for Wikispore
- Mentioned Here
- T164126: Rotate MediaWiki-Vagrant log files to prevent logs from eating up all disk space
T239660: Integrate Parsoid/PHP with core as a composer library
T153214: Citoid restbase endpoint not configured correctly in vagrant
T217113: MediaWiki-Vagrant should use the same Node.js version as Wikimedia production
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).
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.
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).
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.
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.
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?