October: Automatic updating of October CMS and installed plugins

[ayumi-cloud]

Explainer

In wordpress cms you do this by adding a hook in the functions.php file for example:

add_filter( 'auto_update_plugin', '__return_true' );

In October a proposal of adding an option in the config files to turn automatic updates for plugins and themes could be added, e.g.

'auto_update_plugins' => true,
'auto_update_themes' => true

Limitations

Some plugins have a message asking the admins for a manual input before the update can happen. In this case the cms should send an email update to the admin to let them know.

Security Benefits

• All cms suffer from security issues where a plugin and/or themes discovers a xss issue and then updates the plugin - making sure the webmasters cms is running the latest plugins/themes is very important.

Performance Benefits

• Good developers try to maintain and update their plugins and/or themes with new features and increased performance - making sure the webmasters cms is running the latest plugins/themes is very important.

[bennothommo]

@ayumi-cloud It's a good idea, in theory - in practice, in terms with my previous experience with Wordpress, auto-updates were responsible for more of my grey hairs than any other system I have ever worked with.

All updates, on any system, carry an element of risk - you've probably seen it happen with some of our CMS updates. Having a system automatically update - especially one that is perhaps not being maintained or watched by a developer - is a recipe for trouble, especially when dealing with third-party plugins and themes. That can, of course, be mitigated by your suggestion that it be a config option (I would suggest it is false by default, so people understand the risks before they enable it).

The other thing to consider is that there's probably quite a few people who run installs of October CMS without a queue runner or cron job. An automated update system would not be able to easily function in these setups, and I don't think we should go down the route that WP took where they have their cron check run on every request to a page as it would affect performance negatively and wouldn't help sites where traffic is low.

[ayumi-cloud]

@bennothommo I agree with everything you said. Yes as default it would set to turned off in both cases. I don't want to do the exact same approach as WordPress - October CMS can achieve these features with less headache than wp!

After reading your comment - it got me thinking about Semantic Versioning 2.0.0, it maybe a good idea to auto update only MINOR and PATCH versions and send an email message about MAJOR version updates - that way we can avoid you getting anymore grey hairs (joke).

If plugin developers don't follow semantic versioning rules and cause an issue with the cms then users should voice their concerns with plugin developers (as they should be following semantic versioning). Thus we should avoid WordPresses pit falls.

[bennothommo]

@ayumi-cloud I'm gonna drop the mention of themes for now, themes cannot be updated as per the discussion on theme versions (can't seem to find the discussion right now though).

If we were to proceed with this, I think it would be important for October itself to be auto-updateable as well, as most security fixes would be delivered this way.

[ayumi-cloud]

@bennothommo sure I don't mind. But I think plugins and the cms are different, because you, luke and daftspunk have told me in the past that October CMS is not going to follow Semantic Versioning and just stay on version one.

See comments:

https://github.com/octobercms/october/issues/4381#issuecomment-585267817

https://github.com/octobercms/october/issues/4381#issuecomment-585431616

*Many other comments you guys have written in past. But my point is that plugins and cms follow different paths with regards to semantic versioning.

Plugins = Semantic versioning.

CMS = LTS versioning.

Is how I see it right now.

Therefore a clarification would be nice with regards on auto updates for plugins and cms (before coding this issue).

[edit]

Sorry I keep updating this comment trying to put my point across correctly.

I'm talking about CMS updates with regards to major, minor and patch updates - right now that doesn't happen! It's basically more like this:

- v1.0.467
- v1.0.468
...

Is basically writing this, right now:

- 467
- 468
...

I get that moving from Laravel 5.5 LTS to 6 LTS is a major update.

I get a minor (don't need to do anything except press click) is a patch update.

My worry is a minor update that needs a manual review by the end-user. Let's say we are using October CMS with Laravel 6.0 LTS and the update contains a vendor package update that's required for an important security issue and when you update to that vendor package version then some code changes may happen in the themes or plugins (as an example).

Then doing an auto-update would screw things up for people!

So an email message to the end-user telling them about the update would be the best idea.

Therefore October CMS should follow semantic versioning - which it doesn't right now.

My thinking is like this:

• Major CMS updates e.g. Laravel LTS changes - no auto updates (email end-user), e.g. Laravel 6 LTS 2.0.001

• Minor CMS updates e.g. something that requires a code change - no auto updates (email end-user), e.g. 1.1.467

• Patch CMS updates e.g. github repo PR's that don't need any code changes = auto updates (no email sent). e.g. 1.0.467

Tests of special branches:

• Candidate or pre-release (RC) could be given to the current (as of this time) to the Laravel 6 branch as it's not finished and being worked on - yet would be helpful to people testing and adding their input (while being worked on), e.g. 2.0.001-rc

[LukeTowers]

A config value is definitely a requirement (maybe cms.enableAutoUpdate). When it comes to updating plugins vs. the core, it's tricky because some plugin updates require updates to the core and some core updates may require updates to the plugin. It would be easier to deal with this if October used semantic versioning for the core, but that's highly unlikely to change any time soon as discussed in past comments. The best I could see us ever doing is using the minor version number to indicate "Hey, something's changed with this one that you should probably review the notes for to make sure you're still fine." That would basically be just the upgrade to Laravel 5.5 and Laravel 6.x and any future Laravel upgrades because of how sites might be integrated with core Laravel features that change.

October puts a tremendous amount of work into making sure that our builds (patch versions) contain no breaking changes, it's why the Laravel 6 upgrade has taken as long as it has (note that it's now ready for production, a number of users and the core team are using it in production for lots of their October sites with no problems).

[ayumi-cloud]

Cool thanks for the insights Luke and congrats on the Laravel 6 update (I didn't know it was ready now) - will fork the branch and start testing it out.

Just want to ask (to make sure I'm on the right page here) with regards to auto updates with the plugins and cms core. We're going to create two separate pr's and not a single one!

[LukeTowers]

@ayumi-cloud I would say that you should make it as a plugin first, and then we can look at integrating it into the core after we see how popular it is.

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in the last 60 days.
If this issue is still relevant or you would like to see it actioned, please respond and we will re-open this issue.
If this issue is critical to your business, consider joining the Premium Support Program where a Service Level Agreement is offered.

[github-actions[bot]]

This issue will be closed and archived in 3 days, as there has been no activity in the last 60 days.
If this issue is still relevant or you would like to see it actioned, please respond and we will re-open this issue.
If this issue is critical to your business, consider joining the Premium Support Program where a Service Level Agreement is offered.