0

Edited for clarity and to display steps we take to reproduce the issue.

Question

What would cause absolute URLs on our staging site to prepend the staging site's subdomain to them when saved in the editor?

Summary

We write pages manually in HTML and CSS on a staging site hosted on SiteGround, save our changes, then test them. However, when we save our work in the editor, they all prepend the staging subdomain we are writing on to each of the absolute URLs we've written.

Steps to Reproduce

  1. Create a staging copy of the live site.
  2. Disable all plugins.
  3. Install and activate the twenty nineteen default theme from WordPress.
  4. Create a new page, title it whatever you want.
  5. On that page, create four links: a. http://example.com b. http://www.example.com c. https://example.com d. https://www.example.com
  6. Save the page.
  7. View the page - all links point to https://stagingX.example.com
  8. Edit the page - all links will have had "stagingX." prepended to them, showing that they have been rewritten.

Detailed Breakdown

We write a link destination as an absolute URL into a page, like this example:

"Click here for our <a href="https://example.com/daily-specials">Daily Specials</a>!"

We then save our work in the editor.

If we immediately check the link on the staging site, it is already pointing instead to <a href="https://staging.example.com/daily-specials"></a> and displays as such if we relaunch the editor.

While this does not affect any relative URLs (i.e. <a href="/daily-specials"></a>), it does affect every prefix variant of absolute URLs.

The site has thousands of absolute URLs affected by this.

What We've Tried

We must be missing something, so please feel free to offer any guidance or perspective, regardless of whether it seems redundant or not.

We've attempted checking the server, theme, and child theme .htaccess and functions.php files in cPanel for any code that would cause this (perhaps we missed or misunderstood it?).

We've also verified that the site URL etc. under Settings > General in the WordPress dashboard are pointing at the live site without the staging prefix.

We have disabled all plugins and switched to the Twenty Nineteen theme and experience the same issues.

The Home URL and Site URL in settings and in the database are set to the main site, but in the help section of the "Better Search Replace" plugin it shows both URLs as having the staging subdomain preceding them.

  • Seems like this is due to a conflict between the SiteGround staging process and the database storage process of a plugin we use, TagDiv Composer, that's part of a theme we use from the same developers. It all boils down to the plugin's custom HTML blocks storing all those URLs in an encoded format along with everything else, and the rewrite rules used by our server in staging looking for URLs in the database (which it can't read in proprietary code). Thank you all for your help in finding the real problem! – Caleb Mieszko Jun 4 at 8:52
0

Did you check the two URLs in the wp_options table? That's where WP gets the base URL for a site.

If you moved the site database from staging to live, you may have forgotten to change those values in the wp_options table.

  • Thank you for offering guidance, Rick. We did check those and they are both set to our main domain without the staging subdomain, so in our example it'd be targetsite.com. – Caleb Mieszko Jun 4 at 1:19
  • That said, I did check the "Help" tab of the "Better Search Replace" plugin and it shows the staging server included for the site and home URL, even though the database itself shows it correctly. What could cause it to get changed somewhere between them? – Caleb Mieszko Jun 4 at 1:22
  • Could be a plugin that does that. Also, URL settings in the wp-config.php file will override the URL values in the wp-options table. But the search/replace plugin is great to use to ensure your media files are pointing to the live site. Media files get the URL that was active when they were added. So a site move should always include a search/replace process. "Better Search and Replace" is my favorite. – Rick Hellewell Jun 4 at 1:42
  • And it's common (and best, IMHO) to set wp-options to the live URL on a staging system, then use wp-config.php to override to local/dev systems. As long as you don't upload the wp-config.php file from dev to live.... – Rick Hellewell Jun 4 at 1:44
  • Thanks for the reply, Rick, really appreciate your help! We disabled all plugins and switched to a default theme (twenty nineteen) and used the built in editor, but experienced the same issue. Wp-config.php on both the public site and the staging site have database pointers and so on, but no mention of the URL. – Caleb Mieszko Jun 4 at 2:05
0

You should be using relative links (/path/here) instead of absolute URI's including the schema, this way it decreases the probability of you having insecure asset issues. Then, all you'll need to have set is the home and siteurl options in wp_options table to the correct URLs.

If they're hardcoded into the posts/pages, you could use wp-cli or better search replace to replace the content URLs with relative links or the correctly prefixed URL, though would highly recommend relative URIs.

  • Thanks for the reply, Zach! We do have the Home URL and Site URL set correctly in the database and in the WordPress settings, and relative URIs respond appropriately. Unfortunately, Better Search Replace (and every other database tool I've looked in) only sees about 35 of the links. We could still update our thousands of absolute links to relative links manually in our code, but it would take much longer and add overhead to every click. We are already forcing all traffic to only https:// and we write all absolute links as sitename.com while disallowing insecure resources. – Caleb Mieszko Jun 4 at 1:31
  • Our editor saves all of the code we write as snippets we can easily rearrange, so it doesn't seem to translate properly in the database to actual links that we can quickly swap out with database commands. – Caleb Mieszko Jun 4 at 1:32
0

Seems like this is due to a conflict between the SiteGround staging process and the database storage process of a plugin we use, TagDiv Composer, that's part of a theme we use from the same developers.

It all boils down to the plugin's custom HTML blocks storing all those URLs in an encoded format along with everything else, and the rewrite rules used by our server in staging looking for URLs in the database (which it can't read in proprietary code). Thank you all for your help in finding the real problem!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.