Closed frontenddevguy closed 6 years ago
I have been using Wordmove on a couple of sites (and just relying on WP Sync DB for database).
I noticed that one part of my movefile had curly quotes, and changing those seems to have removed that 2005 error. However, now pushing the db gives: /usr/local/lib/ruby/gems/2.4.0/gems/wordmove-2.1.3/lib/wordmove/sql_adapter/default.rb:45:in `gsub!': invalid byte sequence in UTF-8 (ArgumentError)
The rest of the output looks ok, but there is no dump.sql in wp-content
It seems to have gone a bit quiet in here lately..! Really grateful for the amazing features you guys are providing though :)
I have the same error:
mysqldump: Got error: 2005: Unknown MySQL server host 'localhost:8888' (0) when trying to connect
@frontenddevguy I think you made it works, but you encountered on the oldest Wormdove's dilemma in hi s history. We have a bookshop split between issues and wiki about the gsub!': invalid byte sequence in UTF-8 (ArgumentError)
😄
The long story short is: you have non UTF8 chars in the db, and Wordmove will refuse to handle the problem because it's risky. But we have introduced alternative database adapters to solve the problem and I'd advice you to try out the wpcli
one. Head to the documentation to understand more and be sure to have wp-cli installed before to start.
Note: in the docs we say it is experimental, but internally we are using that configuration on all active projects and I can assure it is working like a charm ;)
Let me know if it solves
Hi @nailbrain ,
sorry for the bug delay, but no one from the core team can be active on this project these times... :(
I really think you problem is of another kind: you have localhost:8080
in you Movefile
as database host, but it is nearly impossible or at least really really strange. on 8080
you should have the web server. If you run MySQL on the standard port, you can just wipe out the port from that config.
Keep in mind: database host and site host (vhost in our Movefile) are very different things.
Let me know if it helps :)
Cheers
Ok, I have wpcli and have tried with
global: sql_adapter: "wpcli"
Aside from a xdebug.so extension warning it all seems to work. But then, I see that my staging is now redirecting to localhost (wp_options siteurl and home should not have been overwritten if I understand correctly). Is the search-replace command being run automatically with the sql_adapter set to wpcli? What step did I miss?
Wait wait @frontenddevguy :) I fear you changed the wrong config here. Could you please paste here your Movefile? Strip out sensitive data ;)
global:
sql_adapter: "wpcli"
local:
vhost: "http://site.dev"
wordpress_path: "/Applications/AMPPS/www/site.dev" # use an absolute path here
database:
name: "name"
user: "name"
password: "pass"
host: "127.0.0.1"
production:
vhost: "https://site.co.uk"
wordpress_path: "public_html/site.co.uk/" # use an absolute path here
database:
name: "name"
user: "name"
password: "pass"
host: "http://primarydomain.com"
# port: "3308" # Use just in case you have exotic server config
# mysqldump_options: "--max_allowed_packet=1G" # Only available if using SSH
exclude:
- ".git/"
- ".gitignore"
- ".sass-cache/"
- "node_modules/"
- "bin/"
- "tmp/*"
- "Gemfile*"
- "Movefile"
- "wp-config.php"
- "wp-content/*.sql.gz"
# 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: "primarydomain.com"
user: "username"
# password: "password" # password is optional, will use public keys if available.
port: "7822" # Port is optional
# rsync_options: "--verbose" # Additional rsync options, optional
# gateway: # Gateway is optional
# host: "host"
# user: "user"
# password: "password" # password is optional, will use public keys if available.
# ftp:
# user: "user"
# password: "password"
# host: "host"
# passive: true
# scheme: "ftps" # default "ftp"
# staging: # multiple environments can be specified
staging:
vhost: "https://staging.site.co.uk"
wordpress_path: "public_html/staging.site.co.uk/" # use an absolute path here
database:
name: "name"
user: "name"
password: "pass"
host: "localhost"
port: 7822 # Use just in case you have exotic server config
# mysqldump_options: "--max_allowed_packet=1G" # Only available if using SSH
exclude:
- ".git/"
- ".gitignore"
- ".sass-cache/"
- "node_modules/"
- "bin/"
- "tmp/*"
- "Gemfile*"
- "Movefile"
- "wp-config.php"
- "wp-content/*.sql.gz"
# 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: "primarydomain.com"
user: "username"
# password: "password" # password is optional, will use public keys if available.
port: 7822 # Port is optional
# rsync_options: "--verbose" # Additional rsync options, optional
# gateway: # Gateway is optional
# host: "host"
# user: "user"
# password: "password" # password is optional, will use public keys if available.
# ftp:
# user: "user"
# password: "password"
# host: "host"
# passive: true
# scheme: "ftps" # default "ftp"
Ok, I'm quite sure that
host: "http://primarydomain.com"
is the wrong bit. You have basically to configure it the same as you've configured wp-config.php
on the server.
@pioneerskies I'm not sure I understood correctly?
If I change my staging ssh: host to "localhost" as in wp-config.php I get this error:
ssh: connect to host localhost port 7822: Connection refused
which makes sense as that is where I am SSH-ing to. primarydomain is how I access cPanel, FTP and everything else with my hosting.
With my primary domain set I could upload all other files, and the db push worked, but just overwrote the environment settings when presumably it has a search-replace script for that?
This bit: wp search-replace 'example.dev' 'example.com' --skip-columns=guid
Should I be running that manually or is wordmove including that in the command somewhere?
I was talking about this part
production:
vhost: "https://site.co.uk"
wordpress_path: "public_html/site.co.uk/" # use an absolute path here
database:
name: "name"
user: "name"
password: "pass"
host: "http://primarydomain.com"
to
production:
vhost: "https://site.co.uk"
wordpress_path: "public_html/site.co.uk/" # use an absolute path here
database:
name: "name"
user: "name"
password: "pass"
host: "localhost"
So not changing the ssh host, but the databse host.
wp search-replace 'example.dev' 'example.com' --skip-columns=guid
is managed by wordmove when using wpcli
as sql_adapter
in the global
section.
Let me know.
I already had localhost set as host in staging, where I was testing the db push. Just sent you the output from terminal in case there is some more useful information there.
@pioneerskies Just checking you received the info.. did it shed any light?
Just seen it, sorry for the delay.
You have an error
Duplicate entry 'scanFileProcessing' for key 'PRIMARY'
which is apparently on a non-WordPress field. Do you know what it is related to?
I do not know. Couldn't find anything on google about that either. It is a relatively new and simple site. scanfile could be related to Wordfence I guess since it uses that terminology.
@frontenddevguy is this an unresolved issue? Have you read this other one? https://github.com/welaika/wordmove/issues/448
I gave up on this as it was taking too much time, and continue to use Migrate DB for that.
Ok. I'll close this one since ATM there wont be more troubleshooting.
I get the following error when pushing the db with: wordmove push -e staging --db Error code 2 returned by command "mysqldump --host= ... mysqldump: Got error: 2005: Unknown MySQL server host
All other files transfer fine when I used --all. I am ssh -ing to a shared hosting account. Also for some reason, even though ssh password is commented I am being prompted for my ssh password each time.
Apologies if this seems like a noob question! For the 'database > host' setting I was unsure whether this refers to the vhost or my account's primary domain (which is used successfully for 'ssh > host'. I also tried including the port number in the database section.