Plugin System Design Hole
 

Am I the only one thats noticed you cant use a plugin to modify the $specialtemplates via plugin prior to their first call through init.php

This means regardless, I have to use atleast 1 query if I have anything extra that I need for the hack ie. a datastore item; that could have otherwise been fetched on the initial run.

Gotta love plugins.

ps. Yes I know plugin code is stored in the datstore itself which would present the flawed logic of

"Cannot modify specialtemplates prior to init due to the fact the plugin code for the specified hook has to be fetched before it can be evald into modifying anything."

Thus the answer would seem that plugins need to be stored somewhere other than the datastore; so it can be used prior to init.php

check through Andreas' hacks, you are not the only one ;)

See for discussion: CODERS PLEASE DISCUSS!!! Pre-Datastore modifications with XML-files (UPDATE 28-7)

PS A finished implementation is now not released by Andreas anymore, Brad has taken over this one: [developers] Custom datastore support for products

There are many ways to get round it - the easiest being to add a line at the bottom of config.php.

Personally I think you could just use the XML system that bitfields, cpnav etc use - it just looks for xml files of the form datastore_xxxx.xml

Inside those XML files is

The product is identified in the datastore tag.

The script tag 'name=' is checked against "THIS_SCRIPT" and if matched, all the datastore items specified in load tags are loaded. If the script tag has no name parameter then it is always processed. You no longer need a $specialtemplates array at all then, since vbulletin would have a default database_vbulletin.xml

Just an idea, allthough I've actually thought of doing this for myself to test it, but not got round to it yet.