Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to use './wp-cli.phar' instead of 'wp' command? #18

Closed
ezekg opened this issue Feb 5, 2015 · 10 comments
Closed

Option to use './wp-cli.phar' instead of 'wp' command? #18

ezekg opened this issue Feb 5, 2015 · 10 comments
Assignees
Milestone

Comments

@ezekg
Copy link

ezekg commented Feb 5, 2015

Some of my clients use shared hosting (Godaddy), so I'm not able to install the bin/ executable, unfortunately. Is there a option I can use to execute a local ./wp-cli.phar file instead? If not, would you be interested in a pull request?

@ezekg ezekg changed the title Flag to use './wp-cli.phar' instead of 'wp' command? Option to use './wp-cli.phar' instead of 'wp' command? Feb 5, 2015
@ezekg
Copy link
Author

ezekg commented Feb 5, 2015

I was able to work around it by writing a small bash script that falls back to the .phar file if available. Reason being, if you map a command for one server, it does it for all of them. This includes local dev environments.

# Use .phar file if bin/ executable is not available
#
#  This is useful whenever you're using a host that
#  doesn't let you install executables
#
{ wp: "wp-cli.phar" }.each do |cmd, exe|
    SSHKit.config.command_map[:"#{cmd}"] = "$(if [ $(which #{cmd}) ]; then echo '#{cmd}'; else echo 'php #{shared_path.join(exe)}'; fi)"
end

@soullivaneuh
Copy link
Contributor

I did the trick with the default env:

set :default_env, {
  path: [
    "#{release_path}/bin", # Your composer bin folder
    "$PATH"
    ].join(":")
}

But works only if setted on env config file, not main deploy.rb.

@davestevens
Copy link
Contributor

I am also having an issue with this, unfortunately it seems that the commands are only replaced at the front of the execute method, so execute :gunzip, "<", fetch(:wpcli_remote_db_file), "|", :wp, :db, :import, "-" doesn't work on my shared hosting because its not being replaced with anything.

For a workaround I can unzip the file and then import it, but that required making another file and having to clean up both the compressed and decompressed files.

@soullivaneuh
Copy link
Contributor

Any new about this issue?

@ezekg is possible to make a PR for that?

