Folder structure for auto site setups is inflexible

[iandunn]

In the Meta Environment, we've run into an issue where users have to clone the repo to a specific folder name in order for provisioning to work.

We have a folder structure like:

{vvv_root}/wordpress-meta-environment/wordcamp.dev/logs
{vvv_root}/wordpress-meta-environment/wordcamp.dev/provision
{vvv_root}/wordpress-meta-environment/wordcamp.dev/public_html

That keeps things clean and organized, but it prevents us from using {vvv_path_to_folder} in our Nginx conf files, because the resulting path would be

/srv/www/wordpress-meta-environment/wordcamp.dev/provision/
instead of
/srv/www/wordpress-meta-environment/wordcamp.dev/

So we've just hardcoded /srv/www/wordpress-meta-environment for now. That works if the user clones the directory with that name, but it breaks if they choose a custom folder name.

There are two approaches I can think of to improve the situation for all auto-site-setups:

1. Provide a way for auto-site-setups to customize the replacement value of vvv_path_to_folder.

2. Provide a way for auto-site-setups to hook into provision-post.sh.

I'm thinking that there'd be a default /provision/provision-post.sh file that would find /srv/www -maxdepth 5 -name 'provision-post.sh', and source the results.

This seems like it might be the better approach, because it would allow for a lot of other customization as well, beyond just this situation.

With something like this in place, we could just setup out own {wme_path_to_folder} placeholders and do our own sed replace in our child provision-post.sh.

There'd be some back-compat issues, though, since some users will have already created their own provision-post.sh files (#48).

Any thoughts on the above approaches, or better ideas?

[jeremyfelt]

This should now all be possible after the merge of #980. Sorry for never leaving feedback, @iandunn!

[iandunn]

No worries, thanks the merge, and kudos to @LoreleiAurora for the awesome work in #980 :)

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.