BUG: console menu items for disabled plugins still appear

[Howie]

Subject says it all - install plugin, enable, disable, and the console menu items for it are still there, but other things break because the hooks for setting up e.g. draw_navigation_text is no longer called.

True for at least superlinks, reportit and quicktree.

[TheWitness]

Yea, that makes sense. I'll send this one to Jimmy.

Larry

[gandalf]

Subject says it all - install plugin, enable, disable, and the console menu items for it are still there, but other things break because the hooks for setting up e.g. draw_navigation_text is no longer called.

True for at least superlinks, reportit and quicktree.

Howie, even if I do not the the current inner workings, please be prepared that the "old" style plugins may not work on 088. You will already have noticed, that we renamed the host table to "device" and more. But there is currently no writeup of the changes that are important for plugin developers. In fact, personally I did not install a single plugin yet on 088.
R.

[Howie]

Howie, even if I do not the the current inner workings, please be prepared that the "old" style plugins may not work on 088. You will already have noticed, that we renamed the host table to "device" and more. But there is currently no writeup of the changes that are important for plugin developers. In fact, personally I did not install a single plugin yet on 088.
R.

When there is some documentation, I will look at updating my plugins.

(I still don't have a sensible path from PA 1.x to PA 2.x for some things though, or clear docs on how things like the database table functions and install/upgrade work in 2.x, so I think it might be a while before I have to worry)

[TheWitness]

One of the biggest is precedence/plugin load ordering. I struggle with this one as well. Just today in fact. I had a 1.x plugin that was not loaded but needed to be for my hook to properly mod things. It would be nice to say something like "don't load until after this plugin is loaded first" API call.

I'll copy Jimmy on this one.

Larry

[cigamit]

Subject says it all - install plugin, enable, disable, and the console menu items for it are still there, but other things break because the hooks for setting up e.g. draw_navigation_text is no longer called.

True for at least superlinks, reportit and quicktree.

I see what the issues are. There are several hooks which are always enabled, even when the plugin is disabled. They are 'config_settings', 'config_arrays', 'config_form'. The initial reasoning behind this was, it allowed you to configure the settings for a plugin, before you Enabled it and let it go live. Since the hook we are using to load the console menu is one of these hooks, it gets shown. I can either remove the functionality, or find another place for people to load the menu items they want. Easy enough.

The second thing I see if that since all the hooks fire before we actually do any work (considering we have to load the core files to do any work) if we do an uninstall, the items are not removed until you do another page refresh. I could do a quick hack to work around this, but I might think of a more elegant solution.

[cigamit]

One of the biggest is precedence/plugin load ordering. I struggle with this one as well. Just today in fact. I had a 1.x plugin that was not loaded but needed to be for my hook to properly mod things. It would be nice to say something like "don't load until after this plugin is loaded first" API call.

I'll copy Jimmy on this one.

Larry

I was thinking about load order last night, and its a simple enough thing to accomplish, just add an "loadorder" column to the table, and update the functions to increment these per hook, and then just an interface to manage it all. I will put it on my list.

[cigamit]

When there is some documentation, I will look at updating my plugins.

(I still don't have a sensible path from PA 1.x to PA 2.x for some things though, or clear docs on how things like the database table functions and install/upgrade work in 2.x, so I think it might be a while before I have to worry)

We are all programmers here, so I don't see where the real technical issues are. There was no formal docs when we wrote the plugins for 1.X, but we all managed to spit out some nice plugins without it, just by a quick glance over the code (or using other plugins as examples).

Yes, I do have some *bleh* documentation in my plans, but honestly with both what will need to change for current 0.8.8 and what major changes will occur between now and when 0.8.8 is released, I prefer to wait just a smidgen longer until a few things are finalized before I start down that road and have to redo most of it. An upgrade path will be available for developers well before 0.8.8 hits.

[Howie]

We are all programmers here, so I don't see where the real technical issues are. There was no formal docs when we wrote the plugins for 1.X, but we all managed to spit out some nice plugins without it, just by a quick glance over the code (or using other plugins as examples).

I figure there are probably 8 or so developers of non-trivial plugins, and at least 3 or 4 of those are Cacti devs, but I know from previous discussion and reading comments in the code that they don't seem to be really sure how things should work at times.

The whole point of an API is to act a 'contract' of what the Application will do when the Programmer calls those Interfaces.

As a few examples:
The api_plugin_is_enabled() function doesn't check if a plugin is enabled, only if a new-style plug is in a table.

There's a hook for upgrade_check that is implemented by a bunch of plugins but doesn't actually get called.

I don't know what the right way is to smoothly transition from the 'old' way to the 'new' way without losing existing permissions or user data. How do you tell if the new-style plugin you are installing is actually a replacement for an old-style plugin and migrate permissions?

Anyway - the point was that it's not just to document function calls, but the *intent* of how it's supposed to work. Then you get less "guess what might be right until it doesn't appear to go wrong" code (I still have no idea what all those other columns in draw_navigation_text do - I just copied something else and continue to copy & paste them), less plugins that break other plugins, and so on.

I prefer to wait just a smidgen longer until a few things are finalized before I start down that road and have to redo most of it. An upgrade path will be available for developers well before 0.8.8 hits.

I understand that - and that's why I'm saying I'll wait a bit longer too. I do this for fun, same as the rest of you, and I'll find something more fun to do until it settles down. Maybe it's time to learn to play the guitar I've had for 10 years Or more likely, just work on unit testing or other integration - sorry, guitar.

[TheWitness]

Maybe it's time to learn to play the guitar I've had for 10 years Or more likely, just work on unit testing or other integration - sorry, guitar.

Lol. Sounds so familiar. My bike is still at the shop waiting for me to get in shape again.

TheWitness

[cigamit]

As a few examples:
The api_plugin_is_enabled() function doesn't check if a plugin is enabled, only if a new-style plug is in a table.

That code seems pretty straight forward. It is a v2 function checking if a v2 plugin is enabled. It checks the table where it stores all installed plugin information, and if its there and the status == 1, then its enabled.

Code: Select all

function api_plugin_is_enabled ($plugin) {
	$status = db_fetch_cell("SELECT status FROM plugin_config WHERE directory = '$plugin'", false);
	if ($status == '1')
		return true;
	return false;
}

I tried to keep v2 plugins from checking stuff about v1 plugins on purpose, but maybe I could have made it check both v1 and v2 to smooth the transition.

There's a hook for upgrade_check that is implemented by a bunch of plugins but doesn't actually get called.

Yes, that was one of those functions that haven't been implemented yet, but will be eventually. The problem is finding where to implement it, and how. The original thought was at the beginning of the poller we do a quick check of the versions of the installed plugins, versus the version we have stored in the table. If they are different than its an upgrade, so do the upgrade check, if it fails (returns false) then we disable the plugin so that the admin can look into it.

I don't know what the right way is to smoothly transition from the 'old' way to the 'new' way without losing existing permissions or user data. How do you tell if the new-style plugin you are installing is actually a replacement for an old-style plugin and migrate permissions?

To begin with, the only real thing that has to be done for a transition is using the hook and realm registration API. All the table stuff, etc.. is more of a convenience for the developer. 1 to make creating the tables easy, 2 to help clean up everything when its done. I recently have decided to make it even easier, and worked on a function that you just feed your current table structure to, and it checks the existing one and makes any necessary changes (adding columns, updating columns, or creating it if it doesn't exist, creating the indexes, etc...). It will make life a bit easier than having to do the upgrade scripts the way we currently do them (you will still have to populate the data in these columns, but I am thinking of possibly a hook based mechanism to make it cleaner than checking current plugin version vs old plugin version.

Anyway - the point was that it's not just to document function calls, but the *intent* of how it's supposed to work.

Yes, I understand your point, the documentation is way overdo, and I will get to work on it. The whip has been cracked.

(I still have no idea what all those other columns in draw_navigation_text do

Honestly, neither do I (or a few of them at least). I was thinking we were getting rid of it in 0.8.8, but i see its still there.