Ai, that's a setback. Somehow thought that the cms was 'just another module', I would have thought that what goes for the cms... Guess I thought wrong :-(
We've moved the forum!
Please use forum.silverstripe.org for any new questions
(announcement).
The forum archive will stick around, but will be read only.
You can also use our Slack channel
or StackOverflow to ask for help.
Check out our community overview for more options to contribute.
Truth be told, I haven't done much testing, but I think I remember getting to a head-scratching point where I realized there was no way it was going to work. :-)
But if you get anywhere, please let me know!
I thought to try right away :-) Using 2.3.2. Started with a 'ssmodules' folder outside the docroot, with no OpenBaseDir restrictions in effect.
First I tried the newsletter module that I had already installed: I removed it from my docroot, and created a symlink tot the ssmodules/newsletter folder in its place. Something like:
ln -s ../../ssmodules/newsletter/ newsletter
I found no obvious problems, even after dev/build/?flush=1. So I then tried with some random module (flickrservice in this case), and was perfectly able to install and create a page the same way. So it must be working.
Didn't test all the other issues with GD and stuff yet as I guess this is beside the point here... But it seems to be quite possible now :-)
[EDIT - eh... changed the code, copied the wrong line :-(, anyway: works!]
Hi guys,
I haven't set up any symlink-based configurations myself, but cms should be treated as "just another module", so if the solution works for CMS it should work for others.
If you're debugging this, there's a pretty critical define, and that's BASE_PATH. It's set to the directory above your sapphire directory. If you're having trouble with some issue, it might be worth seeing what that is set to.
It's set in sapphire/core/Core.php line ~96
Without (yet) having done really extensive testing I can confirm that the image_gallery (with dataobject_manager and swfupload installed as well) does work with symlinks. Also (seemingly) working are embargoexpiry, blog and newsletter.
As for all of these, were having some issues, but we think that is more related to us trying (needing) to use multiple languages (generating errors like "I can't handle sub-URLs of a..."). For these issues there are allready a couple of tickets and I hope that it's resolved asap as all our pages have at least two or three languages (Swedish, Finnish and English most of the time).
Sam: thanks for pointing us to the file that contains all (?) important defined variables!
Cheers,
Tim
This is great stuff, thank you.
I have successfully been adding modules to SS installations on a shared host by running php symlink() - so far via a cron job but with a view to writing a php SS deployment app.
Not having so much success using links for the CMS (v2.3.2) itself though :(
Install runs okay until it checks for friendly URLs and fails. If I unlink sapphire and copy the sapphire directory to the web root it works so there's something about that directory, could this be related to Sam's comment about BASE_PATH?
This has been repeated on my local dev server so it's not directly related to the shared host.
If I delete the sapphire directory after installation and link it back to the files above web root I get redirected to install.php when I try to access the site. main.php does this when it thinks no database is set, so why not?
Any ideas?
Cheers,
Rich
That happens when SS either can't find or can't read the database info in your _config.php file.
True and you've given me an idea...
From what I can see, that happens when SS can't connect to the database, this is probably happening because I am using _ss_environment.php to store mysql server location and user credentials (which is one level above the web root), if I move this info to _config.php then all works wonderfully.
I'm guessing that SS is looking for this file above the sapphire directory (which is two levels above the web root) and of course it's not there and _config.php does not contain the database login and password.
So, for now I have a work-around but I've got some work to do if I want site-specific database user credentials kept out of the web root.
Cheers,
Rich