Path and URL substitution clash

[pixelmultiplo]

Describe the bug
Wordpress path get substituted in URLS.

For instance after the pull, my local page has links like this: background-image: url(https://Users/marek/Projects/Larin/website-it/website-it/wp-content/uploads/2019/12/TREVI_az_02.jpg);

Wordmove command
wordmove pull -e staging -d

Expected behavior
The path substitution should not clash with the database. Maybe I am missing a way to disable it.

movefile.yml
`
local:
vhost: https://www.website.local
wordpress_path: /Users/marek/Projects/Larin/website-it/website-it

staging:
vhost: https://staging.website.it
wordpress_path: /staging.website.it
`

Environment (please complete the following information):

• OS: OS x 10.14
• Ruby: ruby 2.5.5p157 (2019-03-15 revision 67260) [x86_64-darwin18]
• Wordmove: 4.0.1

Doctor
[x] wordmove doctor is all green

[alessandro-fazzi]

Hi @marekmaurizio ,

first of all

Wordpress path get substituted in URLS

it's not a bug, it's a feature. Or at least it is intended to be such from the beginning of Wordmove's history. Wordmove thinks that you could have the local path hardcoded somewhere in your database.

Just to take a casual but real example:

Honestly I don't know if we should take care of such a thing, but we do.

Now the "problem" here is that /staging.website.it is a substring of https://staging.website.it so when Wordmove is searching for the path it finds URLs also. And for sure it brings a big problem.

Let me ask one question: are you using FTP protocol by any chance? Having /staging.website.it as a real directory on the remote server sounds strange to me and it looks more likely to be an FTP jail.

Let me know so that I can have a wider vision. TIA

[pixelmultiplo]

No FTP. Just a staging website, this naming is the default in plesk so it happens quite often. I think I never had any instance of path encoded in database. Il mar 11 feb 2020, 09:55 Alessandro Fazzi <notifications@github.com> ha scritto:

…

Hi @marekmaurizio <https://github.com/marekmaurizio> , first of all Wordpress path get substituted in URLS it's not a bug, it's a feature. Or at least it is intended to be such from the beginning of Wordmove's history. Wordmove thinks that you could have the local path hardcoded somewhere in your database. Just to take a casual but real example: [image: Image 2020-02-11 at 9 32 44 AM] <https://user-images.githubusercontent.com/904690/74221179-c5392380-4cb1-11ea-8422-5b32801c821a.png> Honestly I don't know if we should take care of such a thing, but we do. Now the "problem" here is that /staging.website.it is a substring of https://staging.website.it so when Wordmove is searching for the path it finds URLs also. And for sure it brings a big problem. Let me ask one question: are you using FTP protocol by any chance? Having /staging.website.it as a real directory on the remote server sounds strange to me and it looks more likely to be an FTP jail. Let me know so that I can have a wider vision. TIA — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#582?email_source=notifications&email_token=AAGGHWM3SFACA3HAXHD63ILRCJRXRA5CNFSM4KPZTBIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELLUABA#issuecomment-584531972>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGGHWMNY2EVTGQESE2PJQ3RCJRXRANCNFSM4KPZTBIA> .

[alessandro-fazzi]

Ok; I'd ask you to do a test, if you mind to.

Create a file named wp-cli.yml aside of movefile.yml with the following content

search-replace:
  precise: true

then blank your DB and go for a new clean wordove pull.

Let me know if that helps. This test would help me too to understand how and if implement a fix. TIA

[dew-frost]

I have tried the wp-cli.yml approach while trying to solve an apparently unrelated issue -- some URLs not being replaced when pushing the db for a website made using the Elementor plugin.
(Elementor creates absolute URIs for many objects, including images and button HREFs.)

It solved the issue at least partially -- no images are pointing to localhost any more, and several link/button HREFs have being correctly replaced.
Some of the HREFs still pointed to localhost, but I feel it's more of an Elementor issue than Wordmove's.

Just for further info: Elementor saves some data in JSON format in wp_postmeta and the URIs and encoded like this:

[...]
"item_button_primary_url":"http:\/\/localhost\/..."
[...]

When not using precise: true, it seems like such URIs escape (heh) Wordmove's attention, whereas when using it, the problem mostly seems to go away.
(Repeat: there might still be a reason why some replacement don't occur, but I strongly feel the reason is in some misconfiguration I've made in Elementor itself.)

Hope this helps

[dew-frost]

Update: not yet there. An experimental pull for the same website did not replace the staging URLs with localhost (buttons only; menu items, regular anchors, images were replaced normally.) Definitely something with Elementor here...
..which also means my comment yesterday was somewhat OT ^_^

[alessandro-fazzi]

Hey @dew-frost ,

I've put my thoughts on this string

"item_button_primary_url":"http://localhost/..."

and ... well ... it's somewhat interesting. That does not appear to be a serialized object. AFAIK WP-CLI supports string replacement for strings and serialized objects, but if Elementor is (really?) putting json_encodeed strings into the database, it's somewhat obfuscating them from the replacement algorithm.

Take a look at this example:

> psysh                                                                                                                                                                              
Psy Shell v0.9.9 (PHP 7.2.28 — cli) by Justin Hileman
New version is available (current: v0.9.9, latest: v0.10.2)
>>> serialize('http://localhost')
=> "s:16:"http://localhost";"
>>> json_encode('http://localhost')
=> ""http:\/\/localhost""

As we can see, we're still able to find http://localhost inside a serialized string, but not in the json encoded one.

Keep in mind that nor our old hand written default adapter, not wp-cli do support this scenario.

The only solution grinding my gears but still possilble is to introduce a hook calling wp search-replace searching for the escaped string and replacing it with another escaped string. But in order to have a post-push remote hook you'd need to have wp-cli installed on the remote server too, e.g.:

  hooks: # Remote hooks won't work with FTP
    push:
      after:
        - command: 'wp search-replace "http:\/\/localhost" "http:\/\/example.com" --skip-columns=guid'
          where: remote
    pull:
      after:
        - command: 'wp search-replace "http:\/\/example.com" "http:\/\/localhost" --skip-columns=guid'
          where: local

Obviously this is a not tested idea about a workaround for an issue which does not seem to be really wordmove-related :)

[alessandro-fazzi]

@marekmaurizio any update from your side? :)

[dew-frost]

Hi @pioneerskies

I've put my thoughts on this string

thank you :)

Of course the website in question has no SSH access enabled (long story...) so it will not be possibile to try the hook approach in the specific case. The first time I'm on a website that allows me to use SSH, I'll try it, just for the hell of it.

However, after playing some more with DB pulls and pushes, I have become even more convinced my trouble is not related to Wordmove per se. Long story short, not only Elementor but also some of its add-ons put this sort of crazy stuff in the database. I've yet to test a feature of Elementor's that allows substituting the website URL and then regenerating its "files" (sic.) We'll see.

Don't keep this issue open just because of this ;)

[alessandro-fazzi]

Related to #616 .