Template mods in a plugin - template_compile

[AusPhotography]

Based on this discussion... http://www.vbulletin.com/forum/showthread.php/376558-Might-fancy-another-upgrade?p=2138507&viewfull=1#post2138507

I've moved all our site template mods into a plugin hook@process_templates_complete which does this (proforma)
if (!empty($vbulletin->templatecache['TEMPLATE']))
{
$vbulletin->templatecache['TEMPLATE'] = str_replace($findtext,$replacetext,$vbulletin->templatecache['TEMPLATE]);
}
It works quite well and we don't have a lot of modifications.
Note: If it's a special template like $header you apply the same code directly to the parsed $header variable.

BUT! the problem is that the code is executed every page load (digitalpoint's post above).
Ideally I should modify the template one at compile time via the hook@template_compile.

The problem I have is how to force a re-compile of the templates in the site database
a) when the product is 1st installed
b) maybe when a product upgrade occurs

Any suggestions on how to force a template re-compile for an array of template names?

It would ideally run on product installation and upgrade!


Thanks!

[Boofo]

Something like this maybe?

if (vB_Template::$template_usage['register'] OR vB_Template::$template_usage['register_rules'])

[AusPhotography]

Thanks, but how does that force the template to be re-compiled?

--------------- Added 1301962238 at 1301962238 ---------------

Digital points advises by PM that I may have to do it long hand via compile_template and looping thru the templates and updating long hand.
I was hoping for a shortcut

[AusPhotography]

Found a solution https://vborg.vbsupport.ru/showthread.php?t=152931&highlight=Template+Modification+System

[ZeroHour]

snoopytas: regarding template_compile, I am working with it heavily right now for a few mods so once done I will write some tips and tricks.

[thincom2000]

The problem I see with template_compile template mods is that, unless the user is running Template Modification System, you would essentially be forcing the user's database to customize that template in each style. Once this happens, it is difficult to determine whether the user actually has other customizations in the template or not, at least not without an expensive 3-way comparison that uses many megabytes of memory. For users that don't have the template merger class (pre-vB4 users) or that are on shared hosting, we can't revert the changes reliably during a product uninstall, upgrade, or discovery of TMS since the last update.

For these reasons I think it is less intrusive for the user and less error prone if we just encourage users to use TMS, and if TMS is not present, to use the inefficient runtime cache edit.