Push/Pull to staging doesn't replace URLS correctly

DevKinsta Bug Reports
1

Q: Date/Time this occurred (Provide your time zone also)
A: Not specific to a time as it has happened multiple times UTC+8

Q: DevKinsta Version
A: 2.11.0

Q: OS Version
A:

Q: Docker Desktop Version
A: 4.23.0

Q: Were any error codes or messages observed? If so, what were they?
A: No

Q: Detailed Description of the Problem
**A: When Syncing (pushing and pulling) site to staging the urls aren’t replaced correctly. This is noticed more on images, and I found that some images have a double “https://https://” which results in images failing to render.

Local URLS are also not updated to the staging url and vice versa if pulling.

The only way around it I have found is to use the Sync to push the site files to remote staging > export local DB and import to staging DB > use kinsta search and replace url tool to replace local url to staging url. **

3

Hi John,

I’ve just tried to replicate this issue on my end but couldn’t reproduce it (I’m on OS: Linux Ubuntu 22.04 , with DevKinsta 2.11.0 and Docker engine version 24.0.6, build ed223bc. What’s your operating system and its version by the way?).

What I did were as follow:

  1. In DevKinsta, I chose “Import from Kinsta” , and selected to import the WP site I have in MyKinsta account
  2. Once done, I checked the imported (local) site and the site’s URLs were all set properly (just had 1 https:// URL for image and css/js - which looked good).
  3. Then I tried to " pull " that same site again (from Sync → Pull from Kinsta menu), and the process completed just fine - I also re-checked that same site, and the site’s URLs were all also set properly (only 1 https:// URL for image, css and js - so far all looked good still).
  4. Finally I tried to " push " that same local site to my Staging site hosted at Kinsta, and the process also completed - and I tried to load the staging site, and the site loaded properly (I also checked the image, css/js URLs in that Staging site, but couldn’t find double https://https:// at all).

Perhaps you may want to try to add another local site by re-importing that same Staging site from MyKinsta to your DevKinsta (and use different local domain name - just for testing purpose), and then try to pull again, and then push back to that same Staging site and see if you still get double https://https:// in those URLs?

If you still get the same with it, please kindly send us the most recent main.log file (you can send it via DM to me and/or to my colleagues as well: @Alessandro and @ZachE ) and we will check and review it (and if it’s really a bug, we can report the same to our internal developers to investigate further).

Regards,
Agus

4

Hi Agus,

Thanks OS is Windows 11.

I have attempted a new import and experiencing the same issue.

Will DM you the staging site URL and log file.

Kind Regards,

John Marrington

5

Thank you for your reply and update as well as for the main.log files (old and recent) and the screenshot John!

As I mentioned in your other thread, I tried to replicate this on my Windows 11 machine and so far everything seemed to be working properly ( all staging URls were all replaced properly/correctly with the local site’s URL and with the custom ports I set in DevKinsta , and I didn’t find my Staging site URLs at all in the local site’s database either). I also was able to push that local site (with custom port) back to the Staging site in MyKinsta just fine (all worked correctly as expected, and I didn’t find https://https:// either )

I also have checked your recent main.log file (dated as of September 25 / 2023-09-25 ) and tried to search for the action of “search-replace” , but didn’t see that your stagingsiteurl was replaced with your local site’s domain URL (with the custom port).

Since you mentioned that you have now set/force the ports to be: 80 and 443.
Could you please try to add new site/re-import that same Staging Site to your DevKinsta once again (and just leave the existing local site as is) and then check that new local site again on your browser?
(the URL of the new local site will have an additional -1 in it. For example, if you have client.local before, the new one will look like client-1.local ).

Then please see if that new client-1.local also still has the Staging URL in it (also please send us the main.log file again for this new action).

regards,
Agus

6

Hi I have done so and messaged you separately with image and logs. Same issue.

7

Got them again via DM, John :slight_smile: Thank you!

I’ve checked that new main.log file you sent and noticed the following actions in there, that were executed properly (note: I changed your actual site name with “yoursitename” that I pasted below)

[2023-09-25 15:08:06.730] [info] [updateWpConfigUrl]: update urls in wp-config.php. Site:yoursitename-1 from: https://env-yoursitename-staging.kinsta.cloud, to: http://yoursitename-1.local

[2023-09-25 15:08:06.778] [info] [updateWpConfigUrl]: update urls in wp-config.php. Site:yoursitename-1 from: env-yoursitename-staging.kinsta.cloud, to: yoursitename-1.local

[2023-09-25 15:08:06.811] [info] [wpSearchAndReplace] Search and replace. Source: https://env-yoursitename-staging.kinsta.cloud, to: http://yoursitename-1.local

[2023-09-25 15:08:09.511] [info] [containerExec] Command ‘cd /www/kinsta/public/yoursitename-1 && /usr/bin/php8.0 /usr/local/bin/wp --allow-root --skip-themes --skip-plugins search-replace https://env-yoursitename-staging.kinsta.cloud http://yoursitename-1.local --all-tables’ on devkinsta_fpm finished with exit code 0
[2023-09-25 15:08:09.512] [info] [downloadSite] Site successfully downloaded

and also these:

[2023-09-25 15:08:18.092] [info] [updateWpConfigUrl]: update urls in wp-config.php. Site:yoursitename-1 from: http://yoursitename-1.local, to: https://yoursitename-1.local

[2023-09-25 15:08:18.105] [info] [wpSearchAndReplace] Search and replace. Source: http://yoursitename-1.local, to: https://yoursitename-1.local

[2023-09-25 15:08:20.922] [info] [containerExec] Command ‘cd /www/kinsta/public/yoursitename-1 && /usr/bin/php8.0 /usr/local/bin/wp --allow-root --skip-themes --skip-plugins search-replace http://yoursitename-1.local https://yoursitename-1.local --all-tables’ on devkinsta_fpm finished with exit code 0

[2023-09-25 15:08:32.288] [info] [ipc/site/create] Create site completed successfully

So based on the actions above, your staging site URLs in the database (and in the wp-config.php file) have been all replaced with the local domain URL: yoursitename-1.local .

I’m still unsure and am wondering if the Staging URL to that image and any other files (as shown in the screenshot you sent via DM) may be hard-coded in the files ( cache files ? ) somewhere in your site’s files/subfolders - and were not saved in the database :thinking: .
If they were saved in the database, the action above (with wp search-replace cli) would have updated the staging URL with your local domain url.

Could you please do the following to check further:

  1. Open Docker Desktop and click on the Containers on the left side menu

  2. Click the “devkinsta_fpm” name from the containers list (Name column) on the right side

  3. Then on that devkinsa_frm container page, click on the “Terminal” tab

  4. On that “Terminal” page, please type the following (1 line at a time ):

cd /www/kinsta/public/yoursitename

wp db search env-yoursitename-staging.kinsta.cloud --allow-root

( Note: please change the url with the actual of your staging URL - without http or https , and see if it will return any records in the database with that staging URL ? )

  1. Also on that same “Terminal” page, please type the following (1 line at a time ) :

cd /www/kinsta/public/yoursitename

grep -lir env-yoursitename-staging.kinsta.cloud

(Note: please change the url with the actual of your staging URL - without http or https, and see if it will find any local site’s files that may contain that staging URL ?)

Please send the results (in plan text) via DM again once you have executed the above.

regards,
Agus

8

Hi this is done and have DM’ed result.

9

Hello @jbman, thank you for providing the logs!
This seems to be related to a bug we have seen in the past, our devs are working on a solution.
For now, you will need to use wp cli to update the URL and fix the https://https:// issue (or the Search and Replace tool available in MyKinsta).

Thank you again for providing the logs, this data will help us while working on the fix.

Regards,
Alessandro

11

Hi @Alessandro thanks I have messaged you DM regarding WP CLI.

  • John
12

Hi John :slight_smile:

I also got your DM regarding that WP-CLI.

In order to use the WP CLI to update the URL (to search and replace the staging url with the local domain name), you could do it on your local computer from the Docker Desktop (very similar to what I mentioned yesterday). So you could do these:

  1. Open Docker Desktop and click on the Containers on the left side menu

  2. Click the “devkinsta_fpm” name from the containers list (Name column) on the right side

  3. Then on that devkinsa_frm container page, click on the “Terminal” tab

  4. On that “Terminal” page, please type the following (1 line at a time ):

  • cd /www/kinsta/public/yoursitename

before continue, you may want to backup this local site’s database first (just in case something is not right, after the search-replace you could restore from it) with:

  • wp db export --allow-root

(this will export that local site’s database into a .sql file)

then you can continue with the following 1 command line to perform search and replace via WP CLI:

  • wp --allow-root --skip-themes --skip-plugins search-replace https://env-yoursitename-staging.kinsta.cloud https://yoursitename.local --all-tables

( Note: please change the url with the actual of your staging URL and your local site URL )

I also noticed in the results/entries you gave us yesterday (in .txt file) that many staging site URL in the database were set with https:\/\/ something like this:

https:\/\/env-yoursitename-staging.kinsta.cloud

for this, then you may want to run another WP CLI for that specific URL (that has https:\/\/ format), and you will need to search this https:\/\/env-yoursitename-staging.kinsta.cloud and replace it with your local domain URL , for example like this:

  • wp --allow-root --skip-themes --skip-plugins search-replace https:\/\/env-yoursitename-staging.kinsta.cloud https://yoursitename.local --all-tables

After you have done the above WP CLI (search and replace), then you can always double check if there is/are still any staging URL in the database - with the previous WP CLI :

wp db search env-yoursitename-staging.kinsta.cloud --allow-root

if none, then it should be good and you may want to check your site again on your browser - make sure to delete browser’s cache as well (and see if it’s no longer showing any staging URLs).

Hope that helps!

regards,
Agus

13

Hi Agus,

Thanks for these detailed instructions.

  • John
14

You’re most welcome John! :+1:

regards,
Agus