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

'docroot' instead of 'web' #64

Open
weitzman opened this Issue Oct 24, 2015 · 26 comments

Comments

Projects
None yet
9 participants
@weitzman
Collaborator

weitzman commented Oct 24, 2015

Acquia Cloud requires Drupal in a subdir named 'docroot' but this project uses 'web'. The 'web' name is used in scripts in addition to composer.json. Is there some better solution for changing this than find/replace? Would be good to document this somewhere (I volunteer).

@deviantintegral

This comment has been minimized.

Show comment
Hide comment
@deviantintegral

deviantintegral Nov 4, 2015

Contributor

I put a symlink from web to docroot in the project repository, and then ignored docroot from code indexing in PHPStorm. I'm not sure if Acquia lets you serve from a symlink, but I imagine you could rename web to docroot, and then make web the symlink.

Contributor

deviantintegral commented Nov 4, 2015

I put a symlink from web to docroot in the project repository, and then ignored docroot from code indexing in PHPStorm. I'm not sure if Acquia lets you serve from a symlink, but I imagine you could rename web to docroot, and then make web the symlink.

@greg-1-anderson

This comment has been minimized.

Show comment
Hide comment
@greg-1-anderson

greg-1-anderson Nov 26, 2015

Collaborator

I use 'drupal' in pantheon-systems/example-drupal7-circle-composer, and I have also seen htdocs and code.

I'd like to use the same directory name in my project as is used here. It doesn't matter to me very much which one we use; if I'm going to have to rename my root directory anyway, 'docroot' is as good of a choice as any.

If we can agree that it makes sense to standardize on docroot, I'll make a PR here to do it, and convert my project over as well.

Collaborator

greg-1-anderson commented Nov 26, 2015

I use 'drupal' in pantheon-systems/example-drupal7-circle-composer, and I have also seen htdocs and code.

I'd like to use the same directory name in my project as is used here. It doesn't matter to me very much which one we use; if I'm going to have to rename my root directory anyway, 'docroot' is as good of a choice as any.

If we can agree that it makes sense to standardize on docroot, I'll make a PR here to do it, and convert my project over as well.

@webflo

This comment has been minimized.

Show comment
Hide comment
@webflo

webflo Nov 26, 2015

Member

I would go with web. Many people use the template already for D7 and D8. web is default in https://github.com/symfony/symfony-standard as well.

Member

webflo commented Nov 26, 2015

I would go with web. Many people use the template already for D7 and D8. web is default in https://github.com/symfony/symfony-standard as well.

@greg-1-anderson

This comment has been minimized.

Show comment
Hide comment
@greg-1-anderson

greg-1-anderson Nov 26, 2015

Collaborator

Okay, I will switch to web to follow the standard here and in symfony.

Collaborator

greg-1-anderson commented Nov 26, 2015

Okay, I will switch to web to follow the standard here and in symfony.

@webflo

This comment has been minimized.

Show comment
Hide comment
@webflo

webflo Dec 2, 2015

Member

@weitzman Maybe we can revisit this issue and provide a template without the scaffolding files after #77 went in.

Member

webflo commented Dec 2, 2015

@weitzman Maybe we can revisit this issue and provide a template without the scaffolding files after #77 went in.

@greg-1-anderson

This comment has been minimized.

Show comment
Hide comment
@greg-1-anderson

greg-1-anderson Dec 12, 2015

Collaborator

So, it turns out that I have to use code when using Drupal 8 on Pantheon. This limitation should not be around forever; once the restriction is lifted, I'll switch back to web in my fork.

When using drupal-composer/drupal-scaffold, it is very easy to change the location of the Drupal root--and is getting easier. It might be nice to make scripts/composer/post-install.sh a function of drupal-scaffold. If we also defined the placeholder folders such as modules/contrib in composer.json, and had drupal-scaffold create those as well, then we could probably remove the web directly altogether.

Collaborator

greg-1-anderson commented Dec 12, 2015

So, it turns out that I have to use code when using Drupal 8 on Pantheon. This limitation should not be around forever; once the restriction is lifted, I'll switch back to web in my fork.

When using drupal-composer/drupal-scaffold, it is very easy to change the location of the Drupal root--and is getting easier. It might be nice to make scripts/composer/post-install.sh a function of drupal-scaffold. If we also defined the placeholder folders such as modules/contrib in composer.json, and had drupal-scaffold create those as well, then we could probably remove the web directly altogether.

