I have certainly come across some tags in downloaded themes which cause problems until the code is removed – the last I recall was some gravatar code in comments I think.
That said, it could well be poor use of the tags and a failure of the theme author to correctly wrap it in conditional tags.
As for plugins that we may put in – yep, I get that. Blogtimes is but one.
I use the following for my tags:
<?php if (function_exists('do_something')) do_something(); ?> That way if you turn off the do-something plugin, nothing goes nasty.
but is it possible to NOT have plugin tags left in the template files crunch your site when the plugin is deactivated?
Not really. You’re talking chicken and egg, actually. Once the plugin is deactivated none of the plugin code is available or runs any longer, so precisely what could the plugin provide that would somehow satisfy any PHP calls against it? As it currently stands, this is the responsibility of the template author using a technique like IanD mentioned.
So the user or the plugin author should use IanD’s conditional code to stop the tag from borking the page?
Sometimes I have to turn off plugins for testing things, so they are off for a day or two and then I turn them back on. Or less. Or I will want to try something new to see if it works to replace that one and will want to go back if it doesn’t.
If it is no good, I don’t have a problem getting rid of the tag, it’s just for the other occassions. When upgrading the last time, everything choked on my site and I panicked, until I found out that it was because that upgrade turned off all my plugins and one of the meta tag plugins wasn’t recognized so nothing got past the start of the head in the header. Painful lesson.
So the user or the plugin author should use IanD’s conditional code to stop the tag from borking the page?
Almost. The user or the template author should use conditional code.
Put another way, if you have to modify your template to get a plugin to work — like the spelling checker plugin if you want to add the spell checker to the comments section, for instance — surround any call to the plugin function with that conditional.
There’s nothing I as the plugin author can do in that case to “protect” the user. If the user later deactivates my plugin or it gets deactivated unwillingly none of my plugin code is now available. It may as well not even be on the server. So there’s absolutely nothing I as that author can do at that point because all of my code is unused, hence the crux of the problem.
There was talk on the hackers list about coming up with a way to add some sort of “protection” to the plugin system, but it all seemed like a duct tape kind of solution from the start to me and it never really went anywhere.
Most of my CG-PowerPack examples use the wrappering approach that Ian pointed out. If a given plugin function doesn’t exist, don’t try to do whatever the plugin was going to do for you… 😉
-d
That would be nice.
I’d like to add this information to the codex articles on making Plugins and Troubleshooting.
Thanks.
