eZ Community » Blogs » David Ennis » Update-proofing your extension

By

David Ennis

Update-proofing your extension

Sunday 13 May 2012 11:54:46 pm

  • Currently 5 out of 5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

Settings, directories, AcitveExtension, ActiveAccessExtension, etc.. Use them in the wrong order and go slightly mad.

Mix them up in the right quantities and in the right order, add a touch of patience and you have the recipe for easily updating an extension!

Not rocket science and probably straight-forward for many, but I thought I would share the different combinations we tried with settings in order to minimize the aggravation if updating an extension.

When developing our new product “eZ Multitasking One' (read more in Terry's blog), we thought we had everything organized in the best way as far as settings and directory structure were concerned. We set up everything in a way that meant that it would work almost out-of-the-box with minimal settings changes. It made for a quick install in our early tests.

However, some time later in the process, it was bought to our attention that updating the extension could prove to be more of a challenge than we wanted. This is because of the storage of critical settings within the extension itself. Simply replacing the extension directory would wipe out settings changed by the end user. We then went back and reviewed various options. The end result was a change in the way we set up the files and also how we enabled the extension.

The moral of the story: A 100% contained extension is not necessarily a 100% easily update-able extension if there are settings files in place. Same holds for templates, etc but I'll only mention settings.

So, th solution: keep a base set of settings in the extension and have the user override them in their site-access. Here are the things we tried and the final solution that worked well for us:

______________________________________________________________

Our first layout of settings will not be listed here – it is what you would expect: every setting listed under <ezpubroot>/extension/multitasking/settings and we would have the client just modify as needed.. But [read above], there goes the overwriting with an update..

So, the solution was to start with a base set of settings and only override the bits needed for custom experiences.. the base settings could be overwritten on an upgrade. In fact, this might even be the desired affect – overwrite some base settings as long as the site-accesses had the more customizable settings.

Why bother? Just put everything in <ezpubroot>/settings/override/multitasking.ini and be done with it?

Well, yeah, for a single install, but form the start, we wanted settings that would work with a shared-kernel setup(multiple front-end, admin and multitasking site-accesses). Therefore, a good layout for settings was important.

____________________________________________________________

Consider the following (with an admin siteaccess called multitasking_admin):

<ezpubroot>/extensions/multitasking/settings:

  • multitasking.ini ← initial version, not overridden from anywhere
  • site.ini.append.php ← further refinement of settings(single login)
  • menu.ini.append.php (menu used in admin2) ← default settings for menu
  • websitetoolbar.ini.append.php (ezwebin buttion) ← default settings for ezwt integration

<ezpubroot>/settings/siteaccess/multitasking_admin/settings:

  • multitasking.ini.append.php ← settings specific to this
  • site.ini.append.php ← further refinement of settings for single login

<ezpubroot>/settings/siteaccess/admin/settings (needed for tab in admin interface):

  • multitasking.ini.append.php ← further refinement of settings
  • menu.ini.append.php (menu used in admin2) ← default settings for menu
  • site.ini.append.php ← further refinement of settings for single login

<ezpubroot>/settings/siteaccess/ezwebin_site/settings (needed for custom button):

  • multitasking.ini.append.php ← further refinement of settings
  • websitetoolbar.ini.append.php (ezwebin buttion) ← further refinement
  • site.ini.append.php ← further refinement of settings (single login)

So, since we needed the extension in every site-access (for the various integration steps), we enable the extension via <ezpubroot>/settings/override/site.ini.append.php

And... we sat and watched it NOT work like we wanted.

The problem with the above is that by loading the extension in the settings/override/site.ini.append.php, then the module is loaded after the site-access and therefore, the settings in the extension overwrite the settings in the site-access.

Looking back, this makes perfect sense because in terms of eZPublish Settings, settings/override is always applied last. So extensions enabled in settings/override/site.ini.append.php are enable much to late for what we wanted..

As an example:

<ezpubroot>/extensions/multitasking/multitasking.ini loads AFTER <ezpubroot>/settings/siteaccess/multitasking_admin/settings/multitasking.ini.append.php

So. (in terms of load order and array merge of settings) our intended override file is really the base and the base settings becomes the override

________________________________________________________

The first attempt at a solution

One option we considered was to remove the 'customizable' settings from the base settings in <ezpubroot>/extensions/multitasking/ In this way, the load ordering above would not be an issue because the 'customizable' settings would no longer be in the base -and not overwrite he desired settings. However, this means that we had no true base settings file with every setting by default. Even though it was a 'workable' solution, it made me loose sleep and my hair fell out worrying about it not being the right solution.

The better, update-able and FINAL solution:

Keeping the same directory structure above, I said GOODBYEActiveExtension and HELLOActiveAccessExtension

Yup – the final solution was to simply change the enabling of the extension to an activeAccessExtension.. Yes, this means enabling it individually per site-access, but the load ordering means that the settings in the extension take precedence to the settings in the site-access.

The end result: Once you have your extension set up with properly overridden settings and designs in your base settings and design directories, then you can wipe out the extension directory with an update without and issue!

Not the only solution, but one that works in favor of easy updates.

Proudly Developed with from