By: Anonymous: mst3kroqs ()  Jun 07 2008 12:20 pm (Read 1862 times)  

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?

By: Anonymous: jmucchiello ()  Jun 07 2008 22:24 pm  

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:

PHP Formatted Code

function tags_option($index, $unset = null)
{
    static $_MYCONF = Array();

    if (count($_MYCONF) == 0) {
        $res = DB_query("SELECT * FROM {$_TABLES['plugins']} WHERE pi_name = 'tags' and pi_author = 'Joe Mucchiello'");
        $A = DB_fetchArray($res);

        if (version_compare(VERSION, '1.5', '<=')) {
             // creates a $_MYCONF variable which due to scope becomes the static above instead of a global.
             include $_CONF['path'] . 'plugins/' . $A['pi_filesystem_name'] . '/config.php';
        } else {
            $c = config::get_instance();
            $_MYCONF = $c->get_config('tags');
        }
   }
   if (array_key_exists($index, $_MYCONF)) {
      return $_MYCONF[$index];
   }
   return $unset;
}
 


But is that really better?

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

By: Anonymous: mst3kroqs ()  Jun 08 2008 00:43 am  

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 Smile



Hi Joe -

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

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

By: Anonymous: jmucchiello ()  Jun 08 2008 09:43 am  

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

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

By: Anonymous: mst3kroqs ()  Jun 08 2008 12:23 pm  

Quote by: jmucchiello

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

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.

By: Anonymous: jmucchiello ()  Jun 08 2008 13:41 pm  

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.

PHP Formatted Code

<?php
// functions.inc

$db_ver = DB_getItem($_TABLES['plugins'], 'pi_ver', "pi_name = 'myplugin'");
if ($db_ver == 'current_version_number') {
    include $_CONF['path'] . 'plugins/myplugin/real_functions.php';
} else {
// handle case where filesystem contains updated plugin but the upgrade has not happened yet.
   $_MYPLG_CONF['disabled'] = true;

// must have the upgrade function defined.
    function plugin_upgrade_myplugin()
    {}

// if there's a phpblock for the plugin, should make sure it is defined.
    function phpblock_somethingmyplugindoes()
    { return ''; }

// etc.
}
?>

<?php
// public_html/myplugin/index.php

include $_CONF['path'] . 'plugins/myplugin/functions.inc';

if ($_MYPLG_CONF['disabled'])) {
    if (SEC_inGroup('Root')) {
       // go get someone to upgrade me!!!!
       COM_refresh($_CONF['site_admin_url'] . '/plugins.php?mode=edit&pi_name=myplugin');
    } else {
       COM_refresh($_CONF['site_url']);
    }
}
 

6 posts :: Page 1 of 1
All times are CDT. The time is now 10:30 pm.
Normal Topic Normal Topic
Locked Topic Locked Topic
Sticky Topic Sticky Topic
New Post New Post
Sticky Topic w/ New Post Sticky Topic w/ New Post
Locked Topic w/ New Post Locked Topic w/ New Post