[BUGS-7620] define WP_HOME #115
Conversation
and make it available for future application.php modifications
| * Pantheon platform application settings. | ||
| * | ||
| * IMPORTANT NOTE: | ||
| * Do not modify this file. This file is maintained by Pantheon. |
There was a problem hiding this comment.
Usually, Pantheon-managed files in a composer-managed site are brought in via a dependency, e.g. pantheon-systems/drupal-integrations for Drupal sites. For WordPress composer-managed sites, this pattern was not followed because there were not many files to manage this way. Is there any appetite to revisit this decision?
There was a problem hiding this comment.
Ultimately, I don't know that that would leave us in a better place than adding a file for Pantheon-maintained modifications as far as merge conflicts. Currently, we're making a one-line change in a part of application.php that is unlikely to change much, if they've changed the file at all. If we added a dependency and moved our modifications there, we'd make changes to the composer.json, which users almost certainly have made modifications to.
Also, environment-specific application.php files is a recommended practice for Bedrock. We're going against the grain a little bit by not using the /environment/ directory, but since our changes apply to the platform and not a specific environment, this seemed to make the most sense. If people are familiar with Bedrock already, having a Pantheon-specific config file won't seem out of place.
I'm not broadly opposed to the idea, but this is also code that would otherwise have already existed in wp-config.php (or wp-config-pantheon.php) and I think it would be weirder to not make it part of the core project.
…ine them if they're already defined, we don't run this code path
* require a new application.pantheon.php file * use application.pantheon.php to define WP_HOME and make it available for future application.php modifications * ignore internal errors in phpcs rulesets * linting * ignore application.pantheon.php filename pattern * bump actions/cache to v4 * patch set-output with environment var see https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ * add the WP_HOME and WP_SITEURL values to the environment after we define them if they're already defined, we don't run this code path * look for the LANDO environment variable to check for Lando * use the lando environment variable in application.php, too * fix spacing * ignore the putenv that we added
* require a new application.pantheon.php file * use application.pantheon.php to define WP_HOME and make it available for future application.php modifications * ignore internal errors in phpcs rulesets * linting * ignore application.pantheon.php filename pattern * bump actions/cache to v4 * patch set-output with environment var see https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/ * add the WP_HOME and WP_SITEURL values to the environment after we define them if they're already defined, we don't run this code path * look for the LANDO environment variable to check for Lando * use the lando environment variable in application.php, too * fix spacing * ignore the putenv that we added
Adds a new
application.pantheon.phpfile for Pantheon-specific modifications toconfig/application.php. Checks ifWP_HOMEis defined in.envand defines it if not.