Preview/Conditions with Page post type stopped working


I was finishing the conversion of a WooCommerce shop to new Pro. The last thing I wanted to do is to convert the checkout page to Pro and add the [woocommerce_checkout] shortcode to it. I wanted to add some other elements to it as well. If I remember well, this used to work before. The Checkout page normally receives all the Woocommerce body classes automatically, as soon as that page is set as a Checkout page in WooCommerce settings. No matter if it had Pro active on it.

However, once I did that, the checkout page was not loading anymore, and I was starting to get server errrors.

I have recreated the issue on the Staging site, and deactivated the Child theme, all other plugins, cleared cache, resaved permalinks etc. The problem persisted.

I have then reverted the page, removed the Cornerstone shortcodes and placed the [woocommerce_checkout] shortcode back in the the WordPress editor. However, the problem persisted. I had to create a brand new page and assign that as the WooCommerce checkout page. It started to work again.

The issue:

I wanted to assign the dedicated header to that page, (Called Shop Header). When I wanted to preview the Checkout page, the list of Pages were not loading:


The same infinite loading is happening when I want to use Conditions to assign any Header to any Page. The list of pages is not visible.

I do have a backup, but if I revert to it, I will lose 10 hours of work. Right now a wrong header is assigned to a live site, on the checkout page. Is there anything I could do to get the list of Pages back in the Preview and Conditions lists?



I was checking into this and I think I may have locked the site up. I’m really sorry about that. Can you reactivate WooCommerce? Or temporarily deactivate the plugin causing this error:

Fatal error: Uncaught Error: Call to undefined function get_woocommerce_currency() in /home/customer/www/ Stack trace: #0 /home/customer/www/ Wsb_Hub3_Admin->wsb_hub3_notice('') #1 /home/customer/www/ WP_Hook->apply_filters(NULL, Array) #2 /home/customer/www/ WP_Hook->do_action(Array) #3 /home/customer/www/ do_action('admin_notices') #4 /home/customer/www/ require_once('/home/customer/...') #5 {main} thrown in /home/customer/www/ on line 714

It looks like an addon for WC but it isn’t checking to see if WC is active before loading.

Once that’s resolved I can keep investigating. The post preview runs on a backend system called the “locator” and it’s also used on the content index screen here:

It looks like it’s returning an empty response but still with a 200 code which is abnormal. Failure usually involves some kind of error code.

If you were able to provide FTP credentials as well I could test more safely without risk of triggering errors like that again.

Hi @alexander, thank you for looking into this personally.

The plugins to deactivate before WooCommerce are:

  • WooCommerce MX R1
  • WSB HUB3

I didn’t know that they are not checking if WC is active. I’ll notify the authors. Thanks.

I am adding FTP credentials to the secure note.

Thank you!

Thanks @Misho,

I’m making progress here, but still haven’t cracked it. Here’s what I’m discovering, some of this might not be useful to know and I’m talking aloud a bit here. Some very interesting things going in. Thanks to some additional testing after having FTP I was able to determine it is running out of memory on those calls. I’ve added this code:

add_filter( 'cs_locator_limit', function( $count ) {
  return 15;

Thats lowers the number of posts to find from 50 to 20. When I tried it at 5 posts it was sing 118mb of ram to get and oddly that spikes to over 200mb if all plugins are disabled. At 15 it doesn’t use too much more memory. I think what’s happening is that some of the posts are triggering code paths that bloat out the memory. The post with ID 835 is particularly heavy (I think that’s one of the home page translations). I’m adding a secure note where you can see the profiling results. On my local development install I’m not getting anything that uses more than 8mb with a similar number of posts. I’ve also tried downloading your homepage as a template and adding it to my site

At the very least, the above code will let you keep using the site. I’m going to take another look at this tommorrow. I’ve been trying to narrow it down this afternoon but haven’t landed on a solution yet.

I did have one question. Are you seeing the same conflict on the staging site? If not, would you mind sharing those details with me again? It might help to compare them. Thanks!

1 Like

Thank you so much @alexander for all this effort!

Yes, the staging site with no plugins enabled does the same. Credentials are in the secure note.

Btw, the Author of the MX R1 plugin has pushed the update after I have contacted him, so that plugin does not have to be turned off before WC anymore. (This plugin sets the fiend for the VAT number if the buyer is a company).

Thanks again!

Hi @Misho,

I’m sorry for the delay on this one. I’ve still not been able to crack why we’re hitting memory peaks like this. Will keep you up to date. I won’t have a chance to look at it again until early next week.

No Problem @alexander!

After your tweak it works, however if the needed Page/post is not on the list among 15, the search cannot fetch it. Not sure if this is important to mentioned.

Thank you!

Glad to hear that, @Misho. I’ll forward your message to Alex.

1 Like

Let me just go back to the beginning of this thread, and point out that this happened to me when I tried to create a custom Checkout page. So a Cornerstone Page with the [woocommerce_checkout] shortcode. That might not be the actual reason for the problem. Maybe it just correlated with it.

However, not being able to customize the Checkout page is quite a problem on its own. I see comments popping up in the community, where people are asking why is this not possible and will it be at some point?


Hi @Misho,

I’m sorry for not getting back to you sooner. I’ve installed a development build on your site which is 4.1.0 plus a couple of fixes I’ve gotten in today (will be going out on automatic updates as a point release tomorrow). It’s still slow, but if you search in those fields or just scroll to the bottom it will load the next 15 and that process can repeat until they’re all available.

It seems to be working more efficiently on 4.1 than 4.0 but it still takes an incredible amount of memory. I’ve not been able to narrow that down any further, but I don’t see how it could be related to WooCommerce since I’ve done testing with plugins disabled.

As for the checkout page, there’s more we want to do there in terms of customization but regretfully won’t be able to until we can add base level form styling which will be part of the theme options reboot. I know there’s more to be desired with WooCommerce customization but we were kinda running into our own global styling limitations and instead of forcing something to work with the current stacks we’re just going to wait until you can style forms globally.

Would you happen to have a way for me to access the database itself? Perhaps cPanel so I can run a backup, or even just send me a raw database dump? If I could run it in a local development environment I would be able to do more testing and isolate the problem further. Thanks!

Hi Alexander!

Sure, no problem. However Siteground moved away from cPanel. They are complicating with letting people in by asking for authentications and stuff. The database is in the Secure note.

I am now noticing that the database is huge! 700mb. It is also duplicated for some reason. One of those two are probably safe to delete.

Thank you!