From: Tomas K. <to...@us...> - 2005-11-24 09:38:21
|
> Devel list, note there are three issues in this thread now: > > > 1) design of inclusions in plugin.txt (and needed backport) > 2) placement of inclusion of display_messages.php > 3) possible inclusion of compatibility plugin in core > > >>>> plain_error_message() function is stored in >>>> functions/display_messages.php. This file is not loaded by default, >>>> if preferences are stored in DB or newmail plugin is not enabled. >>> >>> Nice catch. A couple of things about this for us to consider: >>> >>> >>> >>> - I had taken a quick look at plugin.txt to see if >>> display_messages.php was listed in the inclusion hierarchy, and it was >>> not. Seems like the hierarchy is incomplete, needing something like >>> this: >>> >>> >>> 7. include/load_prefs.php >>> 7.1. include/validate.php >>> 7.2. functions/prefs.php >>> + 7.2.1 One of the following, depending on prefs backend >>> setting and/or prefs_backend hook, which is executed here: + >>> 7.2.1.a <custom prefs backend> >>> + 7.2.1.b functions/db_prefs.php >>> + 7.2.1.c functions/file_prefs.php >>> + 7.2.1.c.1 functions/display_messages.php >>> >> >> >> 9. functions/prefs.php >> > > OK, right, I missed that. I missed it because I was mistakenly thinking > that the order of listing corresponded to the actual include > order/hierarchy. Would it be too confusing to rebuild this list to > actually mirror how the includes are built? It looks like you decided to > stop listing the includes under part seven at that point because the same > inclusion is made directly in validate.php. Not a bad decision, but it > still tripped me up. > > * Note that I was looking at STABLE plugin.txt, which does NOT include > 9.2.1 and 9.2.2. I think that needs to be backported. Will recheck HEAD validate.php table on Saturday and backport it to SM-1_4-STABLE on Sunday. > I also still wonder about the placement of the display_messages.php > inclusion in the core.... Plugins still have to cover older setups that don't include display_messages.php. >> Is location of compatibility plugin include call stabilized? >> > > I sure hope so, but it is still a bit wet behind the ears. > > >> Plugins should not require patching SquirrelMail source. > > Absolutely. However, the nature of what this one needs to do is a bit > unique and can't be achieved any other way that I can see... and I've > looked a lot, but suggestions are welcome. > >> We can add code that >> loads compatibily functions, if plugins/compatibility/functions.php >> exists. > > If we do, we should probably just have the discussion about putting that > plugin into the core package plugins. In fact, Erin and I had a long > thread on the devel list probably over a year ago where we decided to do > exactly that once the plugin was designed appropriately (I think it now is > - more or less). The good and bad thing about that is that it still > has to be made available in a way that people running older SM versions > can get the latest tarball easily, and it needs to be kept up to date by > developers who change key code that is used in the plugin (such as many of > the functions in global.php). ... > I can make that change w/out too much trouble. The question here is if > it is still desirable to pull the plugin into core, or if Tomas' idea is > preferable. My opinion. Compatibility plugin should not be distributed with SquirrelMail packages. If plugin is part of SquirrelMail distribution, included version won't cover plugin updates added after SquirrelMail package is released. In order to get current plugin version, admins will have to replace files that are part of standard SquirrelMail package. Same "don't mod prepackaged scripts" problem. Plugin can be maintained in SquirrelMail cvs, but it must be distributed in separate package. In order to avoid modifications in SquirrelMail scripts, we make sure that include call place is fixed, plugin's API functions are stabilized and include it with if(file_exists(SM_PATH.'plugins/compatibility/functions.php')) include_once(SM_PATH.'plugins/compatibility/functions.php')); -- Tomas |