@RoSk0

This comment has been minimized.

Show comment
Hide comment
@RoSk0

RoSk0 Dec 21, 2015

Is it possible the directory name to be configurable?

RoSk0 commented Dec 21, 2015

Is it possible the directory name to be configurable?

@greg-1-anderson

This comment has been minimized.

Show comment
Hide comment
@greg-1-anderson

greg-1-anderson Dec 21, 2015

Collaborator

If we removed the web directory, then the only references to the document root would be in the composer.json file and the post-install script. We might be able to have post-install read composer.json and pick up the location of the document root by checking the location of drupal/core; however, there are multiple references to the document root in the composer.json file. You could maybe factor those out to a single reference by adding variable replacement support to composer/installers, but I don't know if such an enhancement would be welcome or not.

Collaborator

greg-1-anderson commented Dec 21, 2015

If we removed the web directory, then the only references to the document root would be in the composer.json file and the post-install script. We might be able to have post-install read composer.json and pick up the location of the document root by checking the location of drupal/core; however, there are multiple references to the document root in the composer.json file. You could maybe factor those out to a single reference by adding variable replacement support to composer/installers, but I don't know if such an enhancement would be welcome or not.

@greg-1-anderson

This comment has been minimized.

Show comment
Hide comment
@greg-1-anderson

greg-1-anderson Dec 22, 2015

Collaborator

The latest version of #77 makes it pretty easy to change the directory name on the fly. There are still a couple of files where it needs to be changed. Unfortunately, the composer command-line tool will not divulge the installation location of a component. You can do it from a custom installer, but, as I mentioned in #77, I recommended that post-install.sh should be kept a shell script so that it is easier for folks to customize.

Collaborator

greg-1-anderson commented Dec 22, 2015

The latest version of #77 makes it pretty easy to change the directory name on the fly. There are still a couple of files where it needs to be changed. Unfortunately, the composer command-line tool will not divulge the installation location of a component. You can do it from a custom installer, but, as I mentioned in #77, I recommended that post-install.sh should be kept a shell script so that it is easier for folks to customize.

@greg-1-anderson

This comment has been minimized.

Show comment
Hide comment
@greg-1-anderson

greg-1-anderson Feb 21, 2016

Collaborator

#77 / #105 have been merged, so relocating the docroot from web to something else now requires modification of only a few files:

  1. composer.json (several locations)
  2. .gitignore (several locations)
  3. post-install.sh (only DOCROOT variable at top of the script)

We could in principal read DOCROOT from composer.json in post-install.sh, but it would still be necessary to make multiple changes to composer.json and .gitignore, so perhaps this is not worthwhile.

Perhaps we should leave this as a customization to be done by the end user?

Collaborator

greg-1-anderson commented Feb 21, 2016

#77 / #105 have been merged, so relocating the docroot from web to something else now requires modification of only a few files:

  1. composer.json (several locations)
  2. .gitignore (several locations)
  3. post-install.sh (only DOCROOT variable at top of the script)

We could in principal read DOCROOT from composer.json in post-install.sh, but it would still be necessary to make multiple changes to composer.json and .gitignore, so perhaps this is not worthwhile.

Perhaps we should leave this as a customization to be done by the end user?

@deviantintegral

This comment has been minimized.

Show comment
Hide comment
@deviantintegral

deviantintegral Mar 7, 2016

Contributor

This feels like there's enough site-specific components to this that trying to automate more probably isn't worth the effort. Let's just make this a task to document the steps above? So far they're working fine for me.

Contributor

deviantintegral commented Mar 7, 2016

This feels like there's enough site-specific components to this that trying to automate more probably isn't worth the effort. Let's just make this a task to document the steps above? So far they're working fine for me.

@weitzman

This comment has been minimized.

Show comment
Hide comment
@weitzman

weitzman Mar 16, 2016

Collaborator

Yes, a docs PR sounds about right. Symlink is simplest solution for many.

Collaborator

weitzman commented Mar 16, 2016

Yes, a docs PR sounds about right. Symlink is simplest solution for many.

@gambry

This comment has been minimized.

Show comment
Hide comment
@gambry

gambry Apr 6, 2016

relocating the docroot from web to something else now requires modification of only a few files:

composer.json (several locations)
.gitignore (several locations)
post-install.sh (only DOCROOT variable at top of the script)

After #128 now files are:

  • composer.json (several locations)
  • .gitignore (several locations)
  • scripts/composer/ScriptHandler.php

But as @weitzman is suggesting a symlink is still the simplest solution ("web" -> "any" or "any" -> "web").

gambry commented Apr 6, 2016

relocating the docroot from web to something else now requires modification of only a few files:

composer.json (several locations)
.gitignore (several locations)
post-install.sh (only DOCROOT variable at top of the script)

After #128 now files are:

  • composer.json (several locations)
  • .gitignore (several locations)
  • scripts/composer/ScriptHandler.php

But as @weitzman is suggesting a symlink is still the simplest solution ("web" -> "any" or "any" -> "web").

@webflo

This comment has been minimized.

Show comment
Hide comment
@webflo

webflo Apr 8, 2016

Member

We could follow symfonys model and add some extra config to our composer.json and use in our ScriptHandler. see https://github.com/symfony/symfony-standard/blob/master/composer.json#L53

Member

webflo commented Apr 8, 2016

We could follow symfonys model and add some extra config to our composer.json and use in our ScriptHandler. see https://github.com/symfony/symfony-standard/blob/master/composer.json#L53

@greg-1-anderson

This comment has been minimized.

Show comment
Hide comment
@greg-1-anderson

greg-1-anderson Apr 8, 2016

Collaborator

That's a great idea, but I think it would need to be a feature of Composer Installers. It would be better as a feature of Composer Installers, anyway, as it seems like it would be commonly useful to be able to do replacements from extra config in destination paths -- and Composer Installers already supports replacements in paths.

Collaborator

greg-1-anderson commented Apr 8, 2016

That's a great idea, but I think it would need to be a feature of Composer Installers. It would be better as a feature of Composer Installers, anyway, as it seems like it would be commonly useful to be able to do replacements from extra config in destination paths -- and Composer Installers already supports replacements in paths.

@gambry

This comment has been minimized.

Show comment
Hide comment
@gambry

gambry Apr 9, 2016

@greg-1-anderson so far composer Installers supports replacements in paths based on package $name, $vendor, $type. Do you think having project based replacements will be a feature they would take in consideration?

If they won't, I would see it more like a composer script, which ask for docroot folder name, update the composer.json paths and add an extra configuration parameter to be used in ScriptHandler.

gambry commented Apr 9, 2016

@greg-1-anderson so far composer Installers supports replacements in paths based on package $name, $vendor, $type. Do you think having project based replacements will be a feature they would take in consideration?

If they won't, I would see it more like a composer script, which ask for docroot folder name, update the composer.json paths and add an extra configuration parameter to be used in ScriptHandler.

@joelpittet

This comment has been minimized.

Show comment
Hide comment
@joelpittet

joelpittet Feb 13, 2017

Just wondering because I am planning on doing this. Could you create a relative symlink from docroot(or whatever you prefer) to web?

joelpittet commented Feb 13, 2017

Just wondering because I am planning on doing this. Could you create a relative symlink from docroot(or whatever you prefer) to web?

@greg-1-anderson

This comment has been minimized.

Show comment
Hide comment
@greg-1-anderson

greg-1-anderson Feb 13, 2017

Collaborator

@joelpittet Yes, some folks do that; should work in most environments.

Collaborator

greg-1-anderson commented Feb 13, 2017

@joelpittet Yes, some folks do that; should work in most environments.

@nalipaz

This comment has been minimized.

Show comment
Hide comment
@nalipaz

nalipaz Feb 13, 2017

Could we use a composer config variable for this? I was just thinking on this and it might be a simple solution.

nalipaz commented Feb 13, 2017

Could we use a composer config variable for this? I was just thinking on this and it might be a simple solution.

@greg-1-anderson

This comment has been minimized.

Show comment
Hide comment
@greg-1-anderson

greg-1-anderson Feb 14, 2017

Collaborator

See my previous comment. The docroot variable exists in a few plain text files. Some fixup is required if the user wants to select something else.

Collaborator

greg-1-anderson commented Feb 14, 2017

