Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SilverStripe files in "Public" directory #4

Open
sheadawson opened this issue May 4, 2016 · 3 comments
Open

SilverStripe files in "Public" directory #4

sheadawson opened this issue May 4, 2016 · 3 comments

Comments

@sheadawson
Copy link

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?

@anselmdk
Copy link
Member

anselmdk commented May 4, 2016

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.

screenshot 2016-05-04 16 53 31

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:

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 :)

@anselmdk
Copy link
Member

anselmdk commented Jun 8, 2016

@sheadawson I've just added the labels enhancement & help wanted. I think this would be a great feature, but it's just nothing I need in my day-to-day work.

@sheadawson
Copy link
Author

Nice one @anselmdk and thanks for the explanation. If I find some time I'll definitely be keen to contribute

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants