WP-CLI CiviCRM Integration

[andyw]

Hi All,

I've been working on porting the drush-civicrm integration to wp-cli if anybody running Civi on Wordpress would like to try it out.

It is currently here:

https://github.com/andy-walker/wp-cli-civicrm/

Some generic instructions on running custom wp-cli commands here (probably placing civicrm.php in your php/commands directory is the best option)

https://github.com/wp-cli/wp-cli/wiki/Commands-Cookbook#loading

Supports the following commands:

wp civicrm api
wp civicrm cache-clear
wp civicrm install
wp civicrm upgrade-db
wp civicrm update-cfg 
wp civicrm enable-debug
wp civicrm upgrade
wp civicrm restore
wp civicrm rest   
wp civicrm sql-conf   
wp civicrm sql-connect
wp civicrm sql-dump
wp civicrm sql-query
wp civicrm sql-cli   
wp civicrm process-mail-queue
wp civicrm member-records

Options and arguments should be the same as for the equivalent drush commands, with the one exception of --tarfile on install and upgrade - that becomes --zipfile, as the Wordpress version of Civi is supplied in a zip file. Otherwise, see the drush-civicrm documentation for supported options / arguments.

Hope that's in some way useful,

Andy

 

[xavier]

Awesome, should it be part of the core?

I'm not familiar with wp-cli, does it handle authentication (eg you can specify to run the api as user X without having to provide the password?)
I found it very convenient on drupal to be able to run the cronjobs using the cli instead of the native civicrm wrapper, it might be something that could benefit as well WP users?

[andyw]

Hi Xavier,

More than happy to contribute that to core if people want it in core - also found one or two bugs in drush-civicrm in the process, so will submit some patches for those.

As far as running commands as a specific cms user, looks like it supports --user=<id|login>, according to here:

http://wp-cli.org/config/

So hopefully that should all work, although it's something I haven't tested yet.

Andy

[Kevin Cristiano]

Thanks for taking a crack at this.  I will test it and let you know what I find.

[totten]

This sounds really cool!

I think it would be great to include in core (or, specifically, civicrm-wordpress.git). FWIW, it would be also be a fine alternative to keep the separate repo and add "composer.json" ( https://github.com/wp-cli/wp-cli/wiki/Community-Packages ). There are a few trade-offs (based on experiences with civicrm.drush.inc):

 * Distributing it with civicrm-wordpress.git is easiest for developers. It's an existing repo with an existing build/publication process.
 * Distributing it with civicrm-wordpress.git is easiest for site-admins -- as long as the site-admin has the latest version and doesn't want to use "wp civicrm install". The installation steps would cancel most potential benefits of the "wp civicrm install" command (eg "Download the wp-cli-civicrm file; manually install it; then run "wp civicrm install"; then uninstall the manually-installed wp-cli-civicrm").
 * Distributing it with composer takes more work in the normal use-cases, but it works the same way regardless of Civi version (4.2, 4.4, master), and using "wp civicrm install" is slightly less ridiculous. It's also easier to release updates to wp-cli without a major Civi revision.

Any thoughts/preferences?

Aside: Regardless of how we decide to package it, I'd like to bundle this with the other CLI tools in buildkit ( https://github.com/civicrm/civicrm-buildkit ).

[andyw]

Hi totten,

Great! - glad that is hopefully going to be of use to a few people.

As regards packaging, I don't have any particular personal preference on that - there are pros and cons to both approaches, as you point out.

I think the install command really only becomes a time-saver if you're continually rolling out new sites / test sites on one server as we tend to do at Circle, otherwise, as you say, it's probably going to be easier to run the install via the UI.

We could also maybe do some stuff with class_exists() to ensure your manually installed version can co-exist with anything that comes bundled with Civi, that's if wp-cli doesn't already have a mechanism for resolving conflicts, which I haven't looked into - so that would at least preclude the last step of having to uninstall your manually installed version.

But I don't have any particular preference - whatever is going to work best for people at the end of the day. Have also asked our sysadmin if he has any thoughts on this.

And @kcristiano - thanks very much for testing this. We have done quite a lot of testing at our end, but there's always bound to be one or two situations we haven't considered, so let me know if you come across any problems.

All the best,

Andy

[Kevin Cristiano]

I had said I was going to check this out, it just took me much longer to get to than I thought.

It is working as expected on my 4.5 alpha site.  I do need to look at the REST command, but the others work fine.  I am curious what it would take to process the scheduled jobs via wp-cli much as drush can do for drupal.  I will take a look at this but any suggestions would be appreciated.

[xavier]

Hi,
processing jobs is just an api call, so if you get civicrm_api3 working, it's solved.

not sure what it the benefit of the REST command over the api one, I don't think it brings any extra features beside testing the rest interface itself.

[andyw]

Hi Kevin,

Hmm .. I was wondering why I missed that one - I thought I went through all the drush civicrm commands and implemented them all, but as xavier says, maybe you want to use the api for that.

Have you tried something like:

wp civicrm api job.execute

(may require some additional params for auth etc).

Unless there's some new drush civicrm command for that that I haven't come across, but I couldn't find any documentation on it if so.

Hope that helps,

Andy

[Kevin Cristiano]

Thanks for the reply.  I had tried that, but I am getting errors.  specifically

Code: [Select]

Array
(
    [is_error] => 1
    [error_message] => API (api, ) does not exist (join the API team and implement it!)
)

I'll take a closer look, I am assuming it has to do with parameters, I've tried:

wp civicrm api job.execute
wp --user=webmaster civicrm api job.execute
wp --user=webmaster civicrm api job.execute auth=0 -y
wp --user=webmaster --path={path to site} civicrm api job.execute auth=0 -y

I'll see what I can determine and report back here.  I am specifically interested in this as once it works, we can specify to only load civicrm and ignore all other plugins. 

[andyw]

Hi Kevin,

Possibly the --user=webmaster after wp is confusing the order of the arguments, from the look of that error.

Maybe try:

wp civicrm api job.execute auth=0 --user=webmaster

Andy

[Kevin Cristiano]

I missed this, but tried again today, still get the same error message.  I'll need to look at this closer.

Have you been able to get api job.execute to work?

[andyw]

Hi Kevin,

I've just taken a look - looks like a couple of lines of code ended up in the wrong order somehow. I've fixed that and committed the change to the Github repo - if you want to update your copy and give that a go now, I think that should work.

Also tested if the --user=webmaster part should go on the end or not - and it doesn't seem to matter.

Hope that helps,

Andy

[Kevin Cristiano]

Looks like this works now.  Thanks for the work here. I also found an issue on a client site where they had an ampersand '&' in the password, the mysqldump command just failed.  I have added quotes to the field to prevent this error in my copy.  I create a PR for this as well.

Thank you for all the work on this.  I'd love to see this in 4.5.  It would be very helpful for all users

[andyw]

Hi Kevin,

Sorry for not replying sooner - have had a bit of a manic week this week. But I will get round to that pull request - thanks for that, and yes, it'd be great to get it into an upcoming version of Civi - would be happy to do some more work to make that the case, so maybe if I drop totten a mail next week about that or something.

There was some discussion about whether to include it with Civi or make it available through composer (or possibly do both if that can be made to work without the two versions conflicting) - the main reasoning being the 'install' command presents a bit of a chicken and egg situation - ie: it doesn't become available until you install Civi, but you need it to be available in order to install Civi .. unless you install it through the UI, which then makes the command useless.

Distributing it through composer negates that problem, but is admittedly not quite as neat a solution as installing Civi and magically having all these commands become available. But I do also think the use case for the install command is a pretty limited one - I can't see too many people favouring it over installing through the UI.

Do you have any thoughts / preferences on that yourself?

Andy