[wp-hackers] function_exists - user woes

[Garett Harnish]

Alex King wrote:

> Heh. Proving the point, I actually screwed up the conditional syntax 
> below, it should have been:
>
> <?php if (function_exists('my_hack_function')) { my_hack_function(); } ?>
>
> :)


Missing a paranthesis is a not what I'd call a major screwed up.  In any 
case, while I agree something like function_exists is a complicated way 
of going about this, there original suggestion has merit (ie: making 
things easier for plugin authours to get their code to run and to make 
it easier for the users to turn them on and off).

Idea 1:  Allowing the plugins to decided what they do when 
enable/disable.  When the function is called that is in the plugin it 
goes, am I enabled?  If so do this, if not do nothing.   Some plugins 
would still break things something fierce like wp-style-switcher ... but 
in those cases it could default to the standard css location ... and 
hope it is still there.  The idea would be to move the intelligence into 
the plugin itself and away from whatever the user placed into their 
code.  This would make it a bit easier for the end user, but would still 
require modification of the index.php in many cases, at least to install 
... and if the user disabled the code then deleted it, it would break 
all over again.

Idea 2:  With PHP5's new object oriented stuff, this might become a lot 
easier (assuming I'm understanding the changes correctly).  Every plugin 
is a class, inheriting a default plugin class.   Every plugin includes 
functions like onload, bypost, menu, etc.  These functions are blank in 
the default class, but can be extended if the authour of the plugin 
needs that functionality.  Onload would be executed when the 
my-hacks.php used to be called, bypost would be executed before each 
post (or something), menu would be called by the menu, and so on.  
Basically the default index.php would call a function which cycles 
through the enabled plugins calling the whatever function the index.php 
wants to load at this time (onload, bypost, menu, etc).  The problem 
would be that some people might not want everything enabled when they 
enable a plugin.   An example might be the menu so modify the plugin 
functions to allow settings.  Things like turn off menu, or set default 
css (for wp-style-switcher), and so on from the plugin admin to reduce 
the amount of PHP code needs to be changed.  Or you setup another 
options page for the menu and you can turn on and off the plugin's menu 
there with check boxes or something.  It would have to be figured out 
whatever is most flexible.

I'm not sure if any of this is possible, but the idea of avoiding 
modification of the code is a good idea, at the very least graceful 
disabling.  I think a lot of the features in PHP5 will allow hacks to 
word better.   Overriding a built-in function with a plug-in would be 
very nice, but I'm not sure how one would go about doing so 
programmatically yet.

--
Garett