Existing uddeIM configuration is reset to defaults during update/reinstall

[JKoelman]

Description

While testing uddeIM 5.6.3 on Joomla 6, I noticed that existing global uddeIM configuration values can be reset to the packaged defaults when the component is updated/reinstalled through Joomla.

This is potentially quite disruptive because an administrator can lose previously configured settings without explicitly resetting them.

This may not be Joomla 6 specific; that is simply the environment where I reproduced it.

Environment

• Joomla 6.1.2
• uddeIM 5.6.3
• PHP 8.x
• Playwright

Reproduction

I first noticed this with e-mail notifications.

Before reinstall/update:

allowemailnotify = 1

After reinstalling the component: allowemailnotify = 0

The recipient-specific notification preference was still present, so the problem appeared to be the global uddeIM configuration.

I then repeated the test with several independent configuration values.

Before update/reinstall:

allowemailnotify = 1
emailtrafficenabled = 1
enableattachment = 1
maxlength = 2350
perpage = 13
showonline = 0
allowurltext = 1

After update/reinstall they had returned to the packaged defaults:

allowemailnotify = 0
emailtrafficenabled = 0
enableattachment = 0
maxlength = 2500
perpage = 8
showonline = 1
allowurltext = 0

Actual result

Existing administrator configuration is replaced by the default values from the installed package.

Expected result

An uddeIM update/reinstall should preserve the administrator's existing configuration values.
New configuration options introduced by a newer version should of course still receive their new package defaults.

Cause

In com_uddeim_j50/script50.php, the current configuration is backed up during preflight('update'):

rename(
    JPATH_SITE . '/administrator/components/com_uddeim/config.class.php',
    JPATH_SITE . '/administrator/components/com_uddeim/config.class_bak.php'
);

The package then installs its config.class.php.

In postflight() the backup is reported, but its existing configuration values are not restored or merged into the newly installed configuration.

So the backup exists, but the active configuration continues using the package defaults.

Possible solution

After the new configuration file has been installed, values from config.class_bak.php could be merged into the new configuration.

A safe approach would be:

• restore only properties that exist in both the old and new configuration;
• keep package defaults for newly introduced properties;
• do not overwrite the new configuration schema/version value;
• do not restore temporary runtime properties;
• keep config.class_bak.php as a recovery copy.

This would preserve existing administrator settings while still allowing future uddeIM versions to introduce new configuration options safely.

[slabbi]

This "feature" has been added after I dropped support.
There is a function that stores the configuration in the database and it can be restored from there whenever necessary.
So best would be to remove this "file backup" I guess.

[joomod]

@JKoelman
thank you for your fine work correcting so many (API) errors.
I must confess, that I have had less attention on the functions in the api file,
so your corrections are a very perfect update to the actual version.

about what I have done to the config backup:

As before there was no backup of the config if you have forgotten to do a db save,
I have decided to do this additionally by a simply file renaming,
so if you have missed to do a db backup you have your old config file

• to look at
• or simply back rename it and use it. (if it is the same config version)

I thought about to do this during post-install, but decided to keep it as manual option
and just throw an information line.

May be a forced db backup during preinstall would be a better solution

[JKoelman]

Thanks for the explanation. That clarifies why the additional file backup was introduced.

I agree that keeping a recovery copy is useful, especially if the administrator did not create a database backup before updating. During my Joomla 6 testing I have now looked at this installer path in more detail.

For reference, I tested this on Joomla 6.1.2 with PHP 8.3 using Playwright/Chromium against a disposable Joomla clone, including deliberately failed/interrupted installer runs and exact post-test cleanup checks.

One thing I found is that rename() during preflight('update') has an unfortunate failure case. If the update fails after preflight, Joomla can roll back the newly copied package files. Because the original configuration was renamed before that, this can leave the active config.class.php missing, while postflight() is never reached.

For that reason I changed the backup step in my Joomla 6 branch from rename() to copy(). This keeps the active configuration in place during the update while still creating config.class_bak.php as a recovery copy.

For a successful update I currently use the following approach in postflight():

• keep the newly installed config.class.php as the base;
• restore only configuration properties that exist in both the old and new configuration;
• keep package defaults for newly introduced properties;
• do not restore the configuration schema/version value;
• do not restore temporary runtime fields;
• keep config.class_bak.php as a recovery copy.

I have tested this separately for same-version reinstall, normal update, package-only new defaults, temporary runtime fields, configuration version handling, refused downgrade and a deliberately failed/interrupted update.

So I think a forced database backup during preinstall could still be useful as an additional recovery mechanism, but I would not use it as the primary way to preserve settings during a normal update. The installer itself can preserve the existing compatible settings automatically, while the database/file backup remains the fallback.

//
I am doing this Joomla 6 work because I plan to use uddeIM in practice alongside a opensource component. At the moment i do have a repo with UddeIM and am optimizing it fully. Actually at the moment it does run fine within Joomla 6. did find some additional bugs and will post them this or next week. am considering to put some time into it.