Announcement

Symphony's issue tracker has been moved to Github.

Issues are displayed here for reference only and cannot be created or edited.

Browse

Closed#453: Highlighting of extensions that need to be updated

If I remember correctly, earlier versions of Symphony used to highlight extensions that need to be updated by changing their colour in the extension overview to grey. This seems no longer be the case in the current development copy. I’m not sure if this is a new issue, but it’s not possible for the user to see if the updater needs to be run.

Furthermore I notice from time to time that people in the forum think they have to uninstall and later reinstall extensions to run the updater. Of course, uninstalling an extension causes a loss of all related data.

What about adding a new update entry in the With selected dropdown that explicitly runs the updater of an extension? Beside that some kind of highlighting should be reintroduced.

some kind of highlighting should be reintroduced

I agree. Not sure why this has disappeared.

What about adding a new update entry in the With selected dropdown that explicitly runs the updater of an extension

I think this is misleading, as “update” is understood as downloading a newer version of the extension.

Furthermore I notice from time to time that people in the forum think they have to uninstall and later reinstall extensions to run the updater. Of course, uninstalling an extension causes a loss of all related data.

Good point. The Enable option runs the updater right? I find it confusing that if I install a newer version of an extension (or if I manually increase the version number) then it becomes “Disabled” (or Enabled=No in the list at least). Even having the row highlighted with the “inactive” class isn’t really enough to tell me that I need to re-enable it.

Should there be something more specific in the labeling?

The problem is that you update an extension by “just” replacing the files in the extensions folder. The user is not required to disable an extension before updating it but the system needs to handle it somehow.

What about adding a notice on top of the backend pages when an extension was updated? This way, the user would notice the need to run the updater even if he is not visiting the extension overview and with a good copy we could make clear that it’s not about downloading newer versions.

One thing we should think about, too: The Extension Manager compares version numbers to check if an extension needs updating. It does not take into account if the extension bundles an updating function for the specific version. So even if an update just fixes a typo and doesn’t need to change the database or configuration it is flagged as “needs to be updated”.

One thing we should think about, too: The Extension Manager compares version numbers to check if an extension needs updating. It does not take into account if the extension bundles an updating function for the specific version. So even if an update just fixes a typo and doesn’t need to change the database or configuration it is flagged as “needs to be updated”.

Sorry but you’ve totally lost me here, can you rephrase?

Are you saying that if the update function does not have a check for the current file’s version, then Symphony should leave the extension as ‘enabled’ because there is no database changes?

This introduces a problem that sym_extensions version would never be updated. At the very least, the whole ‘enable to update’ logic is used to increment the version number of the extension in the database.

Good point. The Enable option runs the updater right? I find it confusing that if I install a newer version of an extension (or if I manually increase the version number) then it becomes “Disabled” (or Enabled=No in the list at least). Even having the row highlighted with the “inactive” class isn’t really enough to tell me that I need to re-enable it.

As Nils mentioned in this issue, perhaps extensions that need updating could have a yellow row colour? One for the UX team to decide upon.

I don’t think there’s a big problem with the fact that you have to re-enable extensions. But I think there’s a problem that people may not always know about it. I suggest two changes:

Firstly, add a page alert in the same vein as the recent “updater” page alert, so that if there are extensions that need enabling, we show an alert:

You have extensions that need re-enabling after updating them to a newer version

This should not display only if the extension is disabled. The installed and potential version numbers should be different for this to display. The reason being that some “default” extensions may be left disabled (e.g. Export Ensemble isn’t supported on all hosts so some users may leave it disabled, so this should not yield an alert).

Secondly, modify the extensions table slightly. I don’t think we need to invent an entirely new row style, but tweak what we have:

Extensions table

  • swapped the version and enabled columns
  • if the extension needs re-enabling, state this along with the new version number

+1

I like that idea. What about redirecting the user to the extension page if extensions (that have been enabled before) need updating?

I like that idea. What about redirecting the user to the extension page if extensions (that have been enabled before) need updating?

Nick Dhung for the win. Like the idea!

@Nils I don’t like the idea of auto redirection. Perhaps we could just display an Alert?

@nickdunn I like the idea! Are you going to implement it or would you like me to start?

I’m away for the weekend so I’m not going to have a chance until late next week at the earliest, so feel free. I think what it needs is a function that extends the listAll or list function, which returns an array of extensions with their current installed version, and also the version from theabout()` function from the driver. This array then needs to be compared both on the extensions page as above, but also on each backend page load to provide an alert.

This was actually very easy to implement using the current listAll function and the ExtensionManager’s fetchInstalledVersion function.

Check it out in this commit.

This was actually very easy to implement using the current listAll function and the ExtensionManager’s fetchInstalledVersion function.

Check it out in this commit.

This issue is closed.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details