wordmove
wordmove copied to clipboard
Same DB, pull works, but push fails with (Wordmove::ShellCommandError)
Describe the bug Pulling the DB works with --hex-blob as MySQL dump option but when I try to push, it fails with:
▬▬ Pushing Database ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
remote | mysqldump --host=[secret] --user=partners_wp837 --password=*****)2 --result-file="[secret]/wp-content/dump.sql" --hex-blob partners_wp837
remote | gzip -9 -f "[secret]/wp-content/dump.sql"
remote | get: [secret]/wp-content/dump.sql.gz [secret]/wp-content/production-backup-1620193346.sql.gz
remote | delete: [secret]/wp-content/dump.sql.gz
local | mysqldump --host=[secret] --user=[secret] --password=[secret] --result-file="[secret]/wp-content/dump.sql" asm_db
mysqldump: [Warning] Using a password on the command line interface can be insecure.
local | Adapt dump
local | gzip -9 -f "[secret]/wp-content/dump.sql"
remote | put: [secret]/wp-content/dump.sql.gz [secret]/wp-content/dump.sql.gz
remote | gzip -d -f "[secret]/wp-content/dump.sql.gz"
remote | mysql --host=[secret] --user=partners_wp837 --password=*******)2 --database=partners_wp837 --execute="SET autocommit=0;SOURCE [secret]/wp-content/dump.sql;COMMIT"
/Users/moose/.rvm/rubies/ruby-3.0.1/lib/ruby/gems/3.0.0/gems/wordmove-5.2.1/lib/wordmove/deployer/ssh.rb:70:in `remote_run': Error code 1 returned by command "mysql --host=localhost --user=partners_wp837 --password=******)2 --database=partners_wp837 --execute="SET autocommit=0;SOURCE /home/partnerscyberize/public_html/wp-content/dump.sql;COMMIT"": mysql: [Warning] Using a password on the command line interface can be insecure. (Wordmove::ShellCommandError)
ERROR at line 1528 in file: '/home/partnerscyberize/public_html/wp-content/dump.sql': Unknown command '\\0'.
from /Users/moose/.rvm/rubies/ruby-3.0.1/lib/ruby/gems/3.0.0/gems/wordmove-5.2.1/lib/wordmove/deployer/ssh.rb:93:in `import_remote_dump'
from /Users/moose/.rvm/rubies/ruby-3.0.1/lib/ruby/gems/3.0.0/gems/wordmove-5.2.1/lib/wordmove/deployer/ssh/default_sql_adapter.rb:15:in `adapt_local_db!'
from /Users/moose/.rvm/rubies/ruby-3.0.1/lib/ruby/gems/3.0.0/gems/wordmove-5.2.1/lib/wordmove/deployer/ssh.rb:38:in `push_db'
from /Users/moose/.rvm/rubies/ruby-3.0.1/lib/ruby/gems/3.0.0/gems/wordmove-5.2.1/lib/wordmove/cli.rb:116:in `block in push'
from /Users/moose/.rvm/rubies/ruby-3.0.1/lib/ruby/gems/3.0.0/gems/wordmove-5.2.1/lib/wordmove/cli.rb:40:in `block in handle_options'
from /Users/moose/.rvm/rubies/ruby-3.0.1/lib/ruby/gems/3.0.0/gems/wordmove-5.2.1/lib/wordmove/cli.rb:39:in `each'
from /Users/moose/.rvm/rubies/ruby-3.0.1/lib/ruby/gems/3.0.0/gems/wordmove-5.2.1/lib/wordmove/cli.rb:39:in `handle_options'
from /Users/moose/.rvm/rubies/ruby-3.0.1/lib/ruby/gems/3.0.0/gems/wordmove-5.2.1/lib/wordmove/cli.rb:115:in `push'
from /Users/moose/.rvm/rubies/ruby-3.0.1/lib/ruby/gems/3.0.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
from /Users/moose/.rvm/rubies/ruby-3.0.1/lib/ruby/gems/3.0.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
from /Users/moose/.rvm/rubies/ruby-3.0.1/lib/ruby/gems/3.0.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
from /Users/moose/.rvm/rubies/ruby-3.0.1/lib/ruby/gems/3.0.0/gems/thor-0.20.3/lib/thor/base.rb:466:in `start'
from /Users/moose/.rvm/rubies/ruby-3.0.1/lib/ruby/gems/3.0.0/gems/wordmove-5.2.1/exe/wordmove:6:in `<top (required)>'
from //Users/moose/.rvm/rubies/ruby-3.0.1/bin/wordmove:23:in `load'
from //Users/moose/.rvm/rubies/ruby-3.0.1/bin/wordmove:23:in `<main>'
from //Users/moose/.rvm/rubies/ruby-3.0.1/bin/ruby_executable_hooks:22:in `eval'
from //Users/moose/.rvm/rubies/ruby-3.0.1/bin/ruby_executable_hooks:22:in `<main>'
Wordmove command
Command used on the CLI: (e.g.: wordmove pull --all --no-db
)
wordmove push -d
Expected behavior
A clear and concise description of what you expected to happen.
Cannot push DB to the remote server thus cannot finish WP deployment
Please help!!
movefile.yml
Paste (removing personal data) the interesting part, if any, of your movefile.yml
formatting it inside a code block with yml
syntax and double checking the indentation.
global:
sql_adapter: default
local:
vhost: http://asm.local
wordpress_path: /Volumes/HDD50GB/_WEBSITES/ASM-FINAL # use an absolute path here
database:
name: asm_db
user: root
password: "root" # could be blank, so always use quotes around
host: localhost
production:
vhost: https://***************.com
wordpress_path: /home/************/public_html
database:
name: **********
user: **********
password: ********
host: localhost
# mysqldump_options: "--hex-blob --default-character-set=utf8"
mysqldump_options: '--hex-blob' # pull fails without it, push fails with it
# port: 3308 # Use just in case you have exotic server config
# mysqldump_options: '--max_allowed_packet=1G' # Only available if using SSH
# mysql_options: '--protocol=TCP' # mysql command is used to import db
exclude:
- '.git/'
- '.gitignore'
- '.gitmodules'
- '.env'
- 'node_modules/'
- 'bin/'
- 'tmp/*'
- 'Gemfile*'
- 'Movefile'
- 'movefile'
- 'movefile.yml'
- 'movefile.yaml'
- 'wp-config.php'
- 'wp-content/*.sql.gz'
- '*.orig'
# paths: # you can customize wordpress internal paths
# wp_content: wp-content
# uploads: wp-content/uploads
# plugins: wp-content/plugins
# mu_plugins: wp-content/mu-plugins
# themes: wp-content/themes
# languages: wp-content/languages
ssh:
host: ****artners.com
user: ****erize
Exception/trace Paste (removing personal data) the entire trace of error/exception you encountered, if any
Environment (please complete the following information):
Mac OSX 10.14 ruby 3.0.1p64 (2021-04-05 revision 0fb782ee38) [x86_64-darwin18] wordmove version 5.2.1
Doctor
- [x]
wordmove doctor
is all green Don't know what that is ... (If it is not, report the error you got.)
I know it has been a long time... sory about that.
I'd try to
production:
database:
mysql_options: "--binary-mode"
and see what happens.
Ref: https://dev.mysql.com/doc/refman/8.0/en/mysql-command-options.html#option_mysql_binary-mode
Please be sure to backup the production DB manually before to attempt
Not sure if it's a bug or just a matter of dealing with specific mysql pains 😛 thus I'm updating the label to Triage. If feedback will happens we'll have the chance to consolidate it as bug again.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.