What exactly does get pushed?

[intelligence]

I just setup capistrano-wpcli to push from local to stage.

Staging.rb

set :stage, :staging
server 'project.labs.domain.com', user: 'deploy', roles: %w{web app db}

fetch(:default_env).merge!(wp_env: :staging)

set :wpcli_remote_url, 'http://project.labs.domain.com/'
set :wpcli_local_url, 'http://project.dev/'
set :wpcli_args, 'staging'

When I push to stage I get no error messages

INFO[7386ee4b] Running /usr/bin/env wp db export - | gzip > /tmp/wpcli_database.sql.gz on localhost
INFO[7386ee4b] Finished in 0.008 seconds with exit status 0 (successful).
INFOUploading /tmp/wpcli_database.sql.gz 100.0%
INFO[4aad959f] Running /usr/bin/env gunzip < /tmp/wpcli_database.sql.gz | wp db import - on project.labs.domain.com
INFO[4aad959f] Finished in 0.153 seconds with exit status 0 (successful).
INFO[20c0aa98] Running /usr/bin/env rm /tmp/wpcli_database.sql.gz on project.labs.domain.com
INFO[20c0aa98] Finished in 0.056 seconds with exit status 0 (successful).
INFO[ba98b0a6] Running /usr/bin/env wp search-replace http://project.dev/ http://project.labs.domain.com/ staging on project.labs.domain.com
INFO[ba98b0a6] Finished in 0.785 seconds with exit status 0 (successful).
INFO[7b41a576] Running /usr/bin/env rm /tmp/wpcli_database.sql.gz on localhost
INFO[7b41a576] Finished in 0.006 seconds with exit status 0 (successful).

But if I check the staging site I cannot see any changes? The pages + settings on my local environment does not appear on the stage . What exactly should get pushed?

Could you please provide an example on how to set up the upload settings, what sort of path should be provided?

[Shaked]

+1 @intelligence

[bsadecki]

+1 @intelligence - Same here. I feel like I'm missing a big piece of the puzzle here.

[jeremyzahner]

Hey Guys.

I will respond on this one shortly.

Cheers

[cibulka]

Same here. :) Should I import the database to my PHPMyAdmin (or something alike) manually?

[jeremyzahner]

Okay all.

Could you try doing it without setting the http:// in front of the url and leave out the args.

So just

set :wpcli_remote_url, 'project.labs.domain.com' 
set :wpcli_local_url, 'project.dev' 

Maybe it has to do with the search and replace operation.

[jeremyzahner]

And: can you provide me with the whole output of the log please?

[jeremyzahner]

Also try it without the trailing slash!

[davestevens]

I faced a similar issue today where nothing was being pushed, it was due to the machine not having mysqldump installed. Technically nothing got pushed so the import didn't overwrite anything. I would suggest changing the capistrano log level to info to see more information about what it being pushed.

[davestevens]

Just had someone else with the same issue, notice the error only being displayed as a debug message.

INFO [9ff0116e] Running /usr/bin/env wp db export - | gzip > /tmp/wpcli_database.sql.gz as Christian@localhost
DEBUG [9ff0116e] Command: ( WP_ENV=staging /usr/bin/env wp db export - | gzip > /tmp/wpcli_database.sql.gz )
DEBUG [9ff0116e]    sh: mysqldump: command not found
INFO [9ff0116e] Finished in 0.293 seconds with exit status 0 (successful).

[christianmagill]

I'm having the same issue only everything shows as successful with log level info. Still no change to staging db.

$ bundle exec cap staging wpcli:db:push                                                                                                                                                                                     [17:07:51]
INFO[f6a2cdda] Running /usr/bin/env wp db export - | gzip > /tmp/wpcli_database.sql.gz on localhost
INFO[f6a2cdda] Finished in 0.110 seconds with exit status 0 (successful).
/Users/christianmagill/.rvm/gems/ruby-2.3.0/gems/net-ssh-2.9.1/lib/net/ssh/transport/session.rb:67:in `initialize': Object#timeout is deprecated, use Timeout.timeout instead.
/Users/christianmagill/.rvm/gems/ruby-2.3.0/gems/net-ssh-2.9.1/lib/net/ssh/transport/session.rb:84:in `initialize': Object#timeout is deprecated, use Timeout.timeout instead.
INFOUploading /tmp/wpcli_database.sql.gz 100.0%
INFO[7af53ac8] Running /usr/bin/env gunzip < /home/influe01/capistrano_tmp/wpcli_database.sql.gz | wp db import - on us17.siteground.us
INFO[7af53ac8] Finished in 0.334 seconds with exit status 0 (successful).
INFO[b596ffd6] Running /usr/bin/env rm /home/influe01/capistrano_tmp/wpcli_database.sql.gz on us17.siteground.us
INFO[b596ffd6] Finished in 0.141 seconds with exit status 0 (successful).
INFO[0661e08c] Running /usr/bin/env wp search-replace influencebydesign.dev staging.influencebydesign.com --skip-columns=guid on us17.siteground.us
INFO[0661e08c] Finished in 0.610 seconds with exit status 0 (successful).
INFO[ad2ea563] Running /usr/bin/env rm /tmp/wpcli_database.sql.gz on localhost
INFO[ad2ea563] Finished in 0.005 seconds with exit status 0 (successful).

[davestevens]

See my previous comment, in that case it seemed that the missing mysqldump wasn't being picked up as an error or suggesting any issues with info level logging.

Try running /usr/bin/env wp db export - standalone and see if that throws any errors.

[christianmagill]

Mysqldump is available both locally and on the server. When I run "wp db export" everything works as intended.

[davestevens]

Are you able to check the database on the staging server to see if the updated data is being transmitted at all? I've had issues previously with php-fpm having to be restarted before changes are being seen.

Is this something which was previously working and has now stopped or has it never worked? Have you tried with debug level logging to see if that points anything out?

[christianmagill]

Ah, it looks like gunzip is not available on the server.

[christianmagill]

My hosting company has recommended using gzip -d which is equivalent. @davestevens Any suggestions on how to best implement this change?

[davestevens]

I'm not entirely sure. You are able to use SSHKit.config.command_map to change commands but there is an issue of arguments here too.

Maybe you could setup an alias on the staging server of alias gzip-decompress="gzip -d" and then add SSHKit.config.command_map[:gunzip] = 'gzip-decompress' to your deploy/staging.rb file.

Edit: Actually, just reading, gunzip is technically a gzip with decompression. So you could possibly just use SSHKit.config.command_map[:gunzip] = 'gzip -d'.