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

Document how to use a different web-root instead of 'web' #64

Open
weitzman opened this issue Oct 24, 2015 · 50 comments
Open

Document how to use a different web-root instead of 'web' #64

weitzman opened this issue Oct 24, 2015 · 50 comments
Labels
Quick fix State: Confirmed The issue was triaged and confirmed for development Type: Documentation

Comments

@weitzman
Copy link
Contributor

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
Copy link
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.

@greg-1-anderson
Copy link
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.

@webflo
Copy link
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
Copy link
Collaborator

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

@webflo
Copy link
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
Copy link
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
Copy link

RoSk0 commented Dec 21, 2015

Is it possible the directory name to be configurable?

@greg-1-anderson
Copy link
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.

@greg-1-anderson
Copy link
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.

@greg-1-anderson
Copy link
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?

@deviantintegral
Copy link
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.

@weitzman
Copy link
Contributor Author

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

@gambry
Copy link

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
Copy link
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
Copy link
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.

@gambry
Copy link

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
Copy link
Contributor

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
Copy link
Collaborator

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

@nalipaz
Copy link

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
Copy link
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.

@nalipaz
Copy link

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
Copy link
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.

@nalipaz
Copy link

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
Copy link

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
Copy link

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
Copy link
Member

webflo commented Mar 22, 2017

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

@webflo
Copy link
Member

webflo commented Sep 21, 2019

@cgmonroe Good idea, please submit an PR.

@greg-1-anderson
Copy link
Collaborator

The post-install script now uses Drupal Finder to locate the web root, so only .gitignore and the composer.json files would need to be modified to use a different location.

@simesy
Copy link

simesy commented Sep 23, 2019

You wouldn't necessarily want to add /docroot to .gitignore anyway, since you'd likely be on Acquia, and their culture is to commit docroot.

@greg-1-anderson
Copy link
Collaborator

The documentation should not presuppose that Acquia is the only reason someone would want to use a different directory name for the Drupal root. It would be worthwhile to discuss how to adjust the .gitignore file for environments where vendor et. al. are committed.

@simesy
Copy link

simesy commented Sep 23, 2019

Agreed, I'm just saying that in my experience jumping around between vendors and dev tools, you're getting down to edge cases with that one. That's a gold stamp :P

@simesy
Copy link

simesy commented Sep 23, 2019

I would probably add both /docroot and /web to gitignore, as these are the only two drupal webroots I've ever seen... and I've never seen them used for anything else (in Drupal project context). Or comment out /docroot with inline comment, which is the ideal for any new person reading it.

michaellenahan pushed a commit to michaellenahan/drupal-project that referenced this issue Sep 30, 2019
@michaellenahan
Copy link
Contributor

With credit to @cgmonroe here is the PR for the changes to the README: #527

@Juc1
Copy link

Juc1 commented Mar 26, 2020

Hi all re https://github.com/drupalcommerce/project-base/blob/8.x/composer.json

Just before the installer paths there is

"drupal-scaffold": {
            "locations": {
                "web-root": "web/"
            }
        },

236d1f0 mentions installer paths. Do I also need to change web-root ?

@greg-1-anderson
Copy link
Collaborator

The previous comments referred to the changes needed when using drupal-composer/drupal-scaffold. Now that this project is using drupal/core-composer-scaffold, you should change the web-root setting as well.

@Juc1
Copy link

Juc1 commented Mar 28, 2020

@greg-1-anderson ok thanks

@leymannx leymannx changed the title 'docroot' instead of 'web' Document how to use a different web-root instead of 'web' Jan 12, 2021
@alexpurser
Copy link

quick novice question please and apologies if ive misunderstood - my webserver creates a docroot - say vhost1 - and i create a drupal project which is now accessible via browser from URL/web. If I want to be able to access the site via URL what are the steps i must follow including any tidying up.. im sure ive read that the composer.json file shouldnt be in the same folder that is visible from the web.. i guess im looking for a best practice guide here keeping it simple for the new guy!

@deviantintegral
Copy link
Contributor

The best / easiest solution is to keep your code in the same place on disk, but change the docroot to <current path for docroot>/web. It's not recommended nor typically supported these days to have the top-level directory you have access to also be the docroot.

@leymannx
Copy link
Collaborator

@alexpurser – You simply have to point your vhost or domain to the web/ folder inside the project. So /var/www/myproject/web instead of just /var/www/myproject. It's bare server configuration. And outside of the scope of this project.

@alexpurser
Copy link

Hi Norman im afraid im constrained by the server which creates the web root directories for vhosts directly under its vhost directory - .../vhost/A, .../vhost/B. ,,,etc. It is non trivial change on the server i am using (Nethserver dist of Centos) so, for the purposes of this question at least, im bringing it back into scope for this project if I may!

@greg-1-anderson
Copy link
Collaborator

This project does not support web hosts that require the Drupal root be at the project root. If you are using such a host, you could try looking at drupal/legacy-project.

@NielsSluijs
Copy link

@alexpurser, I've solved a similar problem by placing the project in a separate directory and replace your "web-root directory" with a symbolic link to the web/ folder.

@AlexSkrypnyk
Copy link
Collaborator

This issue is about documenting the usage of a different web root.

Before we can document this, we need to decide if this project should provide a symlink from docroot to web to demonstrate that this is possible (using docroot, which happens to make this project Acquia-compatible out-of-the-box).

If yes - than we need a PR with a docroot as a symlink and a readme explanation on how to change that. Do note that if we decide to go this way, than it will not be a simple find/replace of docroot with your_docroot because there are several places where the document root is referenced.

If no - we can just document that it is possible to use a symlink, but there could be some side effects.

@AlexSkrypnyk AlexSkrypnyk self-assigned this May 12, 2024
@deviantintegral
Copy link
Contributor

After recommending the symlink solution in 2015, it’s not something I recommend anymore. Challenges I’ve seen include:

  • Developers not knowing they should omit the symlink from IDE indexing, leading to significant performance hit.
  • Difficulties with symlinks on Windows hosts
  • While ddev didn’t exist in 2015, and now does a good job of managing code mounts with symlinks, I’ve seen issues for projects that are using docker compose directly and mess up code syncing, leading to either the symlink not being preserved and duplicate code being synced, or for conflicts syncing changes back out such as after a composer install.

I think the best thing to do is to link to https://github.com/drupal/core-composer-scaffold?tab=readme-ov-file#defining-project-locations and call this done

@leymannx
Copy link
Collaborator

-1 for symlinks from me too.

Can't we pick up the webdir name from composer.json in scripts? This would make it relatively easy to have the webdir changed in just composer.json.

@AlexSkrypnyk
Copy link
Collaborator

cool, we have 3 supporters for not doing symlinks.
Let's just document the process of how it can be updated, if needed.

@leymannx
Copy link
Collaborator

Is there no way to have a variable path name in the installer-paths? Something like "[web-root]/core": ["type:drupal-core"], 🤔

@AlexSkrypnyk AlexSkrypnyk added the State: Confirmed The issue was triaged and confirmed for development label May 13, 2024
@AlexSkrypnyk AlexSkrypnyk removed their assignment May 14, 2024
@adityajoshi94
Copy link

@greg-1-anderson Moving to year 2024 , can we create a symlink in pantheon hosting from Drupal webroot ?
Desired symlink as follow
/web/robot.txt to web/site/default/files/robot.txt.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Quick fix State: Confirmed The issue was triaged and confirmed for development Type: Documentation
Projects
None yet
Development

No branches or pull requests