New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DO NOT UPDATE CORE THIS WAY #1

Open
wilsonge opened this Issue Mar 13, 2016 · 11 comments

Comments

Projects
None yet
3 participants
@wilsonge
Copy link

wilsonge commented Mar 13, 2016

We are literally removing support in 3.5.0 from updating via JInstaller because of the ordering the update is done in and you are about to reintroduce it with this script.....

When updating this way/through Extension Manager the following process happens:

  • Extract package to tmp location
  • Look for extension script, if it exists load it into memory and if it has a preflight method, trigger that
  • Copy all the new files into place
  • Update the extensions table's database row
  • Run any SQL schema updates
  • If the extension script has an update method, trigger that
  • Cleanup from the update routine
  • If the extension script has a postflight method, trigger that

In the update component, it's more like this

  • Copy all the new files into place from a standalone script
  • Loop back into Joomla (now running the new version's code in full)
  • Load the extension script into memory, trigger preflight if it exists (it doesn't right now)
  • Update the extensions table's database row
  • Run any SQL schema updates
  • Trigger update method in extension script if it exists (it does)
  • Cleanup from the update routine
  • Trigger postflight method in extension script if it exists (it doesn't right now)

The important thing being is the postflight is called with the new versions code rather than the old versions code.....

If you keep the current code as is the Core Updates are going to go badly badly wrong......

@nikosdion

This comment has been minimized.

Copy link

nikosdion commented Mar 14, 2016

I already have the code that does the installation part (it's like the update MINUS the download): https://github.com/akeeba/vagrant/blob/master/vagrant/files/joomla/install-joomla-extension.php I am volunteering to release that code under GPLv2 and contribute it to Joomla! with necessary modifications. If you're interested give me a holler.

Many extensions' installation scripts assume that the installation / update happens in the back-end application, in an interactive user session. This lends to some pitfalls about installing and updating extensions through CLI because of the following assumptions:

  • JFactory::getApplication() returns a subclass of JApplicationAdmin or at least JApplicaitonWeb (for those extensions who understand that install/update can be performed through a 3PD service like myJoomla or Watchful). You'll see a lot of blank methods in the script; that's the reason why.
  • Using JUri to get the site's domain name and path. This CAN be worked around by using $live_site whenever it's set OR saving the URL to the site in a com_installer configuration variable every time someone logs into the back-end of the site and using that in the CLI script. I am puling this trick in Akeeba Backup's CLI script for 6 years; I've perfected this technique.
  • Use of JavaScript to perform long running operations. For example installing updates, migrating data to a new schema structure etc. This was a necessary evil for installation / updates over the web interface to avoid timeouts. Unfortunately this breaks in CLI. Developers will need to detect the presence of CLI and have their installation script act accordingly (CLI doesn't have the same kind of strict execution time limit).

That said, 95% of the extensions in JED won't have a problem. Some major extensions may indeed have a problem, so the JED should reach out to the top downloaded and top rated extensions' developers as soon as the code is here.

Regarding fully automating updates, I would argue that this is a treacherous path the way updates are currently implemented in Joomla!, i.e. without regard for semver. I would understand why a site owner might want to receive automatic updates between FooBar 1.0.x and 1.999.x but not from FooBar 1.x to FooBar 2.x –presumably because 2.x introduces backwards incompatible changes. Unfortunately I don't have a solution for that. As a developer I would add a configuration switch in my extension, check it in the preflight of my installation script and abort with an error if the user had chosen to stick to same major version branch. This also sums up why I can't come up with a generic solution: whether you need to allow updates to the next minor or major version branch depends on the extension and how it handles b/c (e.g. in template overrides) over subsequent versions.

Finally, one improvement I would add to the update script would be the ability to not only output progress in STDOUT but also send emails about updates to the Super Users (all by default, alternatively a select few could be selected in com_installer's options) only if updates are installed. Something like:

3 extension updates were found on your site.
2 extension update failed to install.

Successful updates
--------------------------------------------------------------------------------
ACME Subway, package, version 1.2 (previously installed: 1.1)

Failed updates
--------------------------------------------------------------------------------
Foo Bar, plugin, version 2.0 (currently installed: 1.2.3). Update failed because of error:
<p>You have selected to remain in the 1.x version branch in the plugin options. Please change that option to allow updates to version 2.x</p>

Bar Baz, template, version 1.1 (currently installed: 1.0.7). Update failed because of error:
-1 - An error occurred Copy failed

Sorry for the long comment, here's a potato 🍠

@rdeutz

This comment has been minimized.

Copy link
Contributor

rdeutz commented Mar 14, 2016

Thanks for joining the discussion. This script has beed build on a hackathon before the World Hosting Days and it was project suggestion from plesk. There are pitfalls I know and this will only work under certain circumstances. That's totally ok, it wasn't the goal for this project to build the perfect solution. It can be a contribution to something we are discussing for a long time, the installer is pretty much old code and any Joomla! developer has noticed this on one or the other way.

@wilsonge

This comment has been minimized.

Copy link
Author

wilsonge commented Mar 14, 2016

Not only will it not work 100% of the time on 3.4.8 it will introduce a security risk..... The upgrade of utf8mb4 will not take place meaning the incorrect filtering will happen 100% of the time on servers that support UTF8MB4!!

The problem is not the installer - it is 100% OK for extension installation. The problem is using Joomla's internal code to update itself! That is a massive no no. The code has to be updated by something outside of the main CMS (i.e. Joomla Update for the web client installs).

@rdeutz

This comment has been minimized.

Copy link
Contributor

rdeutz commented Mar 14, 2016

So the key is the copy the files first.

@wilsonge

This comment has been minimized.

Copy link
Author

wilsonge commented Mar 14, 2016

Yes (but only for core - not for extensions)

@rdeutz

This comment has been minimized.

Copy link
Contributor

rdeutz commented Mar 14, 2016

Implemented for core with 28a14fe

@wilsonge

This comment has been minimized.

Copy link
Author

wilsonge commented Mar 14, 2016

OK -that's an improvement - BUT I'm removing the XML file from root of the update package from 3.5.0 (to stop updates via Extension Manager - so this mechanism will still not work for 3.5.0+)

@rdeutz

This comment has been minimized.

Copy link
Contributor

rdeutz commented Mar 14, 2016

where you are going to put it in future?

@wilsonge

This comment has been minimized.

Copy link
Author

wilsonge commented Mar 14, 2016

@rdeutz

This comment has been minimized.

Copy link
Contributor

rdeutz commented Mar 14, 2016

We are using now the finaliseUpgrade from JoomlaupdateModelDefault so we should be save, assuming we are changing the JoomlaupdateModelDefault when removing the joomla.xml

@wilsonge

This comment has been minimized.

Copy link
Author

wilsonge commented Mar 14, 2016

Ahh that should be ok - it's not at the moment - but we're fixing it at the moment in joomla/joomla-cms#9414

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment