Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Path and URL substitution clash #582

Closed
pixelmultiplo opened this issue Feb 4, 2020 · 9 comments
Closed

Path and URL substitution clash #582

pixelmultiplo opened this issue Feb 4, 2020 · 9 comments
Assignees
Labels

Comments

@pixelmultiplo
Copy link

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
Copy link
Member

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:

Image 2020-02-11 at 9 32 44 AM

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

@alessandro-fazzi alessandro-fazzi self-assigned this Feb 11, 2020
@pixelmultiplo
Copy link
Author

pixelmultiplo commented Feb 11, 2020 via email

@alessandro-fazzi
Copy link
Member

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
Copy link

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
Copy link

dew-frost commented Apr 3, 2020

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
Copy link
Member

alessandro-fazzi commented Apr 5, 2020

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
Copy link
Member

alessandro-fazzi commented Apr 5, 2020

@marekmaurizio any update from your side? :)

@dew-frost
Copy link

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
Copy link
Member

Related to #616 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants