anselmdk
commented
8 years ago Hey Shea,
happy you like the module!
In order to get development on this module going, I started out going with my own practices, but I do realise that people have very different ways of doing things, and I realise that forcing SilverStripe files to have to live inside of the public directory, might be a deal breaker for many, so I'm all in for making this configurable. I think I even talked to @leomeloxp about it at StripeCon last year. My friend @zauberfisch is another full hearted hater of my practice of using the public directory.
A little reasoning why I'm doing like I'm doing
I see a git repository as a self documented entity, preferably containing as much as possible about a project, including documentation, server configuration, etc.
As terminal tools is checking the entire git repository out on the server, I don't want all of this to be accessible from the web root, which is why I'm having SilverStripe specific files inside of a sub directory, which I call public.
Below is an example of how the directory structure for a project could look like. There I'm also keeping uncompiled JavaScript and Scss files (resources) as well as node_modules out of the web root.
Making the web root directory configurable
It shouldn't be too hard making the root directory configurable. A quick search in affected modules shows this:
- https://github.com/titledk/ttools-silverstripe/search?utf8=✓&q=public
- https://github.com/titledk/ttools-sitesync-silverstripe/search?utf8=✓&q=public
As to how to go about the configuration I propose to add an optional Webroot configuration, which could be similar to how Sitesync is used here: https://github.com/titledk/ttools-silverstripe/blob/master/install/install-ttools.sh#L92
I'd say that by default it would be public/, (Webroot: public/) but could be anything else, also /.
I'm not too happy about using / (root) as that way the ttools directory would be installed inside of the web root, and the ttools/config.yml could be accessed from the web, but there are ways around it by just protecting that directory via .htaccess. (I need ttools to also be available on the server for for syncing purposes.)
vars.sh from core would just read that configuration out, and it should be accessible as a variable in the global scope (just like $Sitesync_FrameworkModule is here: https://github.com/titledk/ttools-sitesync-core/blob/495bac886c2e55baf2022877787bdd166891470d/lib/dump-current-site.sh#L67).
vars-for-env.sh contains some hints on how to deal with default values. I'd love a refactor/simplification of the configuration system, but we'll take that another day :)
sheadawson
Hey this module seems great. I recently wrote a bash deployment script which I've been using but yours is much more extensive with all the migration stuff. Really cool.
I'm keen to give it a go but am a bit put off by having to have the site in a public subfolder as this means I can't just drop it in to my existing way of doing things. Just wondering why it's set up like that? And how possible (or not) would it be to make the subfolder an optional/configurable option?