2010-07-14, 06:27 PM
inc/adminfunctions_templates::find_replace_templatesets() is a function plugins use to modify templates. It is documented as "Find and replace a string in a particular template through every template set."
The function has many pitfalls, many plugin authors do not use it correctly in the first place (hard to find a concise pattern). However even if they do use it correctly, the function simply does not work. The problem is that there are return statements in this function that make it return early, before the actual replacement is being made.
Here the function returns if the change could not be applied to the original, unmodified master template. This is why most plugins fail to undo the changes they made, because their changes naturally are not in the master template. This can be worked around by using the $autocreate = 0 parameter (default 1). However it's not obvious to the average plugin programmer and not documented either.
While looping over template sets, the function returns for the first template that does not match. So an unusual theme, or themes that were imported after the plugin made its changes, bring the whole party to a crashing halt. Since the results queried from the database are not ordered, the exact behaviour in this loop is undefined. Depending on the order it may create some templates and then simply stop.
Ideally the function should replace as many templates as possible instead of just stopping and returning just because something does not match. The way it is now, any plugin that uses find_replace_templatesets is buggy because it can not be guaranteed to make the template changes as intended by the plugin author.
The function has many pitfalls, many plugin authors do not use it correctly in the first place (hard to find a concise pattern). However even if they do use it correctly, the function simply does not work. The problem is that there are return statements in this function that make it return early, before the actual replacement is being made.
$master['template'] = preg_replace($find, $replace, $master['template']);
if($oldmaster == $master['template'])
{
return false;
}
Here the function returns if the change could not be applied to the original, unmodified master template. This is why most plugins fail to undo the changes they made, because their changes naturally are not in the master template. This can be worked around by using the $autocreate = 0 parameter (default 1). However it's not obvious to the average plugin programmer and not documented either.
while($template = $db->fetch_array($query))
{
if($template['template']) // Custom template exists for this group
{
if(!preg_match($find, $template['template']))
{
return false;
}
While looping over template sets, the function returns for the first template that does not match. So an unusual theme, or themes that were imported after the plugin made its changes, bring the whole party to a crashing halt. Since the results queried from the database are not ordered, the exact behaviour in this loop is undefined. Depending on the order it may create some templates and then simply stop.
Ideally the function should replace as many templates as possible instead of just stopping and returning just because something does not match. The way it is now, any plugin that uses find_replace_templatesets is buggy because it can not be guaranteed to make the template changes as intended by the plugin author.