Subdirectory site install

[joemewes]

When having my Drupal install in a subdirectory (../public/sitename/) the symlinks don't work, so I have to use the --copy flag. This isn't great for a dev process as I can't work on the code base in the repo. I think the symlinks should be more dynamic, rather than hard coded to ../../../../repository

not sure if is an issue or feature request...

[pjcdawkins]

The symlinks aren't hard-coded. What does your repository file structure look like?

[joemewes]

Sorry I thought they were.

repo structure is, as normal: /modules /themes .platform.app.yaml

build hook we came up with to get working was as follows:

build: |
      # The subpath directory should exist already because it was created via
      # the public files mount.
      mkdir -p public/sitename
      mv public/* public/sitename/ 2>/dev/null || true
      mv public/sites/* public/sitename/sites/ 2>/dev/null || true
      mv public/sites/default/* public/sitename/sites/default/ 2>/dev/null || true
      rmdir public/sites/default
      rmdir public/sites
      cd public/sitename/sites/default/
      if [ ! $PLATFORM_ENVIRONMENT ]; then
      # If local
      ln -s ../../../../../../shared/settings.local.php
      cd ../../../../
      cd public/sitename/profiles/profilename/themes/custom/themename
      fi
      npm install
      bower install
      npm rebuild node-sass
      gulp sass:prod

I should also note, that a requirement of the project is to be accessed as if it were in a subdirectory and NOT on a subdomain. hence the above solution.

[pjcdawkins]

OK... the symlinks are created before the build hooks run, so that's why you get the wrong path if you're moving stuff around in the build hooks.

The --abslinks option lets you use absolute paths for the symlinks, but I guess you've already explored that option.

Hm...

[joemewes]

the absolute links don't work because of the docker (or any host->guest) dev environment with the repo paths on the host volume mapped on the guest being different.

If you feel this is an edge case scenario you think that won't ever occur again, feel free to leave it/close it. But thought it worth highlighting.

[pjcdawkins]

It might be less complicated to remove Platform.sh's Drupal processes, and build Drupal yourself, something like:

# don't build as Drupal automatically
build:
  flavor: composer

hooks:
  build: |
      # Build the Drupal profile using Drush Make.
      mkdir -p public
      drush make project-core.make public/sitename --yes --concurrency=4 --cache-duration-releasexml=300
      drush make project.make public/sitename/profiles/profilename --no-core -contrib-destination=. --cache-duration-releasexml=300' --concurrency=4
      mv * public/sitename/profiles/profilename/

... you'd also need to add Platform.sh database settings to settings.php, etc. - quite a lot of work, but it might end up cleaner than undoing the work that Platform.sh did automagically.

I would recommend not copying and pasting that ^ without understanding what it's doing - it's just written off the top of my head.

[joemewes]

sure thing.

I think for now, I might run platform build via a bash script and fix the symlinks myself as thats the only thing not working. And its all working on platform.sh, so this would be the quickest win.

Maybe further down the road this won't be an issue of any kind...

I close?