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.

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?

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.

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.

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?

• This reply was modified 7 years by projectdevs.
• This reply was modified 7 years by projectdevs.

Here’s an imgur link with images of it in action:

Tagdiv Editor Rewriting Links – They start as “http://staging5…” I edit them to “https://stemcellpowernow.com…”, hit save, and they’re changed back to “http://staging5…” immediately.

– 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?

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.

Figured this out, no longer need help, thank you!

Sent! Included info in the email on another issue as well – in Microsoft Edge the right side of the site is cut off.

Hey Catalin,

The website is http://stemcellpowernow.com.

Here’s an example search results page by searching for “contact”, and it shows all of the above scenarios: http://stemcellpowernow.com/?s=contact

The Contact Us and home page results uses raw HTML blocks and shows code in the preview tests.

The Footer page uses title blocks and shows nothing in the preview text.

The articles about Lyme disease and Hair generation are posts and show proper content in the preview texts.

Even more specifically: if it’s a page with a raw HTML element at the top, it just shows code in the view results just like the screenshot. If it’s a page with a text block at the top instead, then it shows nothing under the post image. There is no text for those at all.

How can I fix this?

Seems to happen specifically to pages in the search results, but not to posts.