Database does not load on remote server when pushing from local

[mikemuller]

Describe the bug

I am able to push themes and plugins from my local to the remote server. When I try to push the database from local to remote everything looks like it runs correctly but the database does not push up for some reason.

A clear and concise description of what the bug is.

Wordmove command

I am running wordmove push -d

Command used on the CLI: (e.g.: wordmove pull --all --no-db)

Expected behavior

A clear and concise description of what you expected to happen.

movefile.yml

global:
  sql_adapter: wpcli

local:
  vhost: http://wordmove.local
  wordpress_path: /Users/mikemuller/Sites/wordmove/app/public/ # use an absolute path here

  database:
    name: local
    user: root
    password: "root" # could be blank, so always use quotes around
    host: localhost
    # port: 3306
    # mysqldump_options: "--max_allowed_packet=50MB" # Only available if using SSH
    # mysql_options: --protocol=TCP # mysql command is used to import db

production:
  vhost: https://wordpress-224221-2442886.cloudwaysapps.com
  wordpress_path: /home/224221.cloudwaysapps.com/xayfugwwrk/public_html # use an absolute path here

  database:
    name: xxx
    user: xxx
    password: xxx
    host: localhost
    # port: '3306' # 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: 167.99.231.221
    user: wordmove
    # password: "<%= ENV['PROD_SSH_PASS'] %>" # password is optional, will use public keys if available.
    port: 22 # Port is optional
    # rsync_options: '--verbose --itemize-changes' # Additional rsync options, optional
  #   gateway: # Gateway is optional
  #     host: host
  #     user: user
  #     password: password # password is optional, will use public keys if available.

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.

Exception/trace

Paste (removing personal data) the entire trace of error/exception you encountered, if any

Environment (please complete the following information):

• OS:
• Mac 12.2.1
• Ruby: (ruby --version)
• ruby 2.6.8p205
• Wordmove: (wordmove --version)
• 5.2.2

Doctor

Everything is green

• running the wordmove doctor command returns all green

(If it is not, report the error you got.)

Below is the terminal output when pushing:

mikemuller@Mikes-M1-MacBook-Pro public % wordmove push -d

    ℹ️  info | Using .env file: ./.env

▬▬ Using Movefile: ./movefile.yml ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

▬▬ Pushing Database ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

   remote | mysqldump --host=[secret] --user=xayfugwwrk --password=[secret] --result-file="[secret]/wp-content/dump.sql" xayfugwwrk
wordmove@167.99.231.221's password:

   remote | gzip -9 -f "[secret]/wp-content/dump.sql"

   remote | get: [secret]/wp-content/dump.sql.gz [secret]wp-content/production-backup-1644871026.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" local
mysqldump: [Warning] Using a password on the command line interface can be insecure.

    local | adapt dump for vhost

    local | wp search-replace --path=[secret] [secret] [secret] --quiet --skip-columns=guid --all-tables --allow-[secret]

    local | adapt dump for wordpress_path

    local | wp search-replace --path=[secret] [secret] [secret] --quiet --skip-columns=guid --all-tables --allow-[secret]

    local | mysqldump --host=[secret] --user=[secret] --password=[secret] --result-file="[secret]wp-content/search_replace_dump.sql" local
mysqldump: [Warning] Using a password on the command line interface can be insecure.

    local | gzip -9 -f "[secret]wp-content/search_replace_dump.sql"

   remote | put: [secret]wp-content/search_replace_dump.sql.gz [secret]/wp-content/dump.sql.gz

   remote | gzip -d -f "[secret]/wp-content/dump.sql.gz"

   remote | mysql --host=[secret] --user=xayfugwwrk --password=[secret] --database=xayfugwwrk --execute="SET autocommit=0;SOURCE [secret]/wp-content/dump.sql;COMMIT"

   remote | delete: [secret]/wp-content/dump.sql

    local | delete: '[secret]wp-content/search_replace_dump.sql.gz'

    local | mysql --host=[secret] --user=[secret] --password=[secret] --database=local --execute="SET autocommit=0;SOURCE [secret]wp-content/dump.sql;COMMIT"
mysql: [Warning] Using a password on the command line interface can be insecure.

    local | delete: '[secret]wp-content/dump.sql'

[alessandro-fazzi]

Wordmove is doing correctly all its things, so it's hard to track.

From my triageing experience this scenario is often due to different table prefixes in local and in remote. Wordmove does not change tables name, thus it could happen that

• you have wp_ prefix locally
• you have wp_ytw615_ remotely
• tables are correctly updated and trasferred
• you'll end having duplicated tables remotely, one per prefix
• your remote WP continues - as expected - connecting to tables with its configured tables

In order to use wordmove you have to have equals prefixes both locally and remotely. You can choose to update you local DB, or to change the remote prefix. But be sure to take a look to the remote database for an eventual cleanup.

Hope it helps.

Lemme know.

[stale]

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.