We do lots of our work on a staging server first, then push to the live site.
We were working with our host to resolve an issue where all of our links are being forcibly written to point to the staging site before deployment, even though they’re all supposed to be written to point at the live site once pushed.
This is rewriting hundreds of links on every page of our site to point at our staging site, which is password protected, effectively rendering all of those links useless and costing us customers.
To fix this, we have to go in and change hundreds of links with every push.
Here’s the word from our host’s advanced server support team:
“I have carefully examined your case and based on my investigation the reported behavior is caused by incompatibility issues with the TD Composer. I would like to take a moment and clarify that our staging tool does not change the URL of the application. The staging copy should remain configured with the default application URL and we use an Apache module called mod_substitute to load the copy over stagingN.domain.com. However, in your case the TD Composer seems to rewrite some of the links with the URL that the application is opening with and not the one set in the database.”
What would cause this, and how can we stop TagDiv composer from rewriting links with information other than what’s in the database?
Hi,
Please provide some useful examples of how you came to this conclusion. Provide more useful screenshots with some examples for a better understanding!
Thank you!
Hey, Catalin.
We publish content in our staging site with absolute or relative URLs. If we use a relative URL, nothing goes wrong – it works like a charm. However, this takes extra overhead to process.
If we use absolute URLs while coding in a custom HTML block in TagDiv Composer, like https://stemcellpowernow.com/stem-cell-therapy-faq, then save the page, it is instead usually saved as https://staging5.stemcellpowernow.com.
We have tested this dozens of times with all sorts of workaround attempts and each time we save an absolute URL pointing at our live site while developing on our staging site, the URL runs the risk of being changed to the staging URL instead.
We have also tried taking pages that were made on the live site, creating a staging copy, then updating data on the site and pushing back to live. The URLs get changed to point at staging5.stemcellpowernow.com even though we did not change those links at all.
A useful example would be to go to staging5.stemcellpowernow.com/stem-cell-therapy-faq and stemcellpowernow.com/stem-cell-therapy-faq see that both of them point at staging5, even though we never had those URLs pointed at staging5. Staging5 was created almost a week ago, while that page was created around a year ago.
We contacted our host and confirmed that they never change the URLs. We do not and did not have any form of plugin installed that changed these URLs. We have tried downloading plugins to quickly change those URLs back after going live (which is still not ideal), but they can’t find any of the URLs that were made in custom HTML blocks by TD Composer.
Screenshots can’t capture the change, it’s simply a difference in URLs from what’s being written in the composer and what’s actually being saved when we save using the composer. My guess is that these are rewritten when the Custom HTML block is processed?
If you do want screenshots anyway, please let me know what part of the process you want screenshots of and I will get them for you.
Here’s an imgur link with images of it in action:
– They all started as “http://staging5…”
– I edit the shown link to “https://stemcellpowernow.com…”
– I save the custom HTML block.
– The link is changed to “https://staging5…”
We can thus show that these links are being rewritten once saved in the editor, and only once changed in the editor. The other links all retained the old http:// (non-secure) variation, but the one I edited was changed to https:// and forced to point at staging5 again instead.
I need these links to point to the live site they’re actually going to be used on, not to the staging site I’m developing on.
Why is this happening and how can we stop it?
Hi,
This is quite unusual, haven’t seen something like this before. The content entered in the text or HTML elements should remain exactly as they are entered, including links either relative or absolute.
What if you make a test and enter the same links in wordpress editor, then update and re-edit or refresh the page – https://www.screencast.com/t/BpblFW2lJu Do the links change then? Let me know.
Thanks
In this case, it does not seem related to the tagdiv editor, since I tried every variation of http: and https: with and without www. preceding stemcellpowernow.com in the normal WordPress editor, and every time it converts it to a staging link immediately upon publication as well.
What could force it to go to that link instead of our main stem cell therapy website?
I’ve disabled all plugins and switched to an entirely different theme, then making a brand new page, and still encounter this issue. Tried checking .htaccess and functions.php without any luck as well, at the site, staging, and theme level. Checked the database and everything that’s visible there looks right.
These steps reproduce the issue for us.
-
Create a staging copy of the live site.
Disable all plugins.
Install and activate the twenty nineteen default theme from WordPress.
Create a new page, title it whatever you want.
On that page, create four links: a. http://example.com b. http://www.example.com c. https://example.com d. https://www.example.com
Save the page.
View the page – all links point to https://stagingX.example.com
Edit the page – all links will have had “stagingX.” prepended to them, showing that they have been rewritten.
We narrowed down how this issue occurs.
The Custom HTML Block in TagDiv Composer is stored in the database as a form of hashed code, like EtuvXkcz etc. However, the staging tools on our server take advantage of Apache mod_substitute and mod_headers in order to prepend the staging domain when we’re working on it, and strip it when we’re done.
Mod_substitute is able to trigger on content in the editor, so while we’re editing the pages, mod-substitute works its magic and prepends the staging domain so that our site is functional in staging.
However, mod_headers works off of information in the database and is unable to read the code that is stored there by the custom HTML blocks created in TagDiv Composer, so it is unable to then strip the staging domain out of our content.
In our use case, we write the entire site in custom HTML blocks, taking advantage of the speed and versatility of your theme to easily rearrange blocks while keeping load times to a minimum and customization to a maximum with custom HTML and CSS for most everything else (on top of your base CSS).
The way TagDiv Composer stores information in the database prevents database search tools and PHP can not be used to target the many links throughout our site.
A workaround for us is going through every section of code and manually changing all links to relative links. This is not an ideal workaround, but it is getting the job slowly but surely done.
Is there a way this kind of thing can be changed in the future to prevent hashed data being stored in the database instead of the code itself, or is there a better workaround you could recommend for us?
Indeed, the composer encodes the content entered in the HTML element. I believe this functionality was created to avoid damage to the page content caused by invalid code. There were cases when for example an unclosed tag broke the page in which it was entered.
The column text element doesn’t encode it’s content however, maybe you could use it instead of a raw HTML element – http://prntscr.com/nxro1a
Thanks, Simion! I’ve rewritten all of the links as relative instead of absolute. While this is not a perfect solution, it’s a better solution for our client, so we’ll work with that for now.
If anyone runs into this in the future, rewriting absolute links like to relative targets like will work, it can just take a lot of time on a big site.
