From the user point of view, I don't want to know. The user I am likes the automatic (or semi-automatic, it's user defined!) [url=http://www.windowsupdate.com]Windows Update[/url] upgrade when security holes are fixed. The user I am also likes the way this system makes possible to install new additional software from the [url=http://www.windowsupdate.com]Windows Update[/url] site.

Now, in the blogging world, [url=http://www.dotclear.net]Dotclear[/url] has a very intuitive plug-in installation interface: you copy and paste the URL of a new plug-in to install and... a few seconds after, it's installed and ready to work!

In fact, it would be very interesting each plug-in would have its own folder with all the files it wants to have. Then, a _install.plugin.php file would contain all the needed code to perform an installation of that plug-in and _register.plugin.php would have all the plug-in needs to register itself. That would be interesting when complex plug-ins are developed.

But all this does not answer to your questions...

First, after installing the basic plug-in files where [url=http://b2evolution.net]b2evolution[/url] expects to find them (and those files should include all the plug-in-specific dependencies), all the additional files should be put in a separate, plug-in-specific folder. It should be straightforward to remove a plugin even if the user doesn't remeber the list of files to be removed.

Second, as [url=http://forums.b2evolution.net/viewtopic.php?p=26170#26170]EdB[/url] noticed, there is a Settings database table you can use to save some settings. I don't know about any OnInstall event or so. But I haven't installed the development version of Phoenix yet.

To save configuration and/or data, you can either use a database table -- that's slower than loading a .PHP configuration file --, either use a .PHP configuration file -- there may be issues with read/write access rights on some servers. I believe it's better to avoid to modify the core [url=http://b2evolution.net]b2evolution[/url] tables. I believe it's better to create new ones, so the plug-in can be uninstalled easily and the blogging system might be upgraded without any trouble.

I'll follow up on kwa's view. I would only modify the settings table if you were also going to offer a way to alter those settings. I didn't say that in a different thread, but that's where I'm at on my settings table mod - you tweak the value on your settings tab. If the plugin is going to modify it then that's cool - the settings table makes sense. I agree that if these settings are something a user will pick once and be done then just have them edit the file. It's going away from a "pure" plugin, but it'll work. Besides with extra files in a folder you've already gone a bit away. No worries!

As to extra files, I would put any additional files in a folder in the plugins folder. That way it's as contained as possible, meaning both the plugin and support folder are side-by-side. The creative commons plugin does that, and having them together helped me do the migration.

I also have no clue about an OnInstall event. I got busy in other worlds and haven't played with CVS since back in the v12 days. Even when I played I wasn't concerned with hooks so much as basic functionality and a simple hack here or there, so I dunno! What I would do right now is borrow a step from the old/current world: tell users they have to do some icky manual crap. Either edit a file or create/alter a table. Those who use and hack b2evolution have had to accept that this is the way it's done, so you won't limit your current participation by too much. As time goes on you can upgrade your plugin to embrace new and different ways to skin the proverbial cat.