Update process for extensions

General discussion of development ideas and the approaches taken in the 3.x branch of phpBB. The current feature release of phpBB 3 is 3.3/Proteus.
Forum rules
Please do not post support questions regarding installing, updating, or upgrading phpBB 3.3.x. If you need support for phpBB 3.3.x please visit the 3.3.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
MattF
Extension Customisations
Extension Customisations
Posts: 675
Joined: Mon Mar 08, 2010 9:18 am

Re: Update process for extensions

Post by MattF »

MichaelC wrote:Disable Previous Version
Delete old files (as otherwise, files that were just removed will still be included due to autoloading)
Upload new files
Re-enable extension

Then any migrations that have not already been executed will be (so updating the db) and the files are done cleanly as its just deleting and uploading.
Instead of "delete files" and "upload new files" i think we should be saying:
Delete the old extension package in the phpbb/ext/vendor/ directory
Upload the new extension package to the phpbb/ext/vendor/ directory

Certainly nobody is saying ppl should be going through an extension's file structure and deleting/uploading only what may have changed between versions right? The only fool proof way is to completely remove the entire old extension directory and upload the new one..
Has an irascible disposition.

User avatar
nickvergessen
Former Team Member
Posts: 733
Joined: Sun Oct 07, 2007 11:54 am
Location: Stuttgart, Germany
Contact:

Re: Update process for extensions

Post by nickvergessen »

