My comments there and on the mailing list still stand. The 3.5 update could not be made reliably with the Extension Manager because the update relies on code that is only available in the 3.5 code base. The way the Extension Manager update works the entire update will run on the version of the CMS you are updating from. This logic has been flawed since 1.6.0's release in 2011 and has already required workarounds for updates (an explicit import of the legacy JApplication class for 2.5 updates because the old files are not removed in time and the autoloader rules giving preference to libraries/joomla over libraries/legacy, the requirement to disable the "System - Remember Me" plugin, and hacks in certain system plugins to reassign class member variables that should have been assigned in the parent JPlugin class). The 3.5 update added changes that just cannot work with the Extension Manager way any longer.

I appreciate your feedback.

I understand what you're saying about the 3.5 code base, but what I don't understand is why you / the team have chosen to continue developing the joomlaupdate component, incorporating 3rd party akeeba logic directly, rather than expanding the functionality of the Joomla installer classes to accommodate these needs.

Surely the core installer classes would benefit, as would all the components, modules, and plugins, from this new functionality of a forked installer instance. This would not necessarily be difficult to accomplish either, and would eliminate what seems to be a flawed diversion from the core handler to a two party system (joomlaupdate & ext manager).

If this is a issue where we need a quick fix then that's a fair answer, and our team can certainly contribute to merging the joomlaupdate into the core extension manager.

Joomla extensions don't need the environmental checks that updating the Joomla core does need. Fact is from 1.6.0 to 3.4.8 the Extension Manager essentially updated Joomla as an extension of Joomla.

The extension install library should NOT be hacked up to accommodate updating the Joomla core as an extension. The update component, "incorporating 3rd party akeeba logic" or not, is the correct way to handle updates by performing operations in a very specific order and performing specific steps without reliance on the Joomla API which ensures that the steps that do rely on the Joomla API can function regardless of what version the user upgraded from.

However if your team is is able to contribute the code to make it work the
way you want it to work and satisfy the requirments Michael has outlined
above then I am sure it will be looked at and considered

On 23 March 2016 at 16:35, Michael Babker notifications@github.com wrote:

Joomla extensions don't need the environmental checks that updating the
Joomla core does need. Fact is from 1.6.0 to 3.4.8 the Extension Manager
essentially updated Joomla as an extension of Joomla.

The extension install library should NOT be hacked up to accommodate
updating the Joomla core as an extension. The update component,
"incorporating 3rd party akeeba logic" or not, is the correct way to handle
updates by performing operations in a very specific order and performing
specific steps without reliance on the Joomla API which ensures that the
steps that do rely on the Joomla API can function regardless of what
version the user upgraded from.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub
#9547 (comment)

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
http://brian.teeman.net/

Thank you @mbabker and @brianteeman for the time. We'll most certainly get that over to the team, and / or share any roadblocks.

@mbabker and @brianteeman - we've got a prototype ready that includes the merge of the forked handler into the com_installer component. This is a proof of concept that is at the point where the installer is being generated, forked process is started, monitor runs, the files are installed, and the resulting error / success responses are handled.

https://github.com/WebuddhaInc/joomla-cms/tree/com-installer-upgrade

Changes

• The installer was modified to pass packages onto the forked installer. Plugin, components, etc are still installed during the single request as before.
• Logic was started for installer providers being isolated, with Akeeba as the first.
• A new archiveFolder handler was added to the Akeeba installer to support an archive already uncompressed. The Akeeba restore engine can now handle incremental installation from an uncompressed folder.
• When installing a package via url or zip, the package is first uncompressed using the Joomla installer, then the path is forwarded to the provider.
  
• The standalone installer is generated by the installer model with instruction from the provider.
• Files are now written to the /tmp (or /media if /tmp below root) so that we are no longer writing files to the components folder.

TODO

• Activate core package lookup and reporting in update dialog.
• Do another pass on the joomlaupdate & JInstaller classes to catch any pre/post processing considerations that we've missed.
• Finish any remaining separation of Akeeba logic from the general handler.
• Review any OS packages that can be introduced as a provider that includes DB support.
• Examine the future provider requirements and finalize an architecture.
• Examine best practice for the generation of the standalone installer. The current build is basic. There are no doubt vendor packages we can leverage as compilers if reasons exist.
• Examine if / why / how this provider logic could be moved from the admin component into the installer classes.
• Examine / implement a standard for packages to include a JInstaller handler for pre/post processing. We probably don't want to use the current standard since it needs to be standalone.

