Hi Dee,
Thanks for writing back.
> 1. do you still need the snapshot even after admin access?
- The more I review this matter, it is becoming clearer that this issue is growing way out of the scope of support that we can provide.
Let me recap the issue: "When Toolset Types plugin is disabled selectively, through a third-party plugin, the layout/design (specifically the header menu which is also part of a third-party theme or plugin and not from Toolset) breaks".
Our official stance and recommendation on this would be, not to disable the core Toolset Types plugin, selectively, since it is not designed and intended to work like this. Until something built-in is introduced for selective loading of our plugins and components, any measures to improve performance would fall under customization, which can not be covered under the support ( ref: https://toolset.com/toolset-support-policy/ ).
> 3. regarding the customization: there is nothing big done to the site, all i am trying is to
> load the website fast with a logic environment. If toolset is a perfect plugin that doesn't
> load all its resources in ALL pages, i won't be working on this. so please update this to
> your developers. I've spent many hours on these plugins, i don't think i can afford to
> drop and start with other solutions. i hope you understand this too.
> 4. after all this discussion and many topics on the performance, is there anything
> done till now on this subject?
- We are constantly working to improve the performance of our plugins, especially when it comes to loading resources like CSS and script files. This is challenging since a balance needs to be maintained between performance and ease-of-use.
Toolset plugins are designed for a wide range of users with different needs and technical backgrounds. Many of those would expect to have the ability to place the Toolset components like views, content templates, forms, maps, etc on any page of their choice.
Manual control over loading Toolset components on selective pages can make things complicated for those users and automatic detection would inversely affect the performance, instead of improving it. This is the reason that the development team is carefully planning the best way forward for this, that works for most users, out-of-the-box.
Hope this makes clear why restructuring and overhauling of this scale, is so challenging, sensitive and time-consuming.
I also couldn't help but notice that this thread started with the need to improve how multiple script files are loaded on the website. Instead of removing them altogether, have you instead considered using a cache and code optimization plugin which can minify them and either load them as a single file or as an inline code?
In my opinion, that is a better strategy since:
- you won't have to worry about future updates which may depend on those removed files, which means less maintenance time in the long run.
- minified and consolidated CSS and JS files or even loading them inline, will give your website's performance a significant boost and you can even control whether you'd like to load them in the header or the footer of the website.
( you'll need to find the right balance of the settings that works for different components of your website, but that effort will still be far less than management of loading or unloading of built-in files, manually )
- you won't have to add and manage the custom PHP code with conditions to enqueue or enqueue scripts on the selective pages. It's important to note that processing of those conditional code blocks also consumes the server's processing and loading time.
Here are a few articles which review the popular cache and code optimization plugins:
lien caché
lien caché
regards,
Waqar
