Validation issue for updates

Hello @Pixel8r,

Thanks for updating the thread.

Yes and actually that’s what we suggest to our customers also to test the update on a staging server. So that that in case of any issue, same can be looked at without effecting the live website.

Theme Update guide: Please take a look at following article for some help.



I have created a staging copy and done the updates on it and everything appears to be working again now. :slight_smile:

I do have one issue before I push this to the live site though. When I go to the “Collections” menu item, which is the woocommerce shop with prices disabled, I now see a button with readme when I hover over the images. This is only happening on the staging copy and I want to remove this before I push to live.

I will put links to the staging site and the live site in a secure message.



Hello Mark,

Thanks for updating the thread. :slight_smile:

Upon checking your website backend, I am unable to see the frond end of the website and getting following error message (please see secure note). When I checked the URL structure under Settings > General I see that you are using live website URL not the staging one. Please update WordPress Address (URL) and Site Address (URL) to staging URL.

I can make the changes myself but because it’s a customer website, we are not allowed to make any changes without taking due permission from customer. Once you have made the changes, let us know and we will assist you further.


Hi Prasant,

I had tried updating both addresses in the general setting to the staging address but for some reason WP will not accept the change. I was kind of hoping that I would be able to resolve the issue without sorting that one.

Any idea why WP won’t accept the longer staging URL?



I have just spoken to site grounds support about why I can’t change the wordpress and site address in the general settings and this is their response. It seems that you are handing out conflicting advice. Maybe the better thing for me to do is just push the site live as it is and deal with the issues on the live site?

—Siteground support message;

The provided article states correctly about the URLs of our staging tool.

Let me try to explain how our staging software works.

When creating a WordPress staging copy we do not replace the Home and SiteUrl options for WordPress. They remain the same as the original website. Instead, we use three additional Apache modules that allow you to actually work on the correct application:

  • mod_host – all the requests to the application will be processed as they have been made to the real hostname (in our case all of the requests to the and not the URL in the WordPress configuration). This module is written by us.

  • mod_substitute – standard Apache module – used for replacing strings in the Apache’s response. We use this to replace with

  • mod_headers – standard Apache module – used for changing request and response headers. Used for configuring the headers according to the staging subdomain.

This is why the database URL of the staging copy has to be the live site ones instead of the staging ones otherwise the redirect loop error occurs.

We have thoroughly tested the staging software with multiple different WordPress applications and our tests show it is working as expected. Still, unfortunately, we cannot give a guarantee it will not have discrepancies with other third-party plugins/themes and/or custom code added to WordPress.

If you are having troubles using any theme or plugin on the staging site we would advise you to clone your website by using a real subdomain for that purpose. For example, you can create a new subdomain titled from your cPanel -> Subdomains tab. Then clone your live site into and reconfigure the site to work with the new URL. You can clone the site by using your cPanel -> Softaculous tool -> Scripts Installations and click on the “Clone” icon next to Clone Installation Details.

