fix: Make sure env-type settings are populated before start, don't override `.ddev/.gitignore` file, for #7236 by rfay · Pull Request #7286 · ddev/ddev

rfay · 2025-05-13T15:45:55Z

The Issue

refactor: Use .ddev/.env.web for Craft CMS DDEV settings, fixes #7233 #7236
Discord (breakage of .ddev/.gitignore on craft in v1.24.5): https://discord.com/channels/664580571770388500/1372597483443589264

In #7236 (comment) @stasadev pointed out that now that we're using .ddev/.env* for settings (instead of using php application-defined settings load techniques) the settings/env values may be loaded too late (after containers are up) in some situations.

Before #7236 I believe that all explicit use of settings, including project types that used project-level .env (loaded by PHP dotenv for example) were application-loaded, which meant that it didn't matter that we wrote the .env late (post-start). But now with #7236 we're using DDEV's .ddev/.env.* so those only get loaded during docker-compose up, and need to be written before docker-compose up.

The CraftCMS config overrides .ddev/.gitignore completely (which is wrong), and our logic for settings files creates .gitignore file in the directory of the settings file. Since CraftCMS uses .ddev/.env.web, its parent is .ddev, so it used .ddev/.gitignore.

How This PR Solves The Issue

Move the call to app.CreateSettingsFile() in the start sequence to before the docker-compose up

Don't override .ddev/.gitignore for CraftCMS.

Manual Testing Instructions

Mostly automated tests should tell us about this;

A good check of Craft CMS in light of #7236 (comment) is a good idea

Automated Testing Overview

No changes.

Release/Deployment Notes

github-actions · 2025-05-13T15:53:45Z

Download the artifacts for this pull request:

See Testing a PR.

stasadev

Thank you, I tested the Craft CMS quickstart using this PR, and now it updates .ddev/.env.web as expected.

rfay · 2025-05-13T19:49:16Z

Open to suggestions about whether we should get this into this release. I don't foresee problems with doing the settings early, but perhaps I'm being naive. I didn't see any of the settings creators that tried to use a running container either.

stasadev · 2025-05-13T19:53:54Z

To be safe, it can be merged early in the next release.

The workaround is to leave .ddev/.env.web untouched and run ddev restart.

I don't see any issues with this fix, but we can test it for a longer time in DDEV HEAD.

rfay · 2025-05-15T16:33:20Z

Rebased

stasadev · 2025-05-15T19:10:38Z

The first post is updated with .ddev/.gitignore issue, which I fixed here.

We may want to think about how to properly gitignore .ddev/.env.* files (but they were not intended to be gitignored, when I added them for add-ons).

This is probably a task for:

Feature: .ddev/.env.<anything> or .ddev/.env.global.<anything> #7235

stasadev · 2025-05-15T20:50:24Z

-	if _, err = app.CreateSettingsFile(); err != nil {
-		return fmt.Errorf("failed to write settings file %s: %v", app.SiteDdevSettingsFile, err)
-	}
-


I think we should have app.CreateSettingsFile() in both places, on pre-start and post-start.

I suggest to bring back this removed condition.

This code runs only when site is running:

ddev/pkg/ddevapp/drupal.go

Lines 565 to 582 in 7b0cb14

// It is possible that a Drupal install has been done, setting sites/default and sites/default/settings.php

// to read-only, which breaks mutagen's access to them so mutagen then

// can't sync. See https://github.com/ddev/ddev/issues/6491

// So we chmod +w the two files that a Drupal install may set read-only

// *inside* the container, allowing mutagen access to it again

if app.IsMutagenEnabled() && status == SiteRunning {

settingsFiles := []string{

path.Join(app.GetAbsDocroot(true), `sites/default`),

path.Join(app.GetAbsDocroot(true), `sites/default/settings.php`),

}

stdout, stderr, err := app.Exec(&ExecOpts{

Cmd: fmt.Sprintf(`chmod u+w %s 2>&1`, strings.Join(settingsFiles, " ")),

})

if err != nil {

util.Warning("Unable to set permissions inside container on settings files; err='%v', stdout='%s', stderr='%s'", err, stdout, stderr)

}

}

IMO it's pretty safe to do that, but here it was inside mutagenEnabled right?

Yes, inside mutagenEnabled.

I added it back where it was before (but that was late in Start, not in mutagen section)

rfay · 2025-05-15T20:51:41Z

