Terminus doesn't allow pantheon-systems/wordpress-composer to be installed about terminus

[jazzsequence]

There is also a known issue with the Pantheon platform where it didn't support WP core outside of root or web for sub-directory multisites. So we couldn't place it under web/wp for example, as it would fail resolve all the admin requests.

This is resolved in Composer Managed. We've tested WordPress Composer Managed with both subdomain & subdirectory multisite. Note however, that there are platform-level configuration changes that need to be made to support subdirectory multisite (unrelated to the particular issue you mentioned).

[greg-1-anderson]

It is difficult to get Terminus and Drupal to work together, because they have many shared dependencies. Terminus and WordPress do not have as many shared dependencies, but even a combination that works fine today might fail in the future. PHPUnit, PHPCS & c. were designed to be mixed in with other applications; Terminus was not. We did literally get requests that we should change the version of certain dependencies that Terminus was using, so that it could be mixed together with one particular version of Drupal. This is not something we intend to code for. The intended design is for folks to use the phar.

[jazzsequence]

@kasparsd The wordpress-composer repository will be deprecated for a Composer-based WordPress in favor of WordPress (Composer Managed). That repository, however, is based on Bedrock and uses Roots' distribution of WordPress as a Composer dependency to manage WordPress updates rather than via automation (like the main WordPress upstream and the wordpress-composer upstream this is referring/linking to). Is there a reason you specifically need WordPress installed in the root directory and updates managed by automation rather than updates to WordPress managed via Composer itself?

Our documentation has been updated to point to WordPress (Composer Managed) as the recommended option, although this workflow is still early access and not all the docs have been updated yet.
https://docs.pantheon.io/guides/wordpress-composer/pre-ga/wordpress-composer-managed

[kasparsd]

@jazzsequence We've been pulling in the wordpress-composer repo to the web directory via Composer for years. That was before the Pantheon mu-plugins were brought out as dedicated packages.

We're currently using it mostly for dynamically including the pantheon-specific wp-config.php which knows where all the ENV variables are. Looks like we would need to implement https://github.com/pantheon-upstreams/wordpress-composer-managed/blob/main/config/application.php if we wanted to replace it with pure Roots WP core.

There is also a known issue with the Pantheon platform where it didn't support WP core outside of root or web for sub-directory multisites. So we couldn't place it under web/wp for example, as it would fail resolve all the admin requests.

We're currently unable to update to PHP8 tooling because of the Terminus update being blocked by the conflicts flag.

[greg-1-anderson]

Terminus and WordPress are separate PHP applications. They are not intended to be combined with Composer. The conflict was added to explicitly prevent this use case, because we cannot guarantee that it will continue to work, and therefore cannot support it.

We do not recommend installing Terminus in a Pantheon site; it is better to install it in an external system. If you insist on installing Terminus in a Pantheon site, then you should add the Terminus .phar rather than attempt to merge the applications with Composer.

[kasparsd]

@greg-1-anderson I probably didn't explain myself well -- Terminus is being added as a development dependency so that developers on the project can reliably interact with Terminus OR the CI can do all kinds of tasks via Terminus.

Is that not a valid use-case?

[greg-1-anderson]

Your use case might be convenient, but it is not supported. Installing Terminus via composer install is no longer supported; you should use the .phar or Homebrew. Also, even as a dev dependency, mixing Terminus with WordPress might happen to work right now, but it is not possible for us to guarantee that it will continue to work.

[greg-1-anderson]

Also, please note that older Terminus releases are supported for one year after the release date of the next following version. As such, using old versions of Terminus to work around this limitation is only going to be viable for a few more months. Please upgrade to a .phar release shortly, as the EOL date of the versions you are using is approaching.

[kasparsd]

Understood. Good to know that this is a deliberate decision.

Terminus and WordPress are separate PHP applications.

I personally see Terminus as a tool similar to webpack, phpcs or phpunit which are all "separate applications" but they can absolutely work within the same instance of Node or PHP environment and dependency tree.

What were the cases where you saw Terminus fail when added as a dependency along with WP or Drupal, if you don't mind sharing?

The only benefits of an isolated Phar would be the pure code/dependency isolation but it still suffers from having to work with the same shared PHP runtime with the same (potentially missing) extensions, config, etc. Was it the shared dependency tree that was causing most of the trouble?

[greg-1-anderson]

If we were going to support your use case, the way we would do it would be to rename the current project to something like pantheon-systems/terminus-app, and make a new project, pantheon-systems/terminus that bundles the Terminus phar and makes it available in vendor/bin via the Composer binary feature. This wouldn't be hugely difficult to do, but this pattern isn't really something we are particularly interested in encouraging.