This way the staging site will use a real subdomain ( and the “WooCommerce Composite Products” plugin will work properly. The disadvantages of this method are that you will not be able to push the staging site to live directly but you should copy the staging site over the live one and manually reconfigure it to use the live site’s domain name ( instead of the staging one (

Should you have any further questions regarding our services do not hesitate to contact us at any time

Best Regards,

Darin Chakalov
Technical Support Team

Hi Mark,

This looks like the issue with SiteGround’s staging environment. See the bottom of this article:

Regretfully we’ve not heard from them on a better solution.

I still need a solution to my original problem though.

You will note by reading the support message from them that you are both handing out conflicting support messages.

Hello There,

Thanks for updating in! I have logged in to your site. I have revoked and revalidated X theme for several times. It is as if the connection to themeco is blocked. The latest updates in X > Validation is supposed to display 6.2.4

The plugins section or the Dashboard > Updates section fails to recognize that X theme is already validated. I would suggest that you manually update X theme and Cornerstone by downloading the latest copy of the theme from your dashboard ( There could be some corrupted files which is why you are experiencing the issue. Only manual update may resolve this one. To know more how you can manually update the theme, please see “Manual Updates” section in this article:

And if you want, please provide us ftp to your site so that we will do the manual updates for you.

Please let us know how it goes.


On the staging copy I had managed to get everything working correctly. I deleted the theme and cornerstone, then reinstalled the latest X and registered it. The updates then all worked as they should.

I then pushed the staging copy live and have now logged into the live copy I had made from the staging site, but the problem is still there! This is really strange as the live site is now saying that it is registered but still saying the it isn’t on the another cornerstone update that is required.

Please can you just look at the live site and try and work out what the problem is. It hasn’t made any difference going through this whole process of making a staging copy, deleting the theme and cornerstone.

Also as you will now see on the live site the problem I was talking about with the “read more” button appearing over images in the collection. How can I remove this?

I have also noticed that form some reason my “share this” links on each product detail page is now longer showing, even though the following code is on each products short description;

[share title=“Share this Product” facebook=“true” twitter=“true” google_plus=“true” linkedin=“true” pinterest=“true” email=“true”]

I will put the live site login in secure note.



Hi There,

When I visited the WordPress Updates page, I could only the new update of Cornerstone plugin.

Could you please try temporarily disabling the SiteGround Cache to see the new update of X theme appear?

To remove the read more button over the product images, please add this custom CSS under Theme Options > CSS:

.woocommerce li.product .entry-header .button {
    display: none;

Please purge all the cache and check again, the social share icons are loading fine on my end:

For about the icons display issue, please take a look at this release note:


Yes that is the problem. The live site is validated but when you go to updates cornerstone says that it can’t update because it isn’t validated. I have been through a whole process to try and solve this problem. Making a staging site, deleting the theme and cornerstone then downloading and installing a fresh copy of X. I did all this and did all the updates on the staging copy, the validation problem went away. I then pushed the staging site to live but the problem was still there.

I really need a solution to why this live site is saying it is validated but will not accept updates.

Thank you for the other tips to resolving the other issues since doing the above.

Hi @Pixel8r,

I installed 3 plugins (debug bar and its addon). It’s the debug bar menu in the admin toolbar.

In the remote requests, you’ll see all outgoing requests and it doesn’t display the request to our server. Which means something is blocking it. So I tried the console to issue a remote request to our server and got 404, but I can’t get the details of the result.

My initial finding is, the request to our server is being overridden by something else, or being blocked. Would you mind providing your FTP login credentials as well? Maybe I’ll directly test the result from theme’s request.


Ok thanks I have just made an FTP account for you and include details on secure message

In regards to the sharing icons problem. The sharing icons are showing up if I use Chrome but not in Safari. I have tried clearing the cache and restarting the browser but they still do not show up.

This seems strange as they previously worked in Safari and I would like to get them working in all browsers again.

Hey Mark,

Your server is empty. Please give us the correct access.


I am very sorry please try again with the details above, it should now take you to the right folder.

Hi Mark,

I did some tests and I could not find the reason why the automatic update is not working. I still think this is a problem of the hosting service not being able to access Themeco servers.

You can contact your hosting service provider and ask them to make sure that there is a cURL access to Themeco servers as mentioned in the troubleshooting section of the article below:

You will need to update the theme manually on your live server manually. I uploaded the zip file of the latest version in wp-content/themes/ folder. Please use the File Manager panel of your hosting service to unzip that file. Before the unzipping, you need to rename the x folder and make it for example x-backup.

After that you will need to delete the Cornerstone plugin from the WordPress Admin, and go to X > Validation and wait for a few seconds and the new version of the plugin will be installed.

The current version of the theme is 6.2.3 and that is why the theme forces the version 3.2.3 id the Cornerstone. As the version, 3.2.4 will not compatible with the version of the theme.

Thank you.

I have been in conversation with SG support and they can’t seem to find the problem. They have asked me to ask you these questions;

  • Check with the support team the exact CURL request that the theme is making so we can execute it from the server’s Shell.

  • Request more information to be provided about the blocked request - if there is a such, our server will return a specific Status code that should be logged in the access logs of the remote server.

Hey Mark,

Regretfully, I could not find what’s causing this either. I’ve seen this line in your WP Config define('AUTOMATIC_UPDATER_DISABLED', true);. I’m not sure if that affects automatic updates. I’m afraid to touch your setup and also your htaccess as it has some https config in there so I might break your site. Would you mind contacting SiteGround if it’s possible to remove that and restore WordPress’ default htaccess setup? If that doesn’t work, I’ll forward the information SiteGround has requested to the appropriate person.

If you could do a manual update in your live site, that would be the quickest method to update now. The fastest way is to login to your cPanel and delete the X parent folder then upload the latest installable zip file in your themes folder and extract it using the cPanel unzip function.


Hi Christian,

Siteground have just managed to get cornerstone updated, but for some reason X is still stuck on 6.2.3 and not showing in the updates. I will try doing the manual update of X this evening and hope that this problem goes away for future updates.

SG just compared the .htaccess on the staging server to the one on the live site and they are both the same. The staging site is working as it should though. I am not going to try going back to the standard one as I think it will break wordfence firewall.

I am also unsure as to what the define(‘AUTOMATIC_UPDATER_DISABLED’, true); bit is in the WP Config. Do you think it is safe to just remove that?

Thanks for your help.