This support ticket is created Il y a 7 années et 2 mois. There's a good chance that you are reading advice that it now obsolete.
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.
Aucun de nos assistants n'est disponible aujourd'hui sur le forum Jeu d'outils. Veuillez créer un ticket, et nous nous le traiterons dès notre prochaine connexion. Merci de votre compréhension.
I want to change the server environment of the site. Would it be possible to install the duplicator plugin for me so that I can get a clone of the site.
Hi Shane,
Done... by the way... your account is a super admin account... so feel free to add or remove items. Its a test site pure for this issue.. so it's no issue at all if things change or get lost.
The good news is that the issue is not related to CRED at all. The bad news is that it is with our Types WYSIWYG field.
It seems that when you have quite a number of these fields on the same page it dramatically slows down the page loading so we are suggesting that our developers find some way to improve this.
Nothing else we can do here except to reduce the amount of WYSIWYG editors on the page .
I am aware that the more WYSIWYG editors, it slows down the backend....
BUT....
could you please inform at the developers and give an explanation why the page gets slowed down even more when CRED is active?
I don't have a satisfied feeling that they say it isn't CRED at all... I for sure know that the WYSIWYG editors slow down the page on the backend. Has been the fact for all four years i've been using Toolset now.
BUT what I don't get is... the slowdown increases at least 2 times when CRED is active! There somehow needs to be a connection... or try to explain to me why there shouldn't be a connection.
I already communicated the conclusion it had to do with the custom fields on the 27th of September:
==== quote ====
Next I disabled the post fields group linked to pates, therefore pages didn't have a toolset post type taxonomy or anything linked to it.
--> loading time with CRED enabled: +/-9sec
--> loading time without CRED: +/-9sec
So no noticeable difference with CRED enabled or disabled and a tripled increase in loading speed!!!
So somehow the custom post fields to have a huge impact on loading speed of the backend of the page. And when CRED has been enabled this increases with approx 30 seconds.
Based on the analysis done, it could be that the button from CRED loading onto the editors. Removing CRED removes the CRED form button from all the WYSIWYG editors and this could be why you are seeing some improvements in page load times.
However the root issue is the WYSIWYG fields and not CRED itself.
QUOUTE: this could be why you are seeing some improvements in page load times.
Well it's not SOME improvements... its around 50% ... looks like thw hook for adding the button and the WYSIWYG editors are real resource killers...
For this website I don't have time to switch the whole design, for new ones I will see if it also happens when using a Parent Child Post type configuration...
Will the new Types make it possible to set a max amount of child posts for a post? This is why we used this setup... we don;t want the end user adding more and more... so we choose a max of 10 CTA boxes... I can design it in such a way the CTAs are saved as Custom Post, but not sure if I can set a max childs per post and if that would solve the loading on the backend. As the Child posts do also contain those fields.
I do as well suspect that the buttons are causing the problem since each button will be added to each WYSIWYG. I suggested this as an improvement to our development team.
Currently there isn't a way to limit the number of child posts per post.