davestevens added a commit to davestevens/capistrano-wpcli that referenced this issue Jun 18, 2015
SSKKit only allows using `command_map` on the first argument of the
`execute` method.
Trying to use this on a shared staging environment where I am unable to
install `wp` as a global command resulted in using:
```ruby
SSHKit.config.command_map[:wp] = "$(if [ $(which wp) ]; then echo 'wp'; else echo 'php55-cli #{shared_path.join(wp-cli.phar)'; fi)"
```
(See lavmeiker#18)
@jeremyzahner
Copy link
Collaborator

Has anyone of you found a valuable workaround?

1 similar comment
@cibulka
Copy link

cibulka commented Sep 17, 2015

Has anyone of you found a valuable workaround?

@jeremyzahner
Copy link
Collaborator

I will work on a solution to install the wp-cli.phar into the shared folder and use it from there if no wp-cli is installed on the remote system. See here: https://github.com/lavmeiker/capistrano-wpcli/milestones/LUX

@jeremyzahner jeremyzahner added this to the Deployment Improvements milestone Sep 22, 2015
@jeremyzahner jeremyzahner self-assigned this Sep 22, 2015
davestevens added a commit to davestevens/capistrano-wpcli that referenced this issue Sep 22, 2015
SSKKit only allows using `command_map` on the first argument of the
`execute` method.
Trying to use this on a shared staging environment where I am unable to
install `wp` as a global command resulted in using:
```ruby
SSHKit.config.command_map[:wp] = "$(if [ $(which wp) ]; then echo 'wp'; else echo 'php55-cli #{shared_path.join(wp-cli.phar)'; fi)"
```
(See lavmeiker#18)
@cibulka
Copy link

cibulka commented Oct 9, 2015

Are there any updates on this? Right now I get those errors, so it seems, that there definitely was some progress. :)

| => bundle exec cap production wpcli:db:pull
INFO[601ce078] Running /home/web720/wp-cli.phar db export - | gzip > /home/web720/capistrano-tmp/wpcli_database.sql.gz on 81.91.83.149
INFO[601ce078] Finished in 1.154 seconds with exit status 0 (successful).
INFODownloading /tmp/wpcli_database.sql.gz 50.23%
INFODownloading /tmp/wpcli_database.sql.gz 100.0%
INFO[ec51f6e9] Running /usr/bin/env rm /home/web720/capistrano-tmp/wpcli_database.sql.gz on 81.91.83.149
INFO[ec51f6e9] Finished in 0.250 seconds with exit status 0 (successful).
INFO[420060b2] Running /usr/bin/env gunzip -c /tmp/wpcli_database.sql.gz > /tmp/wpcli_database.sql on localhost
INFO[420060b2] Finished in 0.106 seconds with exit status 0 (successful).
INFO[5926342a] Running /home/web720/wp-cli.phar db import /tmp/wpcli_database.sql on localhost
cap aborted!
SSHKit::Command::Failed: wp exit status: 32512
wp stdout: Nothing written
wp stderr: sh: /home/web720/wp-cli.phar: No such file or directory
/Users/Cibulka/.rvm/gems/ruby-2.1.2/gems/sshkit-1.5.1/lib/sshkit/command.rb:97:in `exit_status='
/Users/Cibulka/.rvm/gems/ruby-2.1.2/gems/sshkit-1.5.1/lib/sshkit/backends/local.rb:56:in `block in _execute'
/Users/Cibulka/.rvm/gems/ruby-2.1.2/gems/sshkit-1.5.1/lib/sshkit/backends/local.rb:37:in `tap'
/Users/Cibulka/.rvm/gems/ruby-2.1.2/gems/sshkit-1.5.1/lib/sshkit/backends/local.rb:37:in `_execute'
/Users/Cibulka/.rvm/gems/ruby-2.1.2/gems/sshkit-1.5.1/lib/sshkit/backends/local.rb:26:in `execute'
/Users/Cibulka/.rvm/gems/ruby-2.1.2/bundler/gems/capistrano-wpcli-463d5e0418ba/lib/capistrano/tasks/wpdb.rake:52:in `block (4 levels) in <top (required)>'
/Users/Cibulka/.rvm/gems/ruby-2.1.2/gems/sshkit-1.5.1/lib/sshkit/backends/local.rb:14:in `instance_exec'
/Users/Cibulka/.rvm/gems/ruby-2.1.2/gems/sshkit-1.5.1/lib/sshkit/backends/local.rb:14:in `run'
/Users/Cibulka/.rvm/gems/ruby-2.1.2/gems/sshkit-1.5.1/lib/sshkit/dsl.rb:10:in `run_locally'
/Users/Cibulka/.rvm/gems/ruby-2.1.2/bundler/gems/capistrano-wpcli-463d5e0418ba/lib/capistrano/tasks/wpdb.rake:48:in `block (3 levels) in <top (required)>'
/Users/Cibulka/.rvm/gems/ruby-2.1.2/gems/capistrano-3.2.1/lib/capistrano/application.rb:15:in `run'
/Users/Cibulka/.rvm/gems/ruby-2.1.2/gems/capistrano-3.2.1/bin/cap:3:in `<top (required)>'
/Users/Cibulka/.rvm/gems/ruby-2.1.2/bin/cap:23:in `load'
/Users/Cibulka/.rvm/gems/ruby-2.1.2/bin/cap:23:in `<main>'
Tasks: TOP => wpcli:db:pull
(See full trace by running task with --trace)

Weird thing is, that /home/web720/wp-cli.phar definitely exist on my production environment.

This is relevant part of my deploy/production.rb config file:

SSHKit.config.command_map[:wp] = "/home/web720/wp-cli.phar"

Any ideas? Thanks in advance!

@jeremyzahner
Copy link
Collaborator

This is pushed to the lux branch right now.

You are now able to easily set the location of the wp-cli.phar file via i.e.:

SSHKit.config.command_map[:wp] = "php #{shared_path}/wp-cli.phar"

Will release it shortly.

@cibulka
Copy link

cibulka commented Oct 12, 2015

Awesome, works for me!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants