It occurred to me while working on my plugin today that GL really needs a better plugin registration system for things which would lead to conflicts later on.

For instance, when installing a plugin, aside from the basic conflicts that would arise from choosing the same two-letter prefix for your plugin, the basic name of the plugin, as well as Menu entries, table names, config vars which may be implemented as globals and autotags that it supports/implements could all represent conflicts with other plugins, or ultimately, the core, I guess.

Ultimately, the plugin manager should be able to handle all of this, in terms of at least recognizing conflicts and then refusing to install the plugin, although this is certainly the kludgiest and least-helpful way to deal with this.

I'm thinking the real solution would require that the plugin installation code look for a capability in the plugin itself to resolve these conflicts. This would of course require the plugin to allow the override and local configuration storage of just about everything except the two-letter prefix, and even this could actually be implemented as a constant which could be easily edited by the human trying to install the thing.

This (and a few other things) could be implemented as adding a serialized 'capabilities' or 'definitions' array behind a new plugin API call which the plugin installer could look for, and if it doesn't find, consider the fact that this is an older/dumber plugin that is a go/no-go scenario for plugin var/tag/name conflict resolution.

Does any of this make sense?

I've wanted a better plugin registration system for a long time. But I don't think there's really an issue with naming conflicts. Most plugins use the plugin name as a prefix for tables: mg_album instead of just album. A conflict there would be pretty weird since the prefix and the table name would both have to conflict. As for "two letter prefixes", I don't use them. I use the whole plugin name or a long name: $_TAGS_CONF, $_LABS_CONF. Using just 2 letters is a bit dangerous. And how would you make that prefix configurable? Double $ vars? $$TAGS_CONF[]? You could make a function to take the config vars out the global name space:

But is that really better?

Where have you seen these conflicts? I think a new sample plugin would be easier to maintain

Quote by: jmucchiello

I've wanted a better plugin registration system for a long time. But I don't think there's really an issue with naming conflicts.

---

Where have you seen these conflicts? I think a new sample plugin would be easier to maintain

Hi Joe -

Haven't really seen them, but understand what you're saying here.

So - where is this mysterious tags plugin ... ;^)

If I told, it wouldn't be a mystery.

It is waiting for the day calendar is off my plate.

Quote by: jmucchiello

If I told, it wouldn't be a mystery.

It is waiting for the day calendar is off my plate.

Understood - in the meantime, if there is an opportunity to learn from the developmental code in terms of utilizing some of the new plugin management stuff, pls send, the plugin will get no further than my /dev tree, and all proper attribution will be given, etc.

Most of the stuff I want requires best practices. When your code version does not match the database version, plugins should disable themselves (assuming the upgrade contain significant changes). It's stuff like this that drive me buggy.