Can only use this once!

[zanematthew]

trafficstars

Right out the box you can't use this in more than one plugin/theme on the same site. If you do you get errors regarding: Notice: Constant WPALCHEMY_MODE_ARRAY already defined in /opt/local/apache2/htdocs/gettasktracker/html/wp-content/plugins/task-tracker/library/php/wpalchemy/wp-content/wpalchemy/MetaBox.php on line 20

Example: plugin A uses wpalchemy plugin B uses wpalchemy Both are active on the same site and you get a plethora of errors.

Recommended fix:

1. Change your instructions: http://www.farinspace.com/wpalchemy-metabox/#usage recommending that the developer place this in the plugins dir, and include it once per site.
2. Wrap each, class, function and defined constant in a conditional.

Let me know what you think, I don't mind doing option 2 myself, and then submitting a pull request, but would like to know your intended use first.

[farinspace]

Definitely a big issue as people are/want to use this in their plugins ... there are the constant errors and the same class name issue.

The installation procedure will definitely change ... there are a few major items that will change in the next release, this definitely being one of the issues.

I am thinking of delegating class creation to a wpalchemy() global function, which will be used for creating an instance and also recalling instances (this would avoid the global key word some have to use) and would provide internal management of the code includes and such.

Additionally I want to look into best practice for having a plugin auto install a "must-use" plugin ... which may be an option for managing the library system wide.

Then again it might be better to have each plugin rely on its own version, so nothing ever breaks ... Naming conflicts will have to be taken into consideration ...

Anyway its a problem yes ... I've simply have to spend some time on it and get'er done.

The immediate fix will probably be conditionals as you suggest.

[zanematthew]

I'm reluctant on it being a MU plugin, as the idea of a plugin, is that you can bundle it up and send it on its way. Ideally keeping it in your plugin would be best. I should of time this week, to play with it and might make a pull request.

[armandmorin]

Couldn't a simple option be that the developer sets a variable for a name of the class at the top of the MetaBox.php file. Then all instances of WPAlchemy would be changed to their custom name. This would allow anyone using it to set it right from the start. Or you could insert a PREFIX for the class name which would accomplish the same thing. I think this might be easier.

[farinspace]

searching for some good ideas, best practices: http://stackoverflow.com/questions/8056224/what-are-some-practical-php-namespacing-solutions

[helgatheviking]

can it not be wrapped with

if(!class_exists('WPAlchemy_Metabox')):
class WPAlchemy_MetaBox
{
}
endif;

i kind of like the idea of WPA becoming a plugin (sort of like options framework) would sure make it easier to stay updated across all the places i use it.

sidenote: i just solved a fatal error caused by having WPA in a plugin AND in a theme, but including it conditionally

// Require WP_Alchemy Meta Box Class
if(!class_exists('WPAlchemy_Metabox')) include_once( dirname ( __FILE__ ). '/WPAlchemy/MetaBox.php');