Skip to content

Updated CLI steps to avoid Drupal installation errors #16

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

Closed
wants to merge 0 commits into from

Conversation

T-Fletcher
Copy link

@T-Fletcher T-Fletcher commented Mar 23, 2024

This patch makes a few tweaks to streamline initial installation:

  1. Adds prerequisites with links.
  2. Removes sites/default/files and sites/default/settings.php after ddev creates them when setting the project type - if they are present when ddev drupal install is run, Drupal errors saying it's already installed.
  3. Sets the yarn version and enables corepack, see yarn v4 #12.
  4. Adds steps to install drush, if desired.

For a more detailed breakdown, see this gist.

@T-Fletcher T-Fletcher changed the title Updated CLI steps to handle settings.php being created early by ddev Updated CLI steps to avoid Drupal installation errors Mar 23, 2024
Copy link
Contributor

@rfay rfay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some things to smooth things out.

@T-Fletcher
Copy link
Author

Thanks @rfay, I've accepted your changes.

Copy link
Contributor

@rfay rfay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Worked through it again :) Another round of suggestions. We need to get the add-on working though with yarn, see

@T-Fletcher
Copy link
Author

It may make more sense to apply my changes after #17 is resolved, as it overlaps. I also personally preferred @rpkoller 's README in #13, much easier to digest for newcomers :) Shall we continue this work in those tickets?

@rfay
Copy link
Contributor

rfay commented Mar 26, 2024

@simesy
Copy link
Contributor

simesy commented Mar 27, 2024

Different approach (I hadn't read this PR closely and my solution has different things, ironically) #21

Copy link
Contributor

@rfay rfay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ooops, I see I didn't finish my review. The fix here with sites/default/files on a mutagen-enabled system is important.

README.md Outdated
git clone https://git.drupalcode.org/project/drupal.git drupal
cd drupal
ddev config --project-type=drupal10
ddev config --project-type=drupal10 --omit-containers=db --docroot="" --php-version=8.3 --disable-settings-management --nodejs-version=20
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For folks with mutagen enabled (most everybody on macOS) the drupal* project types do a bind-mount in sites/default/files. That means that sites/default/files cannot actually be easily deleted, and thus ddev drupal is perpetually complaining that "drupal is already installed". It's annoying. This replaces the default upload_dirs (sites/default/files) with a dummy directory (.ddev/tmp) so that doesn't happen any more.
(Side note: Why can the web UI and drush do an install just fine with these things existing and silly ddev drupal can't?)

Suggested change
ddev config --project-type=drupal10 --omit-containers=db --docroot="" --php-version=8.3 --disable-settings-management --nodejs-version=20
ddev config --project-type=drupal10 --omit-containers=db --docroot="" --php-version=8.3 --disable-settings-management --nodejs-version=20 --upload-dirs=.ddev/tmp

@rfay
Copy link
Contributor

rfay commented Mar 28, 2024

A couple of suggestions @T-Fletcher -

  • Please use a named branch for PRs, so you don't get messy with trying to use "main" for various things. It always comes out badly. Use a branch like "20240328_fix_drupal_install_errors" or something like that.
  • When you close a PR without merging, please don't delete the branch. It loses all the changes.

@T-Fletcher
Copy link
Author

Thanks for the advice @rfay, this as my first time working with multiple devs on the same issue. I'll be sure to use feature branches and preserve the work even when closing the MR. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants