Update notification
A suggestion for 2.2, submitted by Nils on 08 January 2011
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#479: Update notification
It could definitely be done through Page Alerts, whether that’s the best place for or if it should be integrated into the left footer area where the current Version is another question entirely
I think a page alert is the best place. We use the alerts for notifying when an action needs to be taken, such as when the manifest folder isn’t writable. Having an un-used update.php in the root is a security risk (insofar as anyone can run it) so it should be Symphony’s duty to make this as obvious as possible.
Just to point it out: beside the security risk I think it’s important to make sure the updater has run. Maybe we can find a solution that handles extension updates as well.
What about adding a page alert which includes an “update now” link that executes the updater for the core and the extensions. Extensions that need updating could be highlighted with a yellow background colour in the extension overview (like the error colour in page alerts).
I’ve half implemented this. Thoughts wanted before committing. It’s currently an Alert::NOTICE
, because Alert::ERROR
really isn’t accurate.
Basically the Administration class checks to see if the update.php
exists. If it does, it displays an Alert that will direct users to the update.php
page. This prevents us having to duplicate update logic and takes away the magic of ‘Update Now’.
Looks great.
Commited. Thanks Nils
I’m re-opening this. I don’t think the copy is quite right:
There is an update available…
To me this implies that the system somehow knows that a new version has been released. I think it should make reference to two things:
- that if you’ve just downloaded a new version, you need to run the updater
- if you’ve run the updater but not delete the script, you need to delete it
The update.php stores the new version number as a constant. Can we parse the file for this constant, compare with the version in config.php
and render a different message depending on the outcome?
Run the updater to update Symphony to {$version}. [View update]
The updater script should be removed now you have updated. [Remove script]
Or something.
Yeah, I agree with both points. #1 should definitely happen now. #2 may be trickier but is desirable because Symphony’s not always going to have permission to delete the update.php file and so shouldn’t generate false positives because of that.
Unfortunately I don’t think it’s going to be possible at the moment to ‘parse the file for this constant’. The only way to do that is by including it, and in doing so, it tries to run the logic of the update.php
file.
We’re perhaps have better luck parsing the README file. I’ll have a look tonight and try to commit a solution that does both #1 and #2 :)
Check this commit.
This commit seems to do the job. It will attempt to parse the README file.
If the README version is greater than the installed version:
Run the updater to update Symphony to $version. [View Update]
If the README version is less than, or the same as the installed version, and the update script exists:
Your Symphony installation is up to date, but an updater script was still detected. For security reasons, it should be removed. [Remove Update Script]
If the README file is not readable, or doesn’t exist:
An updater script has been found in your installation. [View Update]
Thoughts?
The logic seems good, but I’m not keen on parsing the README file. That feels really skanky! I usually delete the README before deploying a site.
Could the update.php be refactored every so slightly so that:
kVERSION
(or a renamed constant) sits globally- the rest of the file sits within a function so that it doesn’t execute when the file is included in another script?
I know what you mean, it doesn’t feel foolproof. Should you delete the README though, the alert will fallback to the most generic message, which allows you to look at the update file yourself. My thinking is that if you are deleting the README and pushing to production, then the update.php file shouldn’t exist anyway, so this Alert will never been seen ;)
I don’t really know where we could move the kVersion
to be honest. index.php
? Could this clash if your install has a modified index.php
? I suppose the beauty at the moment is that the update logic is all self contained.
Your second point might be possible, I haven’t any idea how though. I wonder whether that could be looked at in more detail with the installer changes in 2.2.1?
Are we overthinking this for now? This Alert isn’t something that’s going to be displayed everyday after all. I imagine in most sites this will be used more as a reminder to delete update.php
instead of an ‘update now’ reminder, given that a developer would have to manually download a new Symphony version or pull from the Symphony repo to actually trigger this alert.
In which case as a temporary solution this should be fine. It ain’t pretty, but it’s an edge case and it gets the job done.
There are desires to change the installer post 2.2, so we could extend scope to include the updater too, at which point this could be revisited.
This issue is closed.
Would it be possible that Symphony notifies the user in the backend, when the updater has not been run, e. g. when
update.php
still exists and the version numbers in that file and the configuration don’t match?