Hello,
I rated 5 stars and I love the plugin.
But the above message says something true: it’s not clear how to deal with search & replace fields to get a successful result. A new migration I’ve attempted today failed and I’ve found exactly those double http in database tables.
So, now, what is the correct way to insert urls in the above mentioned fields?
I would be really glad if a dummy information (maybe step by step using screenshot) would be provided!
Thank you very much.
It girl, you have to take off http:
You start the url with // which is literally the stupidest idiosyncrasy I’ve ever seen in a plugin.
So, until the developer fixes this chaotic feature, you have to put:
//oldurl.com
And
//newurl.com
In the respective fields.
But what if I’m migrating from an “http” site to an “https” site? How would I do that without having the “http:” concatenated at the front?
Ah — I needed to make the protocol (http or https) explicit in both the FIND and REPLACE boxes, eg:
http://www.mysite.com -> https://www.mysite.com
So the implied “http:” only happens when neither side has an explicit protocol OR only one side has an explicit protocol. When both sides are explicit, everything works as I would like it to.
@feralreason, it’s best to do the protocol-less find/replace first to ensure any links that already have a different protocol are correctly updated, and then do the protocol specific find replace by adding another find/replace row at the end…
//dev.example.com => //www.example.com
http://www.example.com => https://www.example.com
This goes for http to https and also https to http.
I agree @ianmjones with protocol-less Find/Replace, but this plugin set up defaults with http:, so you can’t do this. It’s one for the developer to fix.
As it stands, part of the useful function of the plugin requires accessing the MySQL database and running a query to fix – therefore negating much of the plugin function and purpose.
Hi @blitz999, I wonder whether you have another plugin, hook function or problem with your theme that is adding “http:” when “//” is found without a protocol?
I am one of the developers of WP Migrate DB Pro, so I can assure you that it does not include the protocol in the URL Find/Replaces that it sets up by default, well, it’s not supposed to.
Maybe you’ve found a bug, please could you send your Diagnostic Info & Error Log from the Help tab to “nom [at] deliciousbrains [dot] com” and mention that Ian asked you to send the info, with a link to this topic, and we’ll see if we can get to the bottom of this issue.
@ianmjones thanks for explaining this. Prior to logging a possible bug, I think this thread is making apparent is that the interface for the find/replace aspect of the plugin is not clear. The precise same issue has been seen by it girl above.
It has caught me out several times, to the point I wrote this post. It is not in one theme or plugin set, but across a number of migrations that I’ve made the mistake of providing the full url. It is easy to do because on a shared server, the path might show as: /nfs/cx/hx/mnt/1234/domains/domain.com/html for example and without a transport protocol. Migrating usually (always?) involves a ‘proper’ URI.
So, the point being made is the interface of the plugin (which is otherwise brilliant and a real lifesaver for serialised data especially), might benefit from some clarity NOT to provide the transport protocol in the find/replace fields to prevent this human mistake being made.
If you definitely think the http://http:// issue IS a bug, I’ll log it. I’ve just had a quick look in a recently migrated site, but there’s nothing obvious in the log as yet… I use protocol-less coding as standard. The only specific place it is specified is in WP General settings.
@blitz999, thanks for your thoughts, much appreciated.
Please do send through your Diagnostic Info & Error Log, plus a screenshot of what the Find & Replace looks like on a new Export profile, just so we know we’re on the same page.
