Create a wp-cli.yml file

[dnaber-de]

What do you think about creating a wp-cli.yml in the project root to specify the path to WP core. The content would just look like that:

path: <wordpress-install-dir>

It would allow to use WP-CLI from the same working directory as one would use composer from. Otherwise you have to change directory to the WP root or specify a parameter on each command.

Edit: The local copy of this file should then go to the .gitignore: wp-cli.local.yml

[franz-josef-kaiser]

@dnaber-de Something like you can see in d84cdf9 ?

[franz-josef-kaiser]

The steps can get tested by checking out the issue-33-wp-cli-yaml branch. Feature proposed as in b40379b.

[franz-josef-kaiser]

There are even more possible configuration values. We might want to allow those as well. Possible ways to add them:

• Add WP_CLI_ vars to .env
• Prompt in the CLI
• Add a separate configuration file
• Make everything that is possible and can be assumed a default inside wp-cli.yml.example
• …

If we do that, I'd vote for the WP_CLI_ prefixed vars inside the .env file. Reason is that some of the values might be easy to extract from already existing options. We could also just use WP_CLI_FOO=${WP_FOO} to alias them per default. This would make it easy and transparent for users to find and understand possible configurations for WP CLI.

Another thing that needs discussion is the correct path to use for the wp-cli.yml file. Currently I just placed it in the /public-root. Maybe we should go with the last option before WP CLI falls back to defaults to leave users with two more "escalation" levels (regarding over-ruling wp-cli.yml files): the WP_CLI_CONFIG_PATH environment variable. We could set this one to ${WP_INSTALL_PATH} or ${WP_HOME} in the .env.example file to have a default-default.

[dnaber-de]

About the correct path for wp-cli.yml: in my opinion this should be the project root (the same as for composer.json and .env.example. To overwrite this default path, there could be another option in the WPStarter extra section of the composer configuration.

About the other configuration values of WP-CLI: the only option that depends on the setup of WPStarter is the path key. Everything else is not related to WPStarter and thus we would just pass some values through (wherever they will be defined). I would suggest to handle the wp-cli.yml as the other generatoed files (e.g. .gitignore): overwrite them on every update unless they are listed in the prevent-overwrite option. A user could either create a copy of that generated file (wp-cli.local.yml) or add it to prevent-overwrite. I would consider it rather seldom that someone changes the WP install path after a project launch. However this would be the one situation that requires the user to update their configuration if it's protected from override.

[franz-josef-kaiser]

@dnaber-de Thanks for the update. Could you check out the branch and give it a test ride if you got some time?

[dnaber-de]

That looks pretty promising

$ composer update
Loading composer repositories with package information
Updating dependencies (including require-dev)                                    
  - Removing wecodemore/wpstarter (2.3.2)
  - Installing wecodemore/wpstarter (dev-issue-33-wp-cli-yaml b40379b)
    Cloning b40379bc92f57341d06944562e75185e6330bcb4 from cache

Writing lock file
Generating autoload files
> WCM\WPStarter\Setup::run
  WP Starter is going to start installation...
  - OK All paths recognized.
  - OK wp-config.php saved successfully.
  - OK index.php saved successfully.
  - .gitignore exists and will be preserved.
  - OK wp-cli.yml saved successfully.


    .gitignore was found in your project folder.       
    Be sure to ignore .env and wp-config.php files.    



    WP Starter finished successfully!    

But for some reason the wp-cli.yml is not placed in the root directory. Is that intended?

$ find . -name wp-cli.yml
public/wp-cli.yml

This is my WPStarter config:

"extra": {
        "wordpress-install-dir": "public/wp",
        "wordpress-content-dir": "public/wp-content",
        "installer-paths": {
            "public/wp-content/plugins/{$name}/": [ "type:wordpress-plugin" ],
            "public/wp-content/themes/{$name}/": [ "type:wordpress-theme" ]
        },
        "wpstarter": {
            "register-theme-folder": false,
            "prevent-overwrite": [ ".gitignore" ]
        }
    }

However, If I change to public/ and run wp site list I see an error:

/public$ wp site list
Error: This does not seem to be a WordPress install.
Pass --path=`path/to/wordpress` or run `wp core download`.

The content of the generated wp-cli.yml:

path: /var/www/my-project-repo/public

but it should be

path: /var/www/my-project-repo/public/wp

according to my configuration.

[franz-josef-kaiser]

Fixed with 1a422cb. The target dir for the wp-cli.yml should now be at …/public/wp. First, I forgot that the path in the wp-cli.yml should change as well. This is fixed with f63ceda.

To test this, I ran a quick test and can confirm that both the location inside and the file itself are generated properly. @dnaber-de Could you please try again?

[dnaber-de]

Now, the path inside wp-cli.yml is correct, also the prevent-overwrite config works if I add "*/wp-cli.yml".

However, the path where you place the wp-cli.yml file makes no sense. The idea is to tell WP-CLI where to find WordPress in the file system from your current working directory if this is not the WP install directory. (If your current working directory is a WordPress install, WP-CLI will recognize this anyway).

Example:

$ cd /path/to/your-project && ls -al
-rw-rw-r--  1 david david   6339 Aug 16 19:00 composer.json
-rw-rw-r--  1 david david 111816 Aug 16 18:47 composer.lock
-rw-rw-r--  1 david david   9848 Jul 26 15:56 .env
drwxrwxr-x  8 david david   4096 Aug 16 19:00 .git/
-rw-rw-r--  1 david david     81 Jul  7 15:35 .gitignore
drwxrwxr-x  4 david david   4096 Aug 16 18:55 public/
-rw-rw-r--  1 david david  16828 Aug 16 12:30 README.md
drwxrwxr-x 21 david david   4096 Aug 16 19:00 vendor/

This is a typical repository of a WPStarter project. (WP install directory is public/wp.) Now if I change the working directory to public/ or even public/wp/ a WP-CLI command would detect the WP install anyway. The idea of the new wp-cli.yml is to be able to run WP-CLI directly from the root directory of the project. Therefore it should be placed in the project root.

Long story short, WPCliStep::targetPath should look like:

    public function targetPath( ArrayAccess $paths )
    {
        return rtrim( $paths['root'], "/" )."/wp-cli.yml";
    }

Just tested it locally and it works as expected.

Edit By the way, the file WPCliStep is indented by tabs, not by spaces.

[GaryJones]

FWIW, https://github.com/bradp/vv already creates a wp-cli.yml file for VVV installs.

[franz-josef-kaiser]

@dnaber-de Changed with cdf1557.

[franz-josef-kaiser]

@Giuseppe-Mazzapica where do we go with this? New milestone 3.0.*? Or abandon it?

[dnaber-de]

I still owe you a comment on the last fix. Didn't found time to test it yet.

[franz-josef-kaiser]

@dnaber-de No worries. Actually I overread the change in labels and did not see the assigned projects from @Giuseppe-Mazzapica. I moved the status to in progress. Would be nice if you can test it so we can merge and close it.

[franz-josef-kaiser]

We might consider adding the following lines as Composer is used to manage packages:

disabled_commands:
  - plugin install
  - plugin uninstall
  - plugin update
  - theme install
  - theme update

[dnaber-de]

That seems convenient. I would limit it to these (and not disallow core language update as this is something where no really comfortable composer solution exists yet).