Lack of interest 2.0 - Better Template Compiling

This suggestion has been closed automatically because it did not receive enough votes over an extended period of time. If you wish to see this, please search for an open suggestion and, if you don't find any, post a new one.

Jake B.

Well-known member
Currently in 1.X it seems that (at least from how I understand it from the small amount of digging I've done into the subject) is that when you install/upgrade a style it recompiles every template for every style that is installed, which makes updating demos with around 20+ themes take absolutely forever. Perhaps for 2.0 have something that only compiles templates that changed. Also, it seems that the templates do not *actually* inherit from the parents, they recompile for every theme. I'm sure there was a reason for doing this instead of having it inherit the compiled templates from the parents as well, though I'm not quite sure what it is. Just seems like inheriting from the parent would be much faster (at least for the compiling process) than the current method. Though, I may be completely full of it and don't actually understand how the current template compile process works (which is entirely possible as I didn't dig into it too much). Perhaps someone could enlighten me on this process if I am incorrect :)

Regards,

Jake
 
Upvote 3
This suggestion has been closed. Votes are no longer accepted.
Also, it seems that the templates do not *actually* inherit from the parents, they recompile for every theme.
There are separate templates for each style/language combination, regardless of whether the child style inherits from the parent or not.
 
One way it could be done is some sort of live template flag that allows templates to be regenerated as a background task without first deleting them all. Then when done, delete the live ones and set the new ones with the live flag.

Either way, I agree... I have 1 style and 1 language and it's painfully slow to rebuild templates and phrases. Enough so that I refuse to add new languages because adding 1 language makes it all twice as slow.

The slowness of it isn't so much the issue for me, but the site being offline for users while it's happening is.
 
It is during XF version upgrades which get vastly slower as more templates, languages and style are added.
True, but that's a situation where a total recompile is necessary (as parts of the compilation process may have changed and it can be very important that the new templates are totally in place or things may be completely broken).

The general comment on timing usually comes up with respect to installing add-ons (or styles) and that doesn't force a closure.
 
True, but that's a situation where a total recompile is necessary (as parts of the compilation process may have changed and it can be very important that the new templates are totally in place or things may be completely broken).

The general comment on timing usually comes up with respect to installing add-ons (or styles) and that doesn't force a closure.

A complete recompile on update of XenForo itsself shouldn't be a problem as it's only run one time. However, when I'm updating the Audentio public demo (like I did earlier today) it's pretty bad because you have to go through the process 20 times.

On our dev board it takes around 10-15 seconds just to save a template because it has to recompile that template for all the children.
 
Rebuilding styles, templates and the rest of deferred tasks is awfully slow for big boards. Especially if you need to do multiple things and everything is rebuild several times.
 
Top Bottom