From dirk at haun-online.de Wed Jan 7 06:53:45 2009 From: dirk at haun-online.de (Dirk Haun) Date: Wed, 07 Jan 2009 12:53:45 +0100 Subject: [geeklog-modules] RFC: Plugin auto install Message-ID: <20090107125345.gxrl8ocxes040k8w@webmail.df.eu> Part of Matt's GSoC project was to make the plugin installation easier. In case you haven't tried out the current version from our Mercurial repository: You can now install plugins by simply uploading their tarball. Also, the bundled plugins have now been properly separated from Geeklog, i.e. they are no longer contained in the mysql_tableanddata.php file. To remove, say, the Polls plugin, you can simply remove its 3 directories from the Geeklog tarball - the rest will still install just fine. One thing we didn't get resolved during the summer was how to handle automatic installation of plugins now. The standard plugin install scripts are made for user interaction and also check for permissions, which simply may not exist during an initial install. So we need a new approach. The idea is that plugins can supply a new file, autoinstall.php. From this file, Geeklog will get the plugin's data (permissions, groups, etc.). The plugin can also provide functions that check the prerequisites and do any post-install operations necessary. Most of the install process, though, will be done by Geeklog now, based on the information it gets from autoinstall.php. If you ever had a look at the plugin install scripts for the bundled plugins in 1.5.x, you'll see that they are pretty generic already and only have a plugin-specific section at their start. All that generic code has now been rolled into Geeklog and the autoinstall.php is simply the new way of that plugin-specific section. There are 4 functions that can be present in an autoinstall.php, only one of which is mandatory: - plugin_autoinstall_foo Provides the information about the plugin: Name, permissions, groups, ... - plugin_load_configuration_foo For plugins using Geeklog's Configuration GUI - plugin_postinstall_foo For any post-install operations that the plugin may need to perform - plugin_compatible_with_this_version_foo To check the prerequisites Only the plugin_autoinstall_ function is required. It should only return information, not perform any operations, as it will be called more than once (and being called doesn't mean that the plugin will be installed). Plugins using an old-style install script will continue to work, of course. They will simply require one extra step (calling the install script) to be installed. All plugin authors: Please have a look at the autoinstall.php files of the bundled plugins - they are pretty straightforward and easy to understand - and let us know if you see any problems with this approach. bye, Dirk P.S. You can get the latest development version by checking it out through Mercurial or download the Nightly Tarball, as explained here: http://www.geeklog.net/staticpages/index.php/CVS From dirk at haun-online.de Tue Jan 13 06:37:59 2009 From: dirk at haun-online.de (Dirk Haun) Date: Tue, 13 Jan 2009 12:37:59 +0100 Subject: [geeklog-modules] RFC: Plugin migration Message-ID: <20090113123759.jl3ty2156m84s0c4@webmail.df.eu> I'm still interested in any feedback from plugin authors regarding the plugin auto install in Geeklog 1.6 [1] In the meantime, here's a somewhat related topic: Migration of plugins. In 1.6, we now have that nifty Migration option in the install script (the other part of Matt's GSoC project). That's what you use when your site moves to another server. It also handles path changes, URL changes, provides warnings about missing files and plugins, etc. When your site's URL changed during the migration, it will also update most of the content now. What's missing are the plugins. So the obvious idea would be to have a PLG_migrate call that informs plugins about the migration and gives them a chance to update paths and URLs where needed. However, the migration can also perform database updates. Which raises the question: What comes first? PLG_upgrade or PLG_migrate? Alternatively, we could call PLG_upgrade for the migration case (with a flag indicating that a migration is underway) and let the plugins figure out the proper order themselves. The downside of this approach is that it would call PLG_upgrade in cases where the plugin doesn't need to be upgraded, which could confuse some plugins. To summarize the options: 1) PLG_upgrade first, then PLG_migrate 2) PLG_migrate first, then PLG_upgrade 3) PLG_upgrade($mode = 'migration') Opinions? bye, Dirk [1] http://eight.pairlist.net/pipermail/geeklog-devel/2009-January/003953.html From dirk at haun-online.de Sat Jan 17 11:56:55 2009 From: dirk at haun-online.de (Dirk Haun) Date: Sat, 17 Jan 2009 17:56:55 +0100 Subject: [geeklog-modules] RFC: Simplifying PLG_itemSaved Message-ID: <20090117165655.1288452353@smtp.haun-online.de> This is the third (and last, I promise) Request For Comments on plugin API changes for Geeklog 1.6. I'm still interested in any feedback on my previous two, regarding Plugin auto install[1] and Plugin migration[2]. Almost 4 years ago[3], Blaine and myself came up with the idea for PLG_itemSaved. The hope was to provide an API into which plugins could hook and that would inform them whenever something was saved in Geeklog, so that they could act on it. Part of the concept was an abort and rollback mechanism, where plugins could report an error and signal to Geeklog (and other plugins) that there was a problem and that the save operation should be aborted. In which case the user would be taken back to the editor where s/he was informed of the problem and could try again. Fast-forward four years and that mechanism has only been implemented for stories. And, looking at the code (in 1.4 and 1.5), not even been implemented correctly. And it hasn't caught on either (i.e. isn't being used by any plugins, to the best of my knowledge). Neither has it been implemented anywhere else. Why is that? I think it's because the API is too complicated. Namely, the abort and rollback isn't really needed. My suggestion would be: Get rid of the abort. When something is saved (a story, a static page, etc.), it calls PLG_itemSaved. Plugins interested in that information can still hook into it, but they can no longer abort the process (why should a plugin be able to tell Geeklog - and the user - that a story should not be saved anyway?). Over the years, we had a lot of scenarios where something like PLG_itemSaved (implemented everywhere) would have come in handy. I think it's time we finally do that. And if the complexity of the API is holding us back here, then we need to fix that. I realize there's also PLG_itemPreSave, which is supposed to be called before the save, and which _can_ cause an abort. We should keep that and implement it everywhere, too, so that every call to PLG_itemSaved is preceded by a call to PLG_itemPreSave. That should handle situations where plugins still want to abort, for whatever reason. Only then it would happen before the object ended up in the database, which gets rid of the rollback and makes things much easier. Comments? bye, Dirk [1] [2] [3] -- http://www.geeklog.net/ http://geeklog.info/