Complete redesign of the update process?

General discussion of development ideas and the approaches taken in the 3.x branch of phpBB. The next feature release of phpBB 3 will be 3.3/Proteus.
Forum rules
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.2.x. If you need support for phpBB 3.2.x please visit the 3.2.x Support Forum on phpbb.com.

If you have questions regarding writing extensions please post in Extension Writers Discussion to receive proper guidance from our staff and community.
User avatar
david63
Registered User
Posts: 287
Joined: Mon Feb 07, 2005 7:23 am
Location: Lancashire, UK

Re: Complete redesign of the update process?

Post by 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.
David
Remember: You only know what you know -
and you do not know what you do not know!

User avatar
DavidIQ
Customisations Team Leader
Customisations Team Leader
Posts: 1834
Joined: Thu Mar 02, 2006 4:29 pm
Location: Earth
Contact:

Re: Complete redesign of the update process?

Post by 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.
Image

User avatar
david63
Registered User
Posts: 287
Joined: Mon Feb 07, 2005 7:23 am
Location: Lancashire, UK

Re: Complete redesign of the update process?

Post by david63 »

DavidIQ wrote:
Thu Mar 10, 2016 1:13 pm
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.
David
Remember: You only know what you know -
and you do not know what you do not know!

User avatar
Ger
Registered User
Posts: 293
Joined: Mon Jul 26, 2010 1:55 pm
Location: 192.168.1.100
Contact:

Re: Complete redesign of the update process?

Post by 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.
Above message may contain errors in grammar, spelling or wrongly chosen words. This is because I'm not a native speaker. My apologies in advance.

User avatar
DavidIQ
Customisations Team Leader
Customisations Team Leader
Posts: 1834
Joined: Thu Mar 02, 2006 4:29 pm
Location: Earth
Contact:

Re: Complete redesign of the update process?

Post by DavidIQ »

david63 wrote:
Thu Mar 10, 2016 1:38 pm
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.
Image

User avatar
david63
Registered User
Posts: 287
Joined: Mon Feb 07, 2005 7:23 am
Location: Lancashire, UK

Re: Complete redesign of the update process?

Post by david63 »

DavidIQ wrote:
Thu Mar 10, 2016 4:13 pm
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
DavidIQ wrote:
Thu Mar 10, 2016 1:13 pm
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.
DavidIQ wrote:
Thu Mar 10, 2016 4:13 pm
I'm only talking about listing the files that will be replaced
That would be my take on this as well
David
Remember: You only know what you know -
and you do not know what you do not know!

User avatar
DavidIQ
Customisations Team Leader
Customisations Team Leader
Posts: 1834
Joined: Thu Mar 02, 2006 4:29 pm
Location: Earth
Contact:

Re: Complete redesign of the update process?

Post by DavidIQ »

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

CHItA
Development Team
Development Team
Posts: 162
Joined: Thu Mar 12, 2015 1:43 pm
Location: Budapest, Hungary

Re: Complete redesign of the update process?

Post by CHItA »

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

User avatar
DavidIQ
Customisations Team Leader
Customisations Team Leader
Posts: 1834
Joined: Thu Mar 02, 2006 4:29 pm
Location: Earth
Contact:

Re: Complete redesign of the update process?

Post by DavidIQ »

CHItA wrote:
Thu Mar 10, 2016 4:28 pm
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.
Image

CHItA
Development Team
Development Team
Posts: 162
Joined: Thu Mar 12, 2015 1:43 pm
Location: Budapest, Hungary

Re: Complete redesign of the update process?

Post by 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.

Post Reply