how about moving the entire update so a standalone app that is only accessible via direct link from the cmd?

It really doesn't need to be a full app for it to work right. Since restore_finalisation.php is only triggered after the filesystem has been updated, we should be able to safely boot the core framework and trigger the finalization steps. In essence the restore.php file is its own application in a file so we do have a standalone app with a hook point to run our app specific stuff, I don't think we'd need to get much more elaborate with it.

The main thing I want to do is stop going through our index.php file which boots and executes the normal Joomla application class (including triggering all the normal plugin events) as using the normal request flow is what's causing us the biggest headaches. We need to boot the admin app class just so JFactory::getApplication() calls work correctly, but we can 100% avoid calling the app's execute() method.

This is not really solution but (I have not tested it) an admin could change .htaccess file to redirect a request from ./administrator/index.php?option=com_joomlaupdate&task=update.finalise to ./administrator/postupdate.php file and starts updating to joomla 3.8.

Notice, it is not as secure as regular update because session is not checked and ftp does not work.

Notice, it is not as secure as regular update because session is not checked and ftp does not work.

And that's why I'm suggesting to hook into restore.php more. The update component is already wired up to pass information (securely) to it. So unlike my postupdate.php which is potentially executable by an unauthenticated user, the update process still can only be triggered by someone with correct privileges.

Please correct me if I misunderstand. It would be good to do that before J4

Restore.php does:

1. After zip package has been downloaded then it starts extracting it

2. Takes care about access, security between ajax calls

3. After new files has been extracted delete old files

4. After done redirect to /administrator/index.php?option=com_joomlaupdate&task=update.finalise...

Restore.php would:

1. After zip package has been downloaded then it starts extracting it

2. Takes care about access, security between ajax calls

3. After new files has been extracted delete old files

4. Uses a new function to do the same as in JoomlaupdateModelDefault::finaliseUpgrade() https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_joomlaupdate/models/default.php#L589
   but execute each sql update file or query per ajax call.

   • may be move / copy functionality of JoomlaupdateModelDefault::finaliseUpgrade() to JoomlaInstallerScript class at https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_admin/script.php#L17

5. After done redirect to /administrator/index.php?option=com_joomlaupdate&task=update.cleanup...

@csthomas I'll keep that in mind in my PR. Thanks.

@brianteeman I am working on that targeting J4. The work is ON since #14159 (comment)

However, The post upgrade script from @mbabker has given me opportunity to do this in short way and possibly can come in J3.x itself. I'll continue the big work for J4 anyway.

You can't do it directly first - you can only do this if you're upgrading from Joomla 3.3/3.4 and higher (when the support for restore_finalisation was introduced). As a result even if you move it there it must still be called in script.php

TLDR: Just do it in 4 - it's so much easier

Change for the sake of change, there are other tasks needing attention without this.