WIP - Support for WordPress example repo #39
Conversation
|
We also need to make an |
src/Commands/BuildToolsCommand.php
Outdated
| // or 'Drupal 7' or 'WordPress' | ||
| // return 'Drupal 8'; | ||
| if (file_exists($siteDir . '/wp-cli.yml')) { | ||
| return 'WordPress'; |
There was a problem hiding this comment.
I created a new empty upstream w/ the framework set to 'wordpress' named 'Empty WordPress'
src/Commands/BuildToolsCommand.php
Outdated
| return 'WordPress'; | ||
| } | ||
| else { | ||
| // This upstream works for Drupal 8 and Drupal 7. |
There was a problem hiding this comment.
Actually, 'Empty Upstream' only works for Drupal 8. I made another upstream named 'Empty 7' for Drupal 7. Maybe test for "$siteDir/web/misc/drupal.js" as an indicator that the site is Drupal 7.
src/Commands/BuildToolsCommand.php
Outdated
| return 'Empty Upstream'; | ||
| // or 'Drupal 7' or 'WordPress' | ||
| // return 'Drupal 8'; | ||
| if (file_exists($siteDir . '/wp-cli.yml')) { |
There was a problem hiding this comment.
Maybe test for "$siteDir/web/wp-admin/index.php"?
There was a problem hiding this comment.
The Composer-based way of doing WordPress moves wp-admin too. In our example it is web/wp/wp-admin. I don't think we can assume that. I'm leaning toward web/wp-config.php. @ataylorme, do you have thoughts on what file would be the best to check for to determine if a repo is WordPress?
There was a problem hiding this comment.
web/wp-config.php sounds like a good option to me. Worst case, we could test two locations (e.g. web/wp/wp-admin/index.php and web/wp-admin/index.php). I don't think it's a problem to put a limitation on where WordPress can be relocated to (e.g. wp or nothing).
If testing wp-config.php sidesteps this issue, even better.
| return 'Empty Upstream'; | ||
| // or 'Drupal 7' or 'WordPress' | ||
| // return 'Drupal 8'; | ||
| if (file_exists($siteDir . '/web/wp-config.php')) { |
There was a problem hiding this comment.
@stevector and @greg-1-anderson WordPress will first look for wp-config.php wherever core is. If WordPress core is in a subdirectory, say wp, then web/wp/wp-config.php will take precedence over web/wp-config.php if it exists.
That tripped me up when first implementing WordPress is a subdirectory via Composer as the Pantheon WordPress upstream includes wp-config.php. When installing core from our upstream repo into a subdirectory web/wp/wp-config.php must be deleted.
All that being said someone could have web/wp/wp-config.php, or wherever they have installed WordPress core, without web/wp-config.php and have a properly working site. I think it's okay for us to be opinionated about using wp for the directory name as well as having wp-config.php live in the we docroot.
There was a problem hiding this comment.
A variant of this line was already committed as part of a separate PR. We could check for both web/wp-config.php and web/wp/wp-config.php, or test some file that is always in the docroot, even when core is relocated, if such a candidate exists.
There was a problem hiding this comment.
I think we should use something like find -maxdepth 2 -type f -name 'wp-config.php rather than hard-coding directories or guessing what subdirectory will have WordPress core.
|
#60 Is a switch to Circle 2 that tests D8 and WordPress. |
|
Closing in favor of #60. |
Here is a work-in-progress PR to replace #9
This PR should not be merged until
SOURCE_COMPOSER_PROJECT(My thought is to use a matrix of variable in Travis). Related to Testing strategy for permutations of external git hosts / CI services / CMS versions #5stevector/example-wordpress-composertopantheon-systems/example-wordpress-composer, a task which has its own set of issues.