Last modified: 2014-08-20 23:54:54 UTC
I hit this because Parsoid.php (https://git.wikimedia.org/tree/mediawiki%2Fextensions%2FParsoid.git) is a symbolic link. However, in MediaWiki-Vagrant, it's just a text file with the text of its destination. This is because core.symlinks is returning false. However, if I'm reading 'git help config' right, that's probably just a symptom of the system not supporting symlinks at clone-time. I can work around this, but it would be good to support this if possible, to make it more like a typical Ubuntu system.
(In reply to Matthew Flaschen from comment #0) > This is because core.symlinks is returning false. However, if I'm reading > 'git help config' right, that's probably just a symptom of the system not > supporting symlinks at clone-time. > > I can work around this, but it would be good to support this if possible, to > make it more like a typical Ubuntu system. Was this on a Windows host computer? The only reason I can think of for symlinks not to be supported would be if the underlying file system didn't support them. In our current configuration, parsoid is cloned on the VMs filesystem which is ext4 and obviously supports symlinks which sort of nullifies my thesis.
I was fixated on the Parsoid service, not the extension even though Matt linked to the extension code. Back to blaming this on the host filesystem. We can (and should) work around the symlink by specifying the entry point for the Parsoid extension as the php/Parsoid.php file.
Hmm, I still saw it on my current checkout. But when I deleted the Parsoid extension and re-provisioned, it fixed itself (the symbolic link is there). Thus, closing as WORKSFORME. It's possible it still doesn't work on VirtualBox shared folders-on-Linux-host (but not confirmed), and I don't think that's a major use case. The host is Debian, and the filesystem is ext4. I believe I originally filed this for my own checkout (not on behalf of someone else), which means it was also Linux then. However, it may have been VirtualBox shared folders, rather than NFS (as I currently use). (In reply to Bryan Davis from comment #2) > I was fixated on the Parsoid service, not the extension even though Matt > linked to the extension code. Back to blaming this on the host filesystem. > We can (and should) work around the symlink by specifying the entry point > for the Parsoid extension as the php/Parsoid.php file. I did that earlier. IIRC that was what I meant by working around it.
Looks like we already deal with this scenario in the current mediawiki::parsoid manifest: mediawiki::extension { 'Parsoid': entrypoint => 'php/Parsoid.php', settings => { wgParsoidCacheServers => [], }, }
