Solved: License validation issues with dev/staging site on SiteGround

Hi there! I’m trying to validate the PRO license for a new development (staging) website, and I keep getting an error:

Your code is valid but looks like it has already been used on another site. You can revoke and re-assign within your Themeco account.

Now this is ridiculous because I’ve explicitly revoked the license from an old devsite and set it to this staging url. I even tried assigning it a license for a production site with the staging URL, still no joy. I never have this issue with my own servers, but this one is hosted with SiteGround.


Update:

I solved my issue after examining various other issues that occurred, and generalized the original post for anyone searching for a similar issue.

It seems that SiteGround’s staging system works with Apache redirects, and forces the original (production) site’s URL on WordPress even though the page is displayed at the right staging URL. As a result, the WordPress site URLs are all example.com rather than staging1.example.com, which is also what X/PRO’s validation system reports to the validation service.

To solve this problem, simple force the correct URL in wp-config.php by adding these two lines below the WP_DEBUG settings:

define('WP_HOME','http://staging1.example.com');
define('WP_SITEURL','http://staging1.example.com');

Before redeploying to production, go back and return the URLs to the production URL. If you fail to set the URL back before deploying, it will break the URLs on the production site. (See Troubleshooting - Builder Preview Warnings)

Additional reading regarding SiteGround staging issues (and workarounds):


Hello Meng,

Thanks for writing in!

I have checked your licenses and two of your licenses were assigned to the domain URL. To better assist you with this issue, please provide us access to your site so that we can check your settings and investigate further. Please create a secure note with the following info:
– Link to your site
– WordPress Admin username / password

To know how to create a secure note, please check this out: https://theme.co/apex/forum/t/how-to-get-support/288

Regards.

@RueNel thanks, I’ve already managed to solve the issue myself. I’ve edited the original post to be of help to any other users searching for the issue in the future.

It seems that SiteGround still hasn’t solved their mess of a staging system, much to the chagrin of developers used to more conventional setups.


For Themeco’s development team, I’d recommend adding a way to detect the website’s actual URL and include it in the URLs reported for validation. If either turns out correct that should be good enough. I’ve seen quite a few other (big) hosting providers work with redirects, disabling the WP site URLs by forcing them into wp-config, etc. which is quite hard to discover for inexperienced users. This validation system should not be the barrier when developing websites and it sucks when you unnecessarily loose precious time (and money) on addressing the issue.

Hey Meng,

It’s good to know that you have resolved your issue.
Thanks for letting us know and your feedback has been noted.

Regards.

Hi @skndal,

I wanted to chime in here to add some additional context. I’ve spoken to SiteGround about their staging system directly in the past and to my understanding it works by rewriting the URLs as pages are rendered. It is not a truly isolated system like other platform staging environments (WPEngine etc.) I’ve asked them to look into it, but it sounds like that would be a considerable investment on their end. To be fair, their platform supports the majority of use cases, but brings some risk if you are working with more complicated functionality.

Great job solving this with the wp-config.php statements by the way. That will certainly keep you out of harms way since the URLs are hardcoded now.

What’s most concerning to me about their technique is that we can’t rely on the WordPress native home_url and site_url functions to be accurate. they often provide the production URL. As a developer, I must always be able to expect those functions to return the URL of the site I am working on. There shouldn’t be a risk that the production URL is ever used instead.

An unfortunate result of their version is this:

  • Plugin makes a wp_remote_get function to an external API
  • That request includes a URL (via home_url) that the remote system is requested to do something with
  • The remote system now has the production URL from a staging

You can probably see how risky that is to mix the two. It gets messy.

Their suggestion of detecting the actual URL is moot because it circumvents best practices. As WordPress developers, we should use the provided WordPress APIs for working with URLs - I’m talking about the home_url, site_url admin_url functions etc. This preserves what makes the WordPress ecosystem powerful by ensuring things can always be hooked into by other developers.

At a minimum, SiteGround should be filtering calls into any WordPress API functions that return URLs.

Sorry for the rant! I came across this thread and saw that you seemed to have put a good amount of time into solving this, so I figured I’d share a few thoughts from my perspective in case it helped round out your understanding. Take care!

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.