A modular, extendable PHP autoloader


Package to simplify the set up of WordPress integration and system testing.



issue comment
Don't override project type php by detected app, fixes #4403

Sure, I'll give it another try.

Created at 3 weeks ago
issue comment
Don't override project type php by detected app

I don't care much about the value of the project-type beside that it might be a bit confusing when a different value does not imply any different behavior. The configuration parameter disable_settings_management is new to me and if it only affects the CMS settings file management I'm fine with it. However, this PR originated from our short discussion in #4403 where you suggested to try the change this PR provides.

I'm fairly new to Go but if you want to move that forward (in whatever direction) I'd be happy to help. Otherwise just close the PR. I'll add a hint to the tickets how to avoid it using disable_settings_management.

Created at 1 month ago
issue comment
Don't override project type php by detected app

The issue I have is that I do want to use the project type "php" when working with a customized WordPress installation but every time I run ddev config ... to change a value that is not "project-type" it switches the project type to "wordpress" (described more detailed in #443 and also for Drupal in #1919.

I do want to use ddev config over editing config.yaml manually to keep this file up to date (inline documentation, new config keys and so on). I'm not sure if disable_settings_management: true would circumvent this issue. But in general I'd like to have DDEV managing configuration files and only use the command line API.

Maybe another config parameter disable_project_type_detection would be the most straightforward solution to maintain backward compatibility without increasing the complexity even more?

Created at 1 month ago
issue comment
Don't override project type php by detected app

I'm sorry I was a bit too optimistic here. Since app.Type is set to "php" by default, we cannot distinct between "php" as the default value or the value that was read from config.yaml in handleMainConfigArgs(). By just removing the app.Type == "php" condition from this statement we will circumvent the app detection entirely.

case (app.Type == "" || app.Type == nodeps.AppTypePHP) && (projectTypeArg == "" || projectTypeArg == detectedApptype):

I think what still should solve the mentioned issues and pass the existing tests would be the distinction between "php" being the default value or the one from the config.yaml. This could either be implemented in handleMainConfigArgs() or by introducing another parameter app.IsDefaultType which would be set in DdevApp.readConfig() for example.

Created at 1 month ago
pull request opened
Don't override project type php by detected app

The Issue

DDEV's config command will override project type "php" if any app like WordPress or Drupal is detected.

How This PR Solves The Issue

As suggested in #4403 it applies the detected app type only if there is no type specified yet.

Manual Testing Instructions

Automated Testing Overview

TestConfigMaintainProjectTypePhp creates a common DDEV project with type "php" and creates a {DOC_ROOT}/wp-settings.php file to mimic a WordPress installation. Then it runs a ddev config command to change an arbitrary value (the PHP version in this case) and finally verifies that the project type is still set to "php".

Related Issue Link(s)

  • #1919
  • #4403

Release/Deployment Notes

Created at 1 month ago
create branch
dnaber-de create branch 20230225_dnaber-de_do_not_override_php_project_type
Created at 1 month ago

Make ddev ssh exit more predictable, not outputting useless info, fixes #3738 (#4569)

Fix 'n' panic in ddev-platformsh, fixes #4579, fixes drud/ddev-platformsh#94 (#4581)

  • Fix 'n' panic in ddev-platformsh, for #4579 [skip ci]
  • Move to yaml.v3
  • fix up several maps that require string key for yaml.v3
  • More instances where yaml.v3 wants string on left side

Provide container start hooks and ability to RUN dockerfile with code mounted, fixes #4233 (#4549)

Don't enable xdebug by default in ddev-webserver, fixes #4597 (#4599)

[debugging] better vscode launch.json [skip ci] (#4601)

Update service name typo in ddev ssh example (#4602) [skip ci]

Traefik needs to properly handle $VIRTUAL_HOST, fixes #4537 (#4582)

[docs] Update DrupalEasy logo in readme + optimize all logos (#4605) [skip ci]

Make sure that traefik items get properly managed in .gitconfig (#4604)

Use 'ddev' for official add-ons, fix test, fixes #4608 (#4609)

Make nodejs installation work, changed npm --unsafe-perm behavior (#4610)

[docs] Fix typos, especially in developer docs (#4603) [skip ci]

Make 'ddev composer create' respect composer_root, fixes #4475 (#4611)

Make ddev nvm work right again, fixes #4499 (#4620)

[docs] add Statamic setup guide (#4622) [skip ci]

[docs] Update release management docs (#4627) [skip ci]

Fix line break in ddev exec help, fixes #4634 (#4636)

Bump golang to v1.20, fixes #4443 (#4639)

If /mnt/ddev_config is not mounted, don't fail, just warn (#4642) [skip ci]

Bump docker-compose to 2.16.0, which is built with go 1.20, fixing DNS issues on macOS (#4641)

Created at 1 month ago
Created at 2 months ago