I still have a problem with deleting all files, as this might cause unnecessary traffic, also I wonder, what I should do with my Gallery images that are uploaded by the users.
I can not create directories outside of the extension (as phpbb should not be writable).
imkingdavid wrote:
Meis2M wrote:is there any notification system for extensions system when new version extension arrive? admin how can find out new version released?
sorry for my english....
Right now, you have to do like you currently do; you will have to keep an eye on the customisations database or development topic for the MOD/Extension.
Well there is a nice MOD for 3.0 Modifications ( https://www.phpbb.com/customise/db/mod/ ... ion_check/ ) and I already ported it to 3.1 using the 3.1 system and composer.json file (instead of adm/mods/xyz.php) also you just point it to any other composer.json file for comparison (can also be in your repository of the mod).

Now I want to allow mulitple checks (aswell as with the customisation database (last approved version))
Member of the Development-TeamNo Support via PM

User avatar
MichaelC
Development Team
Development Team
Posts: 889
Joined: Thu Jan 28, 2010 6:29 pm

Re: Update process for extensions

Post by MichaelC »

nickvergessen wrote:I still have a problem with deleting all files, as this might cause unnecessary traffic, also I wonder, what I should do with my Gallery images that are uploaded by the users.
I can not create directories outside of the extension (as phpbb should not be writable).
That is another problem which we need to choose how to address as not deleting files means things get auto-loaded that shouldn't even be there.
Formerly known as Unknown Bliss
psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
No unsolicited PMs please except for quotes.

User avatar
MattF
Extension Customisations
Extension Customisations
Posts: 675
Joined: Mon Mar 08, 2010 9:18 am

Re: Update process for extensions

Post by MattF »

nickvergessen wrote:I can not create directories outside of the extension (as phpbb should not be writable).
Your Gallery extension provides a unique situation where users upload content to the extension.

Is it possible to have your gallery photo uploads directory live outside of the extension, but still inside your vendor directory, thus making the extension itself separate from the user content?

ie:
/ext/nickvergessen/gallery/
/ext/nickvergessen/gallery_images/
/ext/nickvergessen/newspage/
etc...

Then gallery could be completely replaced with new versions.

The idea of leaving it to the end-user to cherry pick what files are new and must be uploaded, what may need deletion, and so on scares me...99.99% of all support issues I have to deal with in my MODs is due to users never quite getting the install right, often due to not uploading files to the right places. I'd hate to see this potential break-point of the system carry over to 3.1's extensions. :cry:
Has an irascible disposition.

User avatar
nickvergessen
Former Team Member
Posts: 733
Joined: Sun Oct 07, 2007 11:54 am
Location: Stuttgart, Germany
Contact:

Re: Update process for extensions

Post by nickvergessen »

VSE+ wrote:The idea of leaving it to the end-user to cherry pick what files are new and must be uploaded, what may need deletion, and so on scares me...99.99% of all support issues I have to deal with in my MODs is due to users never quite getting the install right, often due to not uploading files to the right places. I'd hate to see this potential break-point of the system carry over to 3.1's extensions. :cry:
Well the basic idea was to allow users to upload a zip in the ACP and then the Extension is automatically unzipped, checked and if it is a valid Extension, moved to ext/
Member of the Development-TeamNo Support via PM

User avatar
MichaelC
Development Team
Development Team
Posts: 889
Joined: Thu Jan 28, 2010 6:29 pm

Re: Update process for extensions

Post by MichaelC »

nickvergessen wrote:I can not create directories outside of the extension (as phpbb should not be writable).
Your Gallery extension provides a unique situation where users upload content to the extension.

Is it possible to have your gallery photo uploads directory live outside of the extension, but still inside your vendor directory, thus making the extension itself separate from the user content?

ie:
/ext/nickvergessen/gallery/
/ext/nickvergessen/gallery_images/
/ext/nickvergessen/newspage/
etc...

Then gallery could be completely replaced with new versions.

The idea of leaving it to the end-user to cherry pick what files are new and must be uploaded, what may need deletion, and so on scares me...99.99% of all support issues I have to deal with in my MODs is due to users never quite getting the install right, often due to not uploading files to the right places. I'd hate to see this potential break-point of the system carry over to 3.1's extensions. :cry:
After discussion on IRC Joas and I worked out it should be ok to file putting the gallery files in files/ or store/
Formerly known as Unknown Bliss
psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
No unsolicited PMs please except for quotes.

Oleg
Posts: 1150
Joined: Tue Feb 23, 2010 2:38 am
Contact:

Re: Update process for extensions

Post by Oleg »

Taking freebsd ports as an example, upgrading a port does the following:

1. the new version is built in a temporary area
2. a package (tarball) is created from existing files of the old version
3. existing files (those in the packing list) of the old version are removed
4. new version is installed
5. the list of files in the new version is stored in the packing list. This could be specified by the port or automatically generated
6. backup package for the old version is deleted

If at any point installation of the new port fails, the backup package is restored.

At no point is the data created by the port touched in any way. At most the running service(s) of the port will be stopped. Any upgrades are expected to be performed manually by the sysadmin. The port may provide upgrade instructions in a post-install message.

User avatar
MichaelC
Development Team
Development Team
Posts: 889
Joined: Thu Jan 28, 2010 6:29 pm

Re: Update process for extensions

Post by MichaelC »

Oleg wrote:Taking freebsd ports as an example, upgrading a port does the following:

1. the new version is built in a temporary area
2. a package (tarball) is created from existing files of the old version
3. existing files (those in the packing list) of the old version are removed
4. new version is installed
5. the list of files in the new version is stored in the packing list. This could be specified by the port or automatically generated
6. backup package for the old version is deleted

If at any point installation of the new port fails, the backup package is restored.

At no point is the data created by the port touched in any way. At most the running service(s) of the port will be stopped. Any upgrades are expected to be performed manually by the sysadmin. The port may provide upgrade instructions in a post-install message.
I'd say this isn't particularly relevant to the situation? We need something that works really really easily for end-users (nothing more complicated than deleting files, uploading files and clicking acp buttons please). If we were doing this in the acp then perhaps, but we aren't, this is getting work done by users manually.

The problem with data has already been solved (putting it in files/ or store/ as it used too).
Formerly known as Unknown Bliss
psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
No unsolicited PMs please except for quotes.

User avatar
naderman
Consultant
Posts: 1727
Joined: Sun Jan 11, 2004 2:11 am
Location: Berlin, Germany
Contact:

Re: Update process for extensions

Post by naderman »

Resulting from a discussion on IRC of how extension updates should work:
  1. Optional: Admin clicks update button in ACP for an extension and is informed that he should upload the new files for the respective extension, maybe also some info on current version and where it is available etc.
  2. Admin overwrites extension files with new extension files - extensions must be backward compatible and run with old schema, or detect outdated schema and disable themselves
  3. Hidden if user is in UI update process because of step 1 already: phpBB detects unrun migrations in changed extension and notifies admin to run update, which brings him to the ACP where an admin who used step1 already is.
  4. Admin is asked to disable the board to avoid issues (this step may be skipped)
  5. Migrations for extensions are run
  6. Board is enabled if it was disabled in step 4

User avatar
naderman
Consultant
Posts: 1727
Joined: Sun Jan 11, 2004 2:11 am
Location: Berlin, Germany
Contact:

Re: Update process for extensions

Post by naderman »

After some more discussion we are back to what nathan proposed in the first post :)

Post Reply