Update Notifications 2.0

A little while back, we added a system to Ghost which regularly asks Ghost.org if there’s a new version of Ghost available.

Ghost.org replies with a little bit of JSON like this:

{
  "version": "0.5.0",
  "next_check": 1427366737
}

This tells Ghost what the current version is, and when it is allowed to ask again.

Inside of Ghost, this is wired up to our notification system, and if the version number goes above the current version of Ghost, a special notification is shown at the top of Ghost, on all pages, which doesn’t go away until the blog is upgraded.

The major problem with this, is that it’s incredibly invasive and annoying, so we’re currently only using it for major version updates, rather than minors, so as not to infuriate our users when we do fast releases. Clearly, that makes the system significantly less useful.

The second problem is that the message in the notifcation is hardcoded inside of Ghost, and that makes it not particularly useful. There’s no way to say ‘hey, this interesting thing happened and that’s why you should update’. There’s also no way to send a notification outside of a version change, which is quite limiting.

To make this whole system SIGNIFICANTLY more useful both to us and to our users, I want to make the following changes:

Move the “update available” notification to the about page.

As this is where the version information is currently shown, lets show the update information here. It means that users have to check the page to find out, but it does at least mean the information is always to hand in an easy to find place.

Add support for custom messages

The updates endpoint on Ghost.org is going to be updated to send back a little bit more JSON, that will look like this by default:

{
  "version": "0.5.0",
  "next_check": 1427366737,
  "messages": []
}

When we want to display a message to our users, it will look like this

{
  "version": "0.5.0",
  "next_check": 1427366737,
  "messages": [{
    "id": ed9dc38c-73e5-4d72-a741-22b11f6e151a,
    "version": "0.5.x",
    "content": "<p>Hey there! 0.6 is available, visit <a href=\"https://ghost.org/download\">Ghost.org</a> to grab your copy now<!/p>" 
  ]}
}

The intention is that Ghost will read these, and display these custom notifications in the top notification spot where update notifications used to go, allowing us to push a particular release or feature, without interfering with the general concept of ‘is there an update available’. The ‘top’ notifications will need to be changed to be dismissible, unlike the existing version.

Note: At some point since 0.5.0, there has been a regression in the notification system, such that top notifications are no longer shown in the correct spot at the top of the screen, but appear in the normal bottom left ‘toaster’ location. This will need fixing.

Each custom message from Ghost.org will have 3 properties, firstly a GUID which should be stored in an array of seenNotifications in the settings table once a message is dismissed, so that the message is not shown again. Secondly, a version string which adheres to semver - this is to indicate which versions of Ghost the notification should be shown to. Finally the HTML content for the notification is provided in full, but should be sanitized via the caja tools already in the Ghost admin client, to ensure this cannot be abused.

Once we have this in place, we then have 2 different notification concepts driven on versioning - whether or not there is an update available, which is simple factual information and custom messages, which provide an opportunity to communicate important details to our users.

• update LTS code base
• port changes to 1.0, https://github.com/TryGhost/Ghost/pull/9123
• add UI @kevinansfield, https://github.com/TryGhost/Ghost-Admin/pull/894

[kirrg001]

This isn’t particularly hard to add in the client, we can store the last version and checked date in local storage with the auth data. We then have the option of using the cached value for a badge and forcing a check on the about screen or using the cached value everywhere.

Cool, thanks for feedback. But not for the first version. The first version will simply show if a new release is available or if your blog is up-to-date (on the about page).

[kevinansfield]

But if we want to add a little badge to show that a new release is available (somewhere over the little menu left-top), we would have to add a delay.

This isn’t particularly hard to add in the client, we can store the last version and checked date in local storage with the auth data. We then have the option of using the cached value for a badge and forcing a check on the about screen or using the cached value everywhere.