SSL issues on page happening sporadically

Hi Paul,

Thank you for writing in, can you check your site’s WordPress Address (URL) and Site Address (URL) under Settings, if its set to https, if not, please do my suggestion here to use Better Search Replace plugin.

Remember to clear all your caching features (plugin, server-side, CDN, and browser’s cache) after updating.

If the issue persists, please provide us login credentials in a secure note so we can take a closer look.

Let us know how it goes,

Hi Friech,

You are certainly on the right track. I inspected the pages in question and the broken pages were littered with https calls to our non-secure site. The working pages had no such calls.

We have found in the past that to fix the pages all we need to do is open them in Cornerstone and save them. It is not necessary to even make any changes.

The question is what keeps breaking them? This has happened multiple times now, and it happens when we have made no edits to the pages in question. Something is making these changes to our pages. It is possible that I may have updated Wordpress and/or one or more of our plugins without rechecking all the pages to make sure the updates didn’t break anything, but I don’t think I had updated anything in a while.

Unfortunately we accidentally fixed all pages with problems so it will be harder to troubleshoot, but do you have any ideas about what might be changing our pages between edits?


Update: I just updated all of our plugins one at a time, deleting the cache and spot-checking pages after each update. Everything still seems ok…

Hi @ErgoArchitecture,

Glad things sorted out on your end now, It could be a caching related issue, also a WP Force SSL plugin might help to force users to view the site in https protocol.


Hi Friech,
I’m afraid that we have not fixed it as this has happened several times before. And to be clear, our site is not HTMLS. It is plain old HTML. Does using Force SSL provide some measure of security to HTML sites?

Hey @ErgoArchitecture,

To better assist you with your issue, kindly provide us access to your site so that we can check your settings. 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: How The Forum Works

Best Regards.


In your Settings > General you didn’t update the WordPress Address (URL) and Site Address (URL) but I already update it.

I also found out that your SSL certificate is not valid, please install a new SSL certificate.

Please let us know how it goes.

Thank you.

Hi Cramaton,

As stated repeatedly in the texts above WE ARE NOT A SECURE SITE! PLEASE STOP CHANGING OUR URL TO HTTPS! IT BREAKS OUR SITE! And if you do make unauthorized edits I would appreciate it if you would at least check the site to make sure that it is working after you make the changes.

We are a plain old HTTP site, and something (or someone) keep changing portions of our code to https:// which obliviously causes problems. In this case it was you. In other cases we are not sure what is doing it. We just find that our html has changed when we had not edited the site for weeks or even months.

It is a very frustrating problem, because we expect our site to stay the way we left it after we have confirmed that everything is working well.


Hello @ErgoArchitecture,

I have investigated the issue. You have installed Autoptimize plugin and it seems that it serves the minified resources using https. Since you do not have an SSL, the plugin resulted to an error. We recommend that you disable this plugin and test your site again. You may also test out other alternative like the W3 Total Cache plugin instead.

Hope this helps.

Thanks for the suggestion. I will check with the plugin author and see if he thinks we might have one of his settings misconfigured.


Hi Steve,

Yes, let us know how it goes. And make sure to clear all your caching features (plugin, server-side, CDN, and browser’s cache) as often times an unusual issue like this is caused by a cache.


Hi again,

We did a spot-check this morning and have already encountered a problem: the EXPERTISE drop down on this page: is serving httpS:// URLs causing page loads to fail with a mixed content error. Please remember that we are not a secure site!

I looked at the menus and can’t see anything that would cause this, and the (same) menu seems to be fine on all the other pages we have tested.

Please do not make any changes to the menu, as they have features that may look like errors to you such as redundant items that change the order on mobile. If you want to experiment, please make a copy and experiment on that. Otherwise, we would be happy to make any changes that you suggest.



UPDATE: It is about an hour after the email above, and the problem is no longer occurring. I did not edit the site in any way. I just went in to the admin console and looked around. We had left the offending page/menu in place to help troubleshoot, but somehow it is no longer misbehaving.

What is changing the code? Is it possible to set up a change log that will time stamp any changes to the code or cached pages, and better yet show what is generating them?


Hello Ergo,

As what I have noticed in the screenshot, it is the Autoptimize plugin is generating the error. It could be that the cached version is causing it. As soon as the new cached version were generated, it disappears.

Hope this helps.

This makes no sense to me, and I don’t know what screen shot you are referring to. The site was serving a cached version that worked just fine this morning at 10 am when I posted my update. Now, that same file is littered with https calls again and the page won’t load as a result. First, why would Autoptimize re-cache the page if it hadn’t changed? A second, why would it cache it differently that it had cached the same page hours earlier? And finally, why would running the same plugin on the same file again fix the problem?

Also, from the author:

Autoptimize uses a WordPress function to determine the URL from which the optimized files have to be served (content_url()) which is based on your settings, so no I see way AO itself would switch to https:// after a couple of months no.

I am likely to believe the author, as I doubt the plugin could be installed successfully on over 1 million sites if it couldn’t tell http from https!

I need to get this fixed, but you have presented no evidence that it is Autoptimize. Can we do better than guessing? How can we log files to troubleshoot?


Hello Ergo,

I have checked it and compared to your screenshot that the error is coming from the plugin.

If you temporarily disable the Autoptimize plugin, you will not have any issue because the said file in the screenshot will also not load. This is why I have said that the issue may have came from the plugin or at least the cached version of Autoptimize plugin.

Best Regards.

Yes, but at the bottom of the screen shot are plain old non-minified PNGs that aren’t loading either.

The Autoptimize theory also doesn’t explain why every cached version of every page works in the morning, then no longer works in the afternoon when nobody has edited the site. I tend to believe the author that it simply forwards on whatever html it is passed. Why on earth would it do anything else?


Hey Steve,

We’re sorry for the long back and forth conversation here and I understand that it’s frustrating along with the issue you’re experiencing. We should have made it clear that what we provide here is only theme support and that we should only prove if our theme is the one causing the problem and not 3rd party factors.

With that said, please clear all caches of the optimization plugins you have now including Autoptimize and the Cache Enabler plugin and any other cache system your web host has enabled in your site. Please contact your web host to make sure all caches are cleared. DO NOT enable caching while the issue persists.

After that, temporarily switch to the parent theme and deactivate ALL 3rd party plugins and monitor if the issue will persist. If it doesn’t persist then one of the plugins and/or the child theme is causing the issue. Consult with a developer if this is the case. If it does persist, read on.

Please note that our theme also could not change the layout of your site nor any other WordPress settings automatically on its own as there’s no feature in it that could do that.

The only thing that could change settings in your site automatically are:

  1. People you authorized to log into your site. If you suspect us, please change the credentials right away so we can’t log in.
  2. 3rd party systems that can automate server / WordPress actions. I have no specific idea but certainly, it’s not our theme because as I said, it has no function to update settings automatically. Please ask your web host.
  3. Your site was hacked and got injected with code or function that could change settings. If this is the case, reinstall everything on your site. If you’re not sure how to reinstall WordPress, please consult with a developer. To reinstall our theme, go to your dashboard, click on a license and download the Latest of Stable version then uninstall X and Cornerstone in your site and install the fresh copy.


Also, I checked the source code of your site and all URLs are in HTTPS. You could have performed a search and replace turning HTTP to HTTPS. Please reverse the process.

That is all we can do for this case because as I said, there is nothing in our theme nor our bundled plugins that could change settings automatically, randomly nor in a timed fashion.

Thank you for your cooperation and understanding.

Hi Christian,

Thanks for your response. I understand that you are here to support your product and not 3rd party plugins which I agree are likely the culprit. Perhaps I didn’t explain well in my first email because I though it might be something simple or something that you had seen before, but I am having trouble troubleshooting because I feel that Cornerstone is buffering me from direct access from data that might help me troubleshoot.

You mentioned that we may have global replaced https for http in our code. I don’t even know how to access our HTML pages! I have tried to do this before, and found this Themeco article which seems to imply that it is not possible with Cornerstone.

I have looked for the HTML in our FTP site, but oddly can’t find it there either. I can see what is served to chrome through developer tools, but this is likely not our actual html but rather a static cached page and since I suspect that something is changing our original html on the fly before it is served this doesn’t help much.
I would LOVE to verify that by inspecting our html directly. Is there an article on how to do this without having those pages broken in Cornerstone?

It may not be this simple as I understand that the HTML is in the Wordpress database and may not even exist as individual HTML pages, but if the database is just an index of actual HTML pages, and they exist somewhere, it would be great to verify that the timestamp of the original pages is not changing unless we edit them.

I don’t have any of the tools to do this at present, so if Cornerstone provides access to the underlying HTML I would love to know how to gain this access. Even if it is only possible through FTP I can Google that and perhaps figure that out too.

Thanks for your help!


Hey Steve,

Thank you for providing more details. Let’s stick to the HTML and the Time Stamp aspect this time.

What you read in the other thread is correct. You can’t edit the HTML generated by Cornerstone and you don’t need to edit HTML for replacing HTTP to HTTPS. You must have used a Search and Replace plugin for that. That is what I’m referring to when I said you need to reverse the process which means searching for all https text in your whole website and replacing it with http.

Regarding page/post timestamps, nothing in the products we provide has that feature as it’s already built-in or available out of the box in WordPress. It’s called Revisions. You can learn more about that here:

Please just note that doing a Search and Replace and other database operations do not count in WordPress Revision system. It only does record page/post edits.

If this https issue still persists, it is your web host that should help you with that. If it’s not a 3rd party plugin causing the issue, it’s highly likely a database operation of the web host that’s changing http to https in your site.

Hope that helps.