Use /var/www/html as docroot, rename docroot to drupal

[mbarcia]

The intended 'docroot' for Ubuntu Trusty is now /var/www/html (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=730372), and that should be the shared folder. Drupal (7 or 8) installs under /var/www/site/docroot, which should be then renamed to /var/www/html/drupal. The same applies to CentOS 6.6, as per the page above.

For Ubuntu Precise, the actual apache document root and shared folder should be /var/www, also renaming docroot to drupal.

[mbarcia]

PR #187 is up.

[philipnorton42]

I'm not sure about this change. It's a massive breaking change to cater for the default location of the Apache webroot, which assumes that we will always use Apache as the web server. The default location for nginx is '/var/www/nginx-default' but it certainly doesn't make sense to use that location.

Not only this but we do the following actions as well: 1) Automatically move the user to the correct location when they ssh onto the box. 2) Install other applications in a higher directory level. So things like Adminer and PimpMyLog get put next to the '/var/www/site' directory so that they are separate to the Drupal sites but still in a coherent place.

I can see why you would want to change the location on a live site, but this is a dev box. I've always said that there are certain things inside Vlad that are really bad for production environments and this might be one of them.

Essentially, I'm going to need more evidence/opinions that this is the best move. I'll leave it open for now to gain other people's opinion on this.

:-1:

[mbarcia]

Hello Philip,

Allow me some background first, then onto your points:

I totally understand your hesitations, as I think this belongs to that kind of issues which carry a lot of work behind the scenes and, at the same time, don't look very useful at first sight. Yeah :-)

But let me develop the idea: the first motivation for this was that the latest dev broke the samba role (and I don't even remember how, but it somehow did). This prompted me to dig further and I recalled when I first approached Vlad (and Ansible) and things were not so sweet. One example, when vagrant up wouldn't finish, and things like that. Having a somewhat obscure folder like "/var/www/site/docroot" didn't help. If it were /var/www/html, it would leave no doubt about its purpose.

Also, there is a use case not being covered. I'm synchronizing a whole Eclipse workspace into /var/www/site/docroot (which is the folder being shared). Currently, I'm forced to have app folders inside docroot, which doesn't make sense.

So that is the main driver: more standard structure and added flexibility on the shared folder.

Continuing onto your points: 1) Automatically move the user to the correct location when they ssh onto the box. what would be "the correct location"? With the PR, user is taken to /var/www/html after vagrant ssh.

2) Install other applications in a higher directory level. So things like Adminer and PimpMyLog get put next to the '/var/www/site' directory so that they are separate to the Drupal sites but still in a coherent place. Having adminer and all the other apps install on a different folder just doesn't look very useful to me. They are just a handful of well known apps. That's why in the PR all apps (including drupal) are at the same level, under /var/www/html.

3) certain things inside Vlad that are really bad for production environments This is a very interesting point. IMO, the goal is simple: the closer to prod the better. Getting there is not, I know.

So, in favor of this change I can mention:

1. Although massive, the logic behind it is simple
2. I like the resulting scenario better
3. standard folder structure
4. shared folder that can be used for multiple projects And
   1. Improves the overall quality by removing hard-coded paths, replacing them with variables.

On the negative side,

1. it can cause some confusion
2. it may break things in the beginning
3. it may cause "legacy" issues (although shouldn't concern us?)

A final comment: we could split the "apache2_docroot" into more than one variable, depending on the context. Maybe have {{ apache2_docroot }}, {{ nginx_docroot }} and just plain {{ docroot }} which could be assigned to either of those two, depending which one is in use. All the Apache tasks would still use {{ apache2_docroot }}, while the Vagrantfile could use {{ docroot }}. That way, nginx and apache would become "pluggable". And to get there, we would still need to go through the "negative side" points mentioned.

Just my 2 cents. Thank you for the feedback.

[philipnorton42]

You know what, I'm warming to this. I think the use of a variable to make it as flexible as possible is a good idea. There might be some fettling to do around the variable names, but I think something generic like {{ webserver_docroot }} would probably do it. This is descriptive, keeps it separate from {{ host_synced_folder }} and any other 'docroot' directories that might exist.

That said, I think we should leave this until version 1.2. I'm trying to draw a line under the current codebase and release a new version (which I think we are nearly there really).

[dixhuit]

I'm trying to draw a line under the current codebase and release a new version (which I think we are nearly there really).

Ha! Good luck with that :)

[philipnorton42]

Ha! Good luck with that :)

We all have our dreams! :)

[mbarcia]

We all have our dreams! :)

You should start by creating a new release branch for 1.1, right?

[philipnorton42]

I'm going to close this ticket in favour of a new 'meta-ticket'. This ticket proposes a new Apache setup structure which should resolve this issue. See it here : https://github.com/hashbangcode/vlad/issues/284