Preview/Conditions with Page post type stopped working

[Misho]

Hi!

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?

Thanks!

[alexander]

@Misho,

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/mojemalozlato.com/public_html/wp-content/plugins/wsb-hub3/admin/class-wsb-hub3-admin.php:714 Stack trace: #0 /home/customer/www/mojemalozlato.com/public_html/wp-includes/class-wp-hook.php(287): Wsb_Hub3_Admin->wsb_hub3_notice('') #1 /home/customer/www/mojemalozlato.com/public_html/wp-includes/class-wp-hook.php(311): WP_Hook->apply_filters(NULL, Array) #2 /home/customer/www/mojemalozlato.com/public_html/wp-includes/plugin.php(484): WP_Hook->do_action(Array) #3 /home/customer/www/mojemalozlato.com/public_html/wp-admin/admin-header.php(292): do_action('admin_notices') #4 /home/customer/www/mojemalozlato.com/public_html/wp-admin/plugins.php(603): require_once('/home/customer/...') #5 {main} thrown in /home/customer/www/mojemalozlato.com/public_html/wp-content/plugins/wsb-hub3/admin/class-wsb-hub3-admin.php 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.

[Misho]

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!

[alexander]

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!

[Misho]

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!

[alexander]

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.

[Misho]

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!

[christian]

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

[Misho]

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?

Thanks!

[alexander]

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!

[Misho]

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!

[alexander]

Thank you! I think I finally figured something out here. Allow me to summarize

• The WordPress postmeta is notorious for not being indexed well and on very large sites there are little bits of information that can only be located by scanning the table
• Your postmeta table is 500mb+ which is doesn’t really add up. It’s a larger site, but certainly not that large.
• The _cornerstone_data by far the biggest contributions to the site being large. I’ve been noticing this for a while in general and after 4.0 I know we will need to spend some time refactoring to prevent duplicate data from being stored
  • Effects and Loopers added dozens of new keys that get stored on most elements. The entire state of every element is saved into the post meta table
  • It still stores elements where values have not changed from the default. I’m looking into a way where we only store the values that have changed. This is a big performance opportunity for Pro.
• However, this problem is tremendously exacerbated on this site.
  • For each post built in Cornerstone there should exactly one instance of _cornerstone_data.
  • In this DB there are cases where individual posts have hundreds of duplicates
  • As a final test, I deleted all the posts with IDs that had duplicates of 100+ and ran the orphan meta cleaner in WP Optimize. At this point everything was working normally

On your end I recommend finding a way to clean the database of the duplicates. Meanwhile, I’ll work on getting Pro into a better place and avoid the possibility of massive post meta objects like that. The only thing I’m not sure of right now is how this was even possible to begin with. The way Pro interacts with post meta only updates the existing value if it exists or creates a single new one. The only thing I can think of is some kind of third party code that manipulates post data. It could be WPML, but I’ve not seen this happen before.

Thank you for your patience while we’ve investigated this issue.

[Misho]

Thank you @alexander!

The entire WP database was duplicated for starters, meaning each table was presented twice with a different prefix. I saw this earlier with Siteground. It might have to do something with restoring backups. I have deleted the entire duplicate of the database, which helped a bit. I still need to find a way to remove duplicate posts. I have built this site in the beginning of 2016. and redesigned it twice since, upgrading it to Pro etc. A lot of junk has accumulated over time.

Thanks for the list of duplicates! I am noticing that those with 100+ duplicates are mostly Homepage translations in other languages. It does smell like WPML. I have a history of issues with WPML, but it seems to be the only Multilingual plugin compatible with Pro:

I greatly appreciate your efforts to improve Pro’s performance wherever you can. It already is among the most performant Theme/Builders out there.

[alexander]

That makes sense. I’ve actually been emailing a bit with the WPML team. They’re integrating Pro with their Advanced Translation Editor and they’re taking a look at our integration internals as well. That won’t be available until April at the earliest but it’s good to know that we are able to work a bit more closely recently.