Complete redesign of the update process?

[david63]

My view of the automatic updater is that it should be removed. One of the main concepts of 3.1 and above is that of extensions and child styles, removing the need to change core files. If people are changing core files then it is up to them to reapply those changes - I have done it in the past when updating other applications where I have made changes to the files.

Now I accept that one reason for changing core files is that there are not the events needed in some cases, or the extended wait for them to be added to the core. When 3.1 was in its infancy I remember asking the question about core updates for events and the answer was that it was anticipated that there would be an update for events at least every two months - this, as we know has not happened. Also the process for adding events is not exactly the most straightforward.

The auto update procedure creates more problems that anything else on the support site (to be honest I have never been able to get it to work - but that's another story!). Updates should, in my opinion, be changed files (or full files if you really want) with database update - ideally all run from the ACP at the push of a button.

[DavidIQ]

I fully agree that the automatic updater should just be removed. However some sort of sanity check should be in place indicating/listing what files will be replaced, outside of the vendors directory. I would say that all files would need to be processed in that case, not just changed files. This is because if we replaced functions.php for instance that might cause the entire site to stop working because of a shared global function being blown away.

[david63]

I fully agree that the automatic updater should just be removed. However some sort of sanity check should be in place indicating/listing what files will be replaced, outside of the vendors directory. I would say that all files would need to be processed in that case, not just changed files. This is because if we replaced functions.php for instance that might cause the entire site to stop working because of a shared global function being blown away.

I think you are making too much work and over complicating the process.

There are two scenarios:

1. Update - where you are updating the current minor version (3.1.7 -> 3.1.8) and major changes such as moving functions.php should not be taking place and this is where you only need changed files.

2. Upgrade - where you are moving from one major version to another (3.1.x -> 3.2.0) where major changes, such as moving functions.php, would be made and that is where you would have a full replacement.

Both of these scenarios could be easily controlled both by the install routine and by the files that are available. A "one click" option to update/upgrade could ensure that files that are not required are deleted otherwise there is no way of guaranteeing that users would actually delete the files.

[Ger]

Would it be feasible to create an array of files (or file structure) with all files that have to be removed, replaced and added, perhaps even in the right order (preventing conflicting function/class names)? The installer should be able to handle that I would think.

To make sure there are no errors for the end users (guests) the complete forum should be disabled during the process and a static frontpage" should be served to anyone who requests a forum page indicating there's some maintenance is going on.

[DavidIQ]

I think you are making too much work and over complicating the process.

I'm only talking about listing the files that will be replaced, nothing else. That's really not that complicated. Now if we went and decided to list all of the changes that are going to get overwritten that's another story, but I'm not suggesting that.

[david63]

I'm only talking about listing the files that will be replaced, nothing else. That's really not that complicated. Now if we went and decided to list all of the changes that are going to get overwritten that's another story, but I'm not suggesting that.

Sorry - I misunderstood what you were saying. It was the bit

I would say that all files would need to be processed in that case, not just changed files.

Where I thought you meant that all files would need to be scanned for changes.

I'm only talking about listing the files that will be replaced

That would be my take on this as well

[DavidIQ]

Ah sorry, the more I use English the less I understand others it seems

[CHItA]

I don't really see how what is suggested here differs from what 3.2 already has (other than the ACP update button).

[DavidIQ]

I don't really see how what is suggested here differs from what 3.2 already has (other than the ACP update button).

I think the aim would be to eliminate having to download and upload files in a similar way that we would be managing extensions.

[CHItA]

If you use one of the automatic options, you don't have to. If you have merge conflicts, then you do, but that's only for those who modified core files, so it doesn't seems to relevant for this discussion.

Downloading update package from .com to your install is doable, but it might have some security implications.