-		if path.Dir(app.SiteSettingsPath) != app.AppRoot {
+		// Don't override the existing .ddev/.gitignore as well
+		// TODO: we may want to append to .ddev/.gitignore if needed.
+		if path.Dir(app.SiteSettingsPath) != app.AppRoot && path.Dir(app.SiteSettingsPath) != app.GetConfigPath("") && app.SiteDdevSettingsFile != "" {


Fascinating. I'll take a bit of a look at this in the light of its history. The reason this was like this was that the drupal sites/default had to have its own gitignore IIRC.

This is great; now I understand the whole history and the stumble here.

…#7236

rfay · 2025-05-16T16:56:48Z

I made minor changes and re-added the previous near-post-start settings update. I don't understand exactly why it would be needed, but don't see it doing any harm.

stasadev

Thank you!

Adding code without deleting it seems safer to me.

Tested it again, the .ddev/.env.web file is updated on ddev start (I edited it during the start, and it was updated again)

And .ddev/.gitignore is not broken.

github-actions Bot added the bugfix label May 13, 2025

rfay mentioned this pull request May 13, 2025

build: make doesn't work on Codespaces (or other Ubuntu 20.04) #7287

Closed

stasadev approved these changes May 13, 2025

View reviewed changes

rfay marked this pull request as ready for review May 15, 2025 16:33

rfay requested a review from a team as a code owner May 15, 2025 16:33

stasadev force-pushed the 20250513_rfay_create_settings_earlier branch from 642dd08 to a2dc75f Compare May 15, 2025 19:06

stasadev changed the title ~~fix: Make sure env-type settings are populated before start, for #7236~~ fix: Make sure env-type settings are populated before start, don't override .ddev/.gitignore file, for #7236 May 15, 2025

stasadev requested changes May 15, 2025

View reviewed changes

rfay commented May 15, 2025

View reviewed changes

rfay and others added 4 commits May 16, 2025 10:28

fix: Make sure env-type settings are populated before start, for ddev…

fd88197

…#7236

don't override .ddev/.gitignore file

a423706

Minor warning wording change

6d82d28

Add CreateSettingsFile() back into late-write in start()

cec8720

rfay force-pushed the 20250513_rfay_create_settings_earlier branch from a2dc75f to cec8720 Compare May 16, 2025 16:37

Minor comment update to clarify settings-directory .gitignore

21c0e92

rfay requested a review from stasadev May 16, 2025 16:56

stasadev approved these changes May 16, 2025

View reviewed changes

stasadev mentioned this pull request May 19, 2025

Improve Craft CMS "settings management" (writing to project .env) #7233

Closed

1 task

rfay mentioned this pull request May 19, 2025

DDEV v1.24.6 release notes #7310

Closed

1 task

rfay merged commit 4eac605 into ddev:main May 19, 2025
14 checks passed

rfay deleted the 20250513_rfay_create_settings_earlier branch May 19, 2025 14:21

	// It is possible that a Drupal install has been done, setting sites/default and sites/default/settings.php
	// to read-only, which breaks mutagen's access to them so mutagen then
	// can't sync. See https://github.com/ddev/ddev/issues/6491
	// So we chmod +w the two files that a Drupal install may set read-only
	// inside the container, allowing mutagen access to it again
	if app.IsMutagenEnabled() && status == SiteRunning {
	settingsFiles := []string{
	path.Join(app.GetAbsDocroot(true), `sites/default`),
	path.Join(app.GetAbsDocroot(true), `sites/default/settings.php`),
	}
	stdout, stderr, err := app.Exec(&ExecOpts{
	Cmd: fmt.Sprintf(`chmod u+w %s 2>&1`, strings.Join(settingsFiles, " ")),
	})
	if err != nil {
	util.Warning("Unable to set permissions inside container on settings files; err='%v', stdout='%s', stderr='%s'", err, stdout, stderr)

	}
	}

Uh oh!

Uh oh!

Conversation

rfay commented May 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The Issue

How This PR Solves The Issue

Manual Testing Instructions

Automated Testing Overview

Release/Deployment Notes

Uh oh!

github-actions Bot commented May 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

stasadev left a comment

Choose a reason for hiding this comment

Uh oh!

rfay commented May 13, 2025

Uh oh!

stasadev commented May 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rfay commented May 15, 2025

Uh oh!

stasadev commented May 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

stasadev May 15, 2025

Choose a reason for hiding this comment

Uh oh!

rfay May 15, 2025

Choose a reason for hiding this comment

Uh oh!

stasadev May 15, 2025

Choose a reason for hiding this comment

Uh oh!

rfay May 16, 2025

Choose a reason for hiding this comment

Uh oh!

rfay May 15, 2025

Choose a reason for hiding this comment

Uh oh!

rfay May 16, 2025

Choose a reason for hiding this comment

Uh oh!

rfay commented May 16, 2025

Uh oh!

stasadev left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

rfay commented May 13, 2025 •

edited

Loading

github-actions Bot commented May 13, 2025 •

edited

Loading

stasadev commented May 13, 2025 •

edited

Loading

stasadev commented May 15, 2025 •

edited

Loading