See my previous comment. The docroot variable exists in a few plain text files. Some fixup is required if the user wants to select something else.

@nalipaz

This comment has been minimized.

Show comment
Hide comment
@nalipaz

nalipaz Feb 14, 2017

We could in principal read DOCROOT from composer.json in post-install.sh, but it would still be necessary to make multiple changes to composer.json and .gitignore, so perhaps this is not worthwhile.

To that remark, wouldn't it be possible to store the value of the docroot in composer config, maybe composer config documentroot something and then apply it in the composer.json with a "{$documentroot}/modules/contrib/{$name}": ["type:drupal-module"], as an example? I would assume the variable should be able to be obtained in the post-install.sh too. That only leaves the .gitignore which could be edited manually by most or we could go so far as to sed it to the correct value if it is set, or perhaps change to a wildcard for simplicity.

nalipaz commented Feb 14, 2017

We could in principal read DOCROOT from composer.json in post-install.sh, but it would still be necessary to make multiple changes to composer.json and .gitignore, so perhaps this is not worthwhile.

To that remark, wouldn't it be possible to store the value of the docroot in composer config, maybe composer config documentroot something and then apply it in the composer.json with a "{$documentroot}/modules/contrib/{$name}": ["type:drupal-module"], as an example? I would assume the variable should be able to be obtained in the post-install.sh too. That only leaves the .gitignore which could be edited manually by most or we could go so far as to sed it to the correct value if it is set, or perhaps change to a wildcard for simplicity.

@greg-1-anderson

This comment has been minimized.

Show comment
Hide comment
@greg-1-anderson

greg-1-anderson Feb 14, 2017

Collaborator

@nalipaz Yeah, that would work for sure. The one wrinkle is that at the moment, we use composer/installers to remap the module install locations, and it does not support a {$documentroot} substitution. At least, in the past it didn't. If you know how to make that work today with a composer config, then a PR to demonstrate that would be most welcome.

Collaborator

greg-1-anderson commented Feb 14, 2017

@nalipaz Yeah, that would work for sure. The one wrinkle is that at the moment, we use composer/installers to remap the module install locations, and it does not support a {$documentroot} substitution. At least, in the past it didn't. If you know how to make that work today with a composer config, then a PR to demonstrate that would be most welcome.

@nalipaz

This comment has been minimized.

Show comment
Hide comment
@nalipaz

nalipaz Feb 14, 2017

@greg-1-anderson I appreciate the details on that. I can't say I know how to make that work and was only speaking theoretically here since it seems the most integrated way. If I can gather a moment I might try my hand at the idea and of course others are welcome to try as well.

nalipaz commented Feb 14, 2017

@greg-1-anderson I appreciate the details on that. I can't say I know how to make that work and was only speaking theoretically here since it seems the most integrated way. If I can gather a moment I might try my hand at the idea and of course others are welcome to try as well.

@fabean

This comment has been minimized.

Show comment
Hide comment
@fabean

fabean Mar 1, 2017

I locally changed the following:
• composer.json (several locations)
• .gitignore (several locations)
• scripts/composer/ScriptHandler.php

To say "docroot" instead of "web" but I'm still not getting the root files in docroot like index.php. I know those come from the drupal-scaffold project but I don't have this issue when it's under /web. Is there another hidden config location I cannot find?

fabean commented Mar 1, 2017

I locally changed the following:
• composer.json (several locations)
• .gitignore (several locations)
• scripts/composer/ScriptHandler.php

To say "docroot" instead of "web" but I'm still not getting the root files in docroot like index.php. I know those come from the drupal-scaffold project but I don't have this issue when it's under /web. Is there another hidden config location I cannot find?

@fabean

This comment has been minimized.

Show comment
Hide comment
@fabean

fabean Mar 3, 2017

Okay, I lied... Totally works it must have been a composer cache or something that kept wanting to put things in /web. Sorry.

fabean commented Mar 3, 2017

Okay, I lied... Totally works it must have been a composer cache or something that kept wanting to put things in /web. Sorry.

@webflo

This comment has been minimized.

Show comment
Hide comment
@webflo

webflo Mar 22, 2017

Member

@fabean Please review #255. This removes the requirement to change the ScriptHandler

Member

webflo commented Mar 22, 2017

@fabean Please review #255. This removes the requirement to change the ScriptHandler

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