To test this we just created a Joomla 3.5 archive with the joomla.xml file included.

Hopefully it's clear where we are going with this. Your thoughts are appreciated.

I can't say I can follow what you're proposing because there are a lot of extraneous whitespace changes in pre-existing files in staging...WebuddhaInc:com-installer-upgrade which just makes trying to figure out what you've done even more complex. With that said...

It seems you are re-introducing a dependency on code that pre-exists to the installer to make it work. Part of the reason the "Akeeba" restore.php file works so well is it is entirely self contained and can be updated on a whim (and when the updater makes changes to it, those changes don't cause breaks). Separating it out as you have and building that entire process back into Joomla to me spells trouble.

It also seems like you are adding a lot of overhead to the Extension Manager for something that extensions do not need to support. The core update process for much of it needs to be a self-contained environment, the Joomla Update component provides that with its current structure, whether it was Akeeba based or written from scratch by someone else.

Lastly, before you go too much further, what issues does #9612 NOT address at this point that you are trying to address?

Note: I'm not saying this is a theoretical bad idea, but honestly I'm not sold right now on what Joomla gains from your proposal.

@mbabker Thanks for the feedback

I can't say I can follow what you're proposing because there are a lot of extraneous whitespace

I do see the white space you reference. There are very few adjustments to the previous logic. 95%+ of the changes are additions / new files. If it helps I can reduce the white space changes.

It seems you are re-introducing a dependency on code that pre-exists to the installer to make it work.

You are correct - this is a POC

• Rather than re-writing Akeeba in this first run we're showing among other things how we can eliminate the component / logic separation.
• Akeeba has been relegated to a "provider" logic that can be removed or exist as one of many providers after the next / future rounds of improvement.
• This concept can be easily refined to further segregate all installer logic from particular package needs, so the package dictates case outside of basic file copy.

Part of the reason the "Akeeba" restore.php file works so well is it is entirely self contained and can be updated on a whim (and when the updater makes changes to it, those changes don't cause breaks).

There are issues that we see and are attempting to address:

• Several restore file conditions is Akeeba need specific
• The Akeeba specific preparation logic has been intertwined with joomlaupdate
• This Akeeba restore depends on a configuration file written to the component folder, which just seems to be a bad practice
• Executing the restore.php file from within the same environment that is being updated introduces the same problems that we're trying to avoid. To overcome this there are skip rules to stop restore.php from being copied, which ultimately means it can only be updated with special conditions. Moving it from it's location solves this problem.
• Editing files as large as the packaged restore file is difficult. The separation eases team development and introduces a simple logic for the provider to build a compiler on demand. If the argument is that this particular provider implementation seems too cumbersome, the parts can be easily combined again.

Ultimately we are still creating a self contained installer, it is now just built by a self contained provider. We can of course remove the entire provider logic without breaking the benefit of this joomlaupdate merge into the installer.

Separating it out as you have and building that entire process back into Joomla to me spells trouble.

I'm not sure it introduces any more trouble than those introduced by the restore file to begin with. Either the installer can write the file or it cannot, and if not then it would have failed with either approach. If it is problematic then eliminating this build feature wouldn't change the other benefits of this approach. Each provider can have a single file that is copied.

It also seems like you are adding a lot of overhead to the Extension Manager for something that extensions do not need to support.

I see your point. Our view is that, what you consider overhead is minimal compared to the the joomlaupdate component we will be dropping.

Lastly, before you go too much further, what issues does #9612 NOT address at this point that you are trying to address?

This is a completely different approach to the problems addressed in that PR. We are not trying to make the joomlaupdate work, we are trying to get rid of it.

It seems evident that the development community is moving to centralized package management solutions. For Joomla to be working in the opposite direction concerns us. Our opinion is that we should be working toward integration with products like composer, which this update prepares us for.

Whether a core, component, module, or plugin, they are all as packages to be installed. Each package can be expected to dictate destination, pre / post processing operations, dependencies, and otherwise independently. The installer just needs to monitor file copy and kick off a few events. Most of the weight in Akeeba are for the different archive types and file handlers, which is reasonable to expect from any provider. We could drop all but the ZIP and FOLDER portions to reduce complexity.

I know there are a lot of considerations that you and others have made to get the software where it is, and I appreciate you taking the time to review these changes. Our team has been working with Joomla since it was Mambo, and have several dozen packages that we manage / distribute. We likewise feel invested in the future of Joomla.

I think there are some decisions that can be made now that would open the door for a major simplification of the installation / upgrade and even dependency management moving forward.