Disable multisite constants while checking wp core is-installed

[fullyint]

Fixes #554: WordPress database error Table 'name' doesn't exist
The error happens on a first deploy of multisite -- before multisite is installed.

When MULTISITE=>true and the database tables don't yet exist, WordPress will error before WP-CLI can execute --reference

The mysql_db module doesn't allow checking presence of tables as far as I could tell. I didn't manage to come up with any satisfactory CLI commands to inline a mysql query or php command to check the DB tables. Suggestions welcome.

This PR dynamically comments out the MULTISITE and SUBDOMAIN_INSTALL constants, allows WP-CLI to check wp core is-installed, then immediately re-enables the constants.

I removed the --network option from the is-installed command because it yields RC: 1 when the multisite constants are absent. (This PR makes the constants absent during the is-installed check.)

This PR assumes the location of multisite constants in config/application.php, a bedrock directory structure. If that is not a safe assumption, I suppose we could add a task that checks whether the file exists then make conditional the tasks that disable the multisite constants.

[swalkinshaw]

Would this help? http://wp-cli.org/commands/db/query/

[fullyint]

The problem is that we can't use WP-CLI because it can't even load. Under these conditions WordPress fails to load before WP-CLI can do anything.

[QWp6t]

if those were environment variables (i.e., in .env), you could easily override by setting the env var before loading wp-cli since phpdotenv doesn't override existing environment variables.

then the user's directory structure wouldn't matter, but the user wouldn't be able to hard-code those values.

🤔

[nathanielks]

I've also run into this. My hack was to install WP in the finalize-before step

[fullyint]

I've updated this PR but also posted an alternative in #765. Both follow @QWp6t's suggestion:

if those were environment variables (i.e., in .env), you could easily override by setting the env var before loading wp-cli since phpdotenv doesn't override existing environment variables.

then the user's directory structure wouldn't matter, but the user wouldn't be able to hard-code those values.

Both PRs expect that users have added these lines to site/config/application.php:

define('MULTISITE', env('MULTISITE') ?? true);
define('SUBDOMAIN_INSTALL', env('SUBDOMAIN_INSTALL') ?? true); // Set to false if using subdirectories

This PR retains the regular multisite.enabled and multisite.subdomains settings in wordpress_sites, using those values to create corresponding default env vars. #765 drops the former settings, consolidating all multisite config in the env vars only.

This PR added a default path_current_site env var based on multisite.base_path because it looked like those two values should be aligned.

[swalkinshaw]

is shell needed for ENV vars?

Ansible does support environment: http://docs.ansible.com/ansible/playbooks_environment.html

[nathanielks]

I do believe so as `command` is not run in a shell environment. You have to pass them into the task itself

…

On Feb 19, 2017 9:44 AM, "Scott Walkinshaw" ***@***.***> wrote: ***@***.**** commented on this pull request. ------------------------------ In roles/deploy/hooks/finalize-after.yml <#754 (comment)>: > @@ -1,6 +1,6 @@ --- - name: WordPress Installed? - command: wp core is-installed {{ project.multisite.enabled | default(false) | ternary('--network', '') }} + shell: MULTISITE=false SUBDOMAIN_INSTALL=false wp core is-installed is shell needed for ENV vars? Ansible does support environment: http://docs.ansible.com/ ansible/playbooks_environment.html — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#754 (review)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AATKmRan542vQrmd3yqz-iiGnXq6yRpnks5reH-ZgaJpZM4L_CLS> .

[fullyint]

Thank you @swalkinshaw and others for the review, and @swalkinshaw for the idea that wp-cli could --require a file with temporary overrides for the multisite constants. This require loads before WP loads, so it prevents the problem that WP won't load when multisite constants are true.

I've reverted again 😅 and added a commit with just this --require strategy. Of course, we'll need to squash before merging.

I added error_reporting(E_ALL & ~E_NOTICE); to the --require file to avoid having the is-installed task show in red PHP Notice: Constant MULTISITE already defined (even though task status is ok).

[swalkinshaw]

This can just be a plain file with a copy right?

[fullyint]

Latest edits submitted in fresh uncluttered PR: #766