Home › Toolset Professional Support › [Resolved] Edit Content Template page with Conditional has extremely long load times
This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.
Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.
Sun | Mon | Tue | Wed | Thu | Fri | Sat |
---|---|---|---|---|---|---|
- | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | 7:00 – 14:00 | - |
- | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | 15:00 – 16:00 | - |
Supporter timezone: Europe/London (GMT+00:00)
This topic contains 10 replies, has 2 voices.
Last updated by erikd-6 4 months, 1 week ago.
Assisted by: Nigel.
I am reopening a ticket for this issue as a reaction to Nigel's reply to my reply on the blog post https://toolset.com/2024/07/toolset-1-6-16-essential-updates-for-wordpress-6-6-and-better-workflow/#comment-975263. I would like to discuss this issue further with Nigel, as he suggested in his private reply. I have additional info I would like to share.
The extremely long load time of this content template I made is caused by a conditional. The conditional checks if the content of the post-content field of a product is empty and if it's not, it displays the post-content field plus a price field and an add-to-cart field. This looks like really basic stuff to me.
With this conditional block the content template has a load time of 197 seconds.
When I remove this block, the content template loads in a few seconds.
* The uploaded image shows the structure of the content template in the block editor. The conditional block I temporarily removed for testing load time is the bottom part.
Languages: English (English ) Spanish (Español )
Timezone: Europe/London (GMT+00:00)
OK, it may be relevant that you are testing whether the post body is empty or not.
I don't know for sure, but I can imagine that getting the post content involves passing it through the_content filters, which could add a lot of overhead to the checks, more so on a complex or large site.
We can try to avoid that by updating the condition to test the output of the wpv-post-body shortcode where we can set suppress_filters to true.
First, you'll need to go to Toolset > Settings > Front end Content and under Third-party shortcode arguments you'll need to add wpv-post-body (even though it is actually a built-in shortcode).
Then edit the condition of your Conditional block, and choose a Custom Shortcode as the source, specify wpv-post-body as the shortcode, and then add these shortcode attributes (as shown in the screenshot):
view_template="None" suppress_filters="true"
Can you try that and see if it materially affects the template loading time?
Hi Nigel,
Thanks for your reply. I tried this and it absolutely works. Loading time of the CT is now back to just a second or 2.
Do you think this can be implemented in a future version of Toolset Blocks so that this also works with the post content field? If not, this workaround will do.
update:
Sorry, my first impression seems to have been a little bit too optimistic. After some more testing by reloading the content template several times, load times now appear to be around 90 seconds. Index WP MySQL For Speed Monitoring shows number of queries for the reload of the CT are slightly lower (1809 versus 2335 queries captured). So there is still an improvement in the load times but now about half of the 197sec they were before. I still run the server on 4CPU's and max IO and with [E=noabort:1, E=noconntimeout:1] in the .htaccess. The rest of the pages load very quickly.
I normally develop in Firefox. Just checked the issue in Edge. Load time of the CT: 95 sec. Seems quite consistent.
To test this further I also made a Content Template for pages with two conditionals both testing if the post content field contains any data or non. Here I didn't apply the custom shortcode but just used the post content field in the conditionals. I applied this CT to one special test page where I copied the content of the product post content into this pages post content field. This CT loads in seconds.
I could now try to duplicate the product content template and assign it to one product only.
Update:
I tried this and it brings back load time for the same CT (but assigned to 1 product only) to seconds.
So it looks like the number of products (or posts in general) a CT is applied to has impact on these very long load times. There are 29 products in this site now, 28 publishes and 1 draft. That doesn't seem a lot to me.
update:
Again I have to correct myself. The first 2 load attempts for this new CT for 1 product only were performed in seconds. When I tried again the load times were back at 90-95 seconds.
Meanwhile the test CT for 1 page still loads in seconds.
Languages: English (English ) Spanish (Español )
Timezone: Europe/London (GMT+00:00)
OK, let me try to do some testing on my own site with a similar set up to see if I experience the same problem.
Please bear with me while I do that.
Languages: English (English ) Spanish (Español )
Timezone: Europe/London (GMT+00:00)
Actually, while I set that up, perhaps you could try something else.
These shortcodes are essentially rendering the content to test whether it is empty or not, but we don't need to render it, we just need to know if it exists or not.
So let's try an alternative approach.
Add a code snippet at Toolset > Settings > Custom Code with the following custom function:
function is_content_empty(){ global $post; $return = empty( $post->post_content ) ? 1 : 0; return $return; }
Then at Toolset > Settings > Front-end Content under "Functions inside conditional evaluations" register the is_content_empty function, so that it can be used in conditional shortcodes and blocks.
The function will return 1 if the post content is empty, or 0 if it is not empty (has some content).
So your condition would look like that in the screenshot, so that what's inside the Conditional block is only output if there is post_content.
This approach should not have any performance implication from testing the presence of post_content itself, and is likely the best option.
Could you try on your site and see what the results are like?
Hi Nigel,
It looks like this works! Load times for CT's testing if post-content has data are normal now.
Could I do the same for testing if a wysiwyg custom field is empty? For example with a custom field "MyWysiwyg" could I make a function with $return = empty( $post->wpcf-mywysiwyg ) ? 1 : 0; ? Is this the right syntax?
Languages: English (English ) Spanish (Español )
Timezone: Europe/London (GMT+00:00)
You would need to get the value of the custom field and test that:
function is_wysiwyg_empty(){ global $post; $value = get_post_meta( $post->ID, 'wpcf-mywysiwyg', true ); $return = empty( $value ) ? 1 : 0; return $return; }
Thanks, Nigel, I will try that.
Now that it has been confirmed that there is an issue with very long loading times for content templates and there is a workaround that fixes this issue, will this be fixed in a future update so that we don't have to apply these types of workarounds?
I find the functionality enabled by conditionals extremely useful and this is one of the reasons why I am a big fan of Toolset.
Do you agree that this functionality should ideally work quickly and smoothly 'out of the box'?
Languages: English (English ) Spanish (Español )
Timezone: Europe/London (GMT+00:00)
Hi Erik
I chatted with the devs about this, and they said it is more complex than it looks at face value, as there are scenarios where the "content" is not stored in post_content but is generated (e.g. using certain page builders) where you would want the content to be generated to be able to test against. Adding settings for whether you want the generated content to be tested versus the stored post_content introduces complexity into the UI.
Given the possibility of using the custom shortcode or custom function features that already exist with conditional blocks and shortcodes, they don't see a compelling case for "internalising" this.
That's the feedback.
Hi Nigel,
Allright. I can live with that.
Thanks for your help. My issue is resolved.