Use WP Provisioner

[XedinUnknown]

The Problem

WP CLI is a great tool. However, it has some problems, and is not very flexible. Vagrant has Vagrantfile for configuration, which is plain Ruby. Grunt uses Gruntfile.js for configuration, which is plain JS. A more powerful approach to provisioning a WP installation would be great.

Suggested Solution

With dnaber-de/wp-provisioner, we can have a Wpfile.php that will provision WP in a very powerful, configurable, and granular way. The best way to add that repository to the project's composer.json is yet to be found.

[mecha]

So the current problem is that WP Provision cannot be executed from the root user - this is because it uses WP CLI internally which throws an error. WP CLI has the flag --allow-root to disable the error but WP Provisioner has no such flag.

My proposed solution is to avoid using the root user altogether and have the Vagrant script use a user made specifically to have ownership of Bedrock and its WordPress-related files and services.

[mecha]

I did some research and also checked what users are present via vagrant ssh and cut -d: -f1 /etc/passwd.

There is a vagrant user that, I can assume, Vagrant uses. Apart from a few special users, such as mysql, mongodb, postgres, blackfire, etc, there is no user being used by Bedrock to install WordPress.

Perhaps we can change this such that the provisioning script in the Vagrant file creates a bedrock or wp user (if it does not exist) and log into that to perform the installation. This would of course include WP Provisioner, which would solve the aforementioned problem and allow me to finish this issue.

[XedinUnknown]

@mecha, like you said, there's the vagrant user that Vagrant should be running the provisioning script as. Isn't this what's running the commands? And if not, why?

[mecha]

@XedinUnknown I do not know but there is no indication in the provisioning shell script that this is the user being used initially. All I know is that the root user is being used when the WordPress config is being set up.

Whether one of the previous commands switches to root or whether it is the root user that used from the start of the provisioning script is unknown yet. I propose that we either choose an existing user or create a new one and have the provisioning script switch to that user before doing anything else.

[XedinUnknown]

@mecha, the privileged option seems to be what were looking for. Please try changing this to false.

[XedinUnknown]

Unfortunately, the WP provision config file name is hardcoded to be provision.php.

[XedinUnknown]

Changes in 4b0fc6e52bf5accbaf685b5e517be0dbe83d4d41 appear to be obsolete. Despite the permissions now being rwx-rw-rw and the user/group being vagrant, WP Provisioner still complains that it is unable to access the provision file:

Provision file not exists or is not readable /var/www/web/provision.php

[XedinUnknown]

PHP confirmed to be running as vagrant:

$ php -r "echo shell_exec('whoami');"
vagrant