[33]Library Installer

User avatar
Hackwar
Joomla! Virtuoso
Joomla! Virtuoso
Posts: 3788
Joined: Fri Sep 16, 2005 8:41 pm
Location: NRW - Germany
Contact:

[12]Updates to external libraries & extensions + 2 ideas

Post by Hackwar » Fri Feb 15, 2008 9:53 pm

1. Updates for external libraries
The following libraries are outdated in 1.5 and should be updated: 2. Updates for external extensions 3. Additional ideas
3.1 Upgrade of Joomla! 1.5 to 1.6
It would be interesting to create a component that does all the updating from 1.5 or 1.5.1 to 1.6, since there are some database scheme changes and the data in the database has to be updated, too. It would simplify updating to a mere number of clicks. Since the changes would be quite substantial, it is most likely that both the maximum upload size as well as the maximum execution time would be reached when doing all this in one step. This would mean, we would have to divide the upgrading into logical steps, both in terms of uploading, moving files around and updating the database. Maybe all this is possible with JPackage?
3.2 Show/Hide Button for TinyMCE Editor
With a few very simple additions, a link to hide the WYSIWYG editor could be added to the textarea. A patch for this is added to this document.
patch_editor_show_hide.zip
You do not have the required permissions to view the files attached to this post.
god doesn't play dice with the universe. not after that drunken night with the devil where he lost classical mechanics in a game of craps.

Since the creation of the Internet, the Earth's rotation has been fueled, primarily, by the collective spinning of English teachers in their graves.

RoscoHead
Joomla! Explorer
Joomla! Explorer
Posts: 318
Joined: Mon Jul 30, 2007 11:01 pm
Location: Melbourne, Australia
Contact:

[35]Joomla! update logic

Post by RoscoHead » Sat Feb 16, 2008 12:31 am

I would like to see an XML schema developed describing tables, such that extensions can include the schema they require and the installation process adds/updates any tables automatically as required. This removes the need for files like "1.0-1.2.sql" and "1.1-1.2.sql". As most updates involve mostly adding/dropping of tables and adding/dropping of fields, this would remove most of the hassle of providing upgrade SQL.

An appropriate schema would need to be created to describe table structure including details such as table collation and storage type, field types, and index type & structure.

Of course installation would still have to be able to execute any install/uninstall SQL files as it currently does for loading default data and/or situations that can't be handles by the XML.

ROSCO

Jonathan Cameron
Joomla! Apprentice
Joomla! Apprentice
Posts: 34
Joined: Wed Sep 12, 2007 7:55 pm
Location: Pasadena, California

Simplify installation of multi-part extensions

Post by Jonathan Cameron » Sat Feb 16, 2008 11:03 pm

1. Background/Summary

Many extensions include more than one component, module, or plugin. Currently the installation process is a bit tedious. The installer has to install each component, module, or plugin separately.

The proposal is to simplify installation of multi-part extensions by extending the installation process to install all components, modules, or plugins in one step for the administrator. The benefits are two-fold: First, when an extension contains several parts, it is easy to overlook one part during the manual installation process. Second, this would be simplify adding extensions to Joomla for new users who don't know much about unzipping files or installing extensions in Joomla.

2. Functional goals
The current installation system loads a single archive (zip) file and unpacks it, and then reads through the installation XML file to copy files from the archive to the desired locations is the Joomla files. This is really the hard work.

NOTE: The next part assumes that the extension is delivered to users in a single ZIP file that contains separate zip files for each component, module, or plugin that composes the extension.

There are (at least) three possible approachs. (1) When an installation file is unpacked and no installation XML file is found, Joomla would look for all enclosed ZIP/archive files and try to install them separately. (2) A new extension installation XML file could be created at the top level of the extension archive file that outlines which components, modules, or plugins are contained along with any other useful information such as desired installation order, etc. The installation software would read this meta-installation XML file and handle each part appropriately. This might include options that certain plugins are to be enabled by default. (3) Integrate the installation XML files of all parts into one installation file with several separate <install...></install> sections, one for each part. The main archive/zip file would not contain any zip files for the parts, but the files for each part would live in its own directory within the larger extension archive file.

Some thought would need to be given to how to display the warnings, error messages, and installation output for each part. Also, if difficulties are encountered during the installation of one of the parts, what should happen to the parts that were installed just before the failing one? Should they be rolled back?

3. Changes to management / user experience

* This change could probably be made backwards compatible: The proposed mechanisms kick in when the installer discovers that the extension file is not a simple single component, module, or extension. These older installation files would not need to be updated.

* This enhancement would simplify installation of multi-part extensions for the system administrator, particularly for novice administrators.

* The installation procedure would not change. No training would be needed.

* It does not seem like this would be difficult to implement or require a lot of code.

* There would be no effect on the front end.

RoscoHead
Joomla! Explorer
Joomla! Explorer
Posts: 318
Joined: Mon Jul 30, 2007 11:01 pm
Location: Melbourne, Australia
Contact:

Re: Automatic update of table structures

Post by RoscoHead » Sun Feb 17, 2008 4:30 am

  1. Introduction
    The term "template" is used interchangeably in the Joomla! source code for both the files which reside under the /templates/* directories, and the files which reside under the tmpl sub-directory of a component view (also termed "layout"). This can be confusing to developers, and reduces maintainability. This should be changed to be more consistent.

  2. Scope
    This involves many changes to library variables and functions, for example JView::loadTemplate() should be JView::loadLayout().

  3. Technical Implementation
    All instances of "template" being used when "layout" should be used instead need to be identified, and changed.

  4. Impact
    Because the API must be backwards compatible, stub functions with the old names must be provided to call the new functions. These may be deprecated in the future, impacting 3PD extensions.

  5. References
    Framework API
ROSCO

User avatar
Hackwar
Joomla! Virtuoso
Joomla! Virtuoso
Posts: 3788
Joined: Fri Sep 16, 2005 8:41 pm
Location: NRW - Germany
Contact:

[21]Installation system check improvements

Post by Hackwar » Sun Feb 17, 2008 1:08 pm

1. Introduction
1.1 Scope
This document should describe a series of improvements to installation checks and support for new users.
1.2 Objective of the document
This document is aimed at providing a basis for a discussion about a series of improvements to installation checks to support new users.
1.3 General remarks
1.4 Definitions
1.5 License
GNU GPL
2. What is the current issue?
Looking into the forum, there is a series of typical issues, which users are facing. Often enough, the files got corrupted while uploading, the PHP version is not compatible and folders have the wrong owner and access rights. This produces unnecessary workload for supporters in our forums and grieve for the users.
3. What are the proposed improvements?
These improvements basically touch three areas:
  • The installation of Joomla! itself
  • The installer for extensions and
  • The system info screen in the help menu
3.1 Joomla! Installation
On the second screen of the installation, the checks for the compatibility of the server with Joomla need big improvements. For example, working settings don't need to be shown, making the interface simpler. Maybe a slide-in area can be used to show the working settings, but besides that, only not-working settings should be visible.
The PHP check needs to check against an array of PHP versions, since we have a few versions that don't work, even though they are >4.3.9.
The folder check should be reintroduced, not only checking for writable or not, but also for the owner of the files. For Joomla to work at its best, it would be good if the owner of the files is the user of the Apache server. Based on this check and checking for safe mode, too, the FTP mode should not be used at all and that step can be omitted entirely.
To make sure that the files are all still in prestine condition, a check button should be on the second screen of the installation, that checks the checksums of all files against a checksum file. It should seperate which files are necessary and which are not, thus making it possible to modify the installation package with pre-installed extensions. This is supposed to prevent corruption of files, as they seem to happen from time to time when uploading the files seperately via FTP.
3.2 Extensioninstaller
The Installer for Extensions should check all the folders that need to be writable before installing an extension, also inside the extensions folder itself. To prevent installation errors due to pre-existing folders, it should also check if the folder is empty instead of throwing an error directly. In case of an error, it should list the folders, that are not writable.
3.3 System Info Screen
The system info screen should provide all the informations that are available on the second install screen, including the file check function.
4. Effects on...
4.1 Users
There is no negative effect to be expected on the user.
4.2 3P extensions
There is no negative effect to be expected on 3P extensions.
4.3 Performance
The effect on performance should be neglectable, since the code is only executed very rarely. Especially the file check is pretty resource intense, but a first test has shown that it should be possible even on a slow webspace.
installation_0_1_hannes.zip
You do not have the required permissions to view the files attached to this post.
god doesn't play dice with the universe. not after that drunken night with the devil where he lost classical mechanics in a game of craps.

Since the creation of the Internet, the Earth's rotation has been fueled, primarily, by the collective spinning of English teachers in their graves.

User avatar
H13
Joomla! Ace
Joomla! Ace
Posts: 1545
Joined: Sun Dec 10, 2006 6:39 pm
Location: Czech Republic
Contact:

Installing or Upgrading components, ...

Post by H13 » Sun Feb 17, 2008 8:36 pm

1. There is a great environment for installing components but I am missing the possibility for upgrading components (maybe I only don't know where to find it or how to create it).

2. How should it work:
- If user wants to install a component:
a) new files will be copied
b) new component tables will be created (standard installation procedure)
- If user wants to upgrade a component
a) new files will be copied (old files will be removed while uninstalling before upgrading or they will be overwritten)
b) NO tables will be created (it means, all old data will be used with new upgraded component)

Before you want to upgrade a component, you must uninstall the old component
- If user wants to upgrade a component
a) old files (in old component) will be deleted
b) NO tables will be removed from database
- If user wants to remove the component
a) old files will be deleted
b) component tables will be deleted too (DROP TABLE IF EXIST)


The problem is not upgrading (Every developer can write own upgrading script --> install.component.php: install --> creating of tables, upgrade --> no creating of tables) but there is a problem with uninstalling the old component: developer cannot write own script because while uninstalling all data (including the developer uninstalling script) will be deleted and the script cannot be run.

I hope, you know what I mean...

Thank you, Jan
- Phoca Cart - Joomla eCommerce App - https://www.phoca.cz/phocacart
- Phoca Gallery - powerful image gallery
- Phoca Restaurant Menu - https://www.phoca.cz/phocamenu
- Phoca Download - download manager for Joomla

User avatar
willebil
Joomla! Guru
Joomla! Guru
Posts: 762
Joined: Thu Aug 18, 2005 12:06 pm
Location: Netherlands

Re: Installing or Upgrading components, ...

Post by willebil » Sun Feb 17, 2008 9:09 pm

I plan to write down a whitepaper of this in more detail. Some design details and the actual logic has been targetted at Summer Of Code 2006, and documentation of that can be found here --> http://joomlacode.org/gf/project/jpackage/wiki/

For 1.6 we will target at the update logic and make it full error proof (like reverting when something goes wrong during updating). This will be challenging enough. Your comments are just part of what needs to be done. I will merge this topic when the whitepaper (or other topics that match) are posted.

Thanks for the post!

pasamio
Joomla! Ace
Joomla! Ace
Posts: 1318
Joined: Thu Aug 18, 2005 9:27 am
Location: San Jose, CA, USA
Contact:

Re: Simplify installation of multi-part extensions

Post by pasamio » Mon Feb 18, 2008 12:40 am

Is this similar to what you are requesting:
http://extensions.joomla.org/component/ ... Itemid,35/
Sam Moffatt
Updater, Installer and Authentication Systems
JoomlaCode Backend Systems
Pie.

Geoff
Joomla! Virtuoso
Joomla! Virtuoso
Posts: 3173
Joined: Sun Apr 16, 2006 12:20 am
Location: 127.0.0.1

Re: Installing or Upgrading components, ...

Post by Geoff » Mon Feb 18, 2008 2:05 am

If I'm reading/understanding this correctly, in essence this would function like the SMF Modifcation Manager available in the Administrative backend.
Backup, backup, backup!
The "Master" .htacess file by Nicholas http://snipt.net/nikosdion/the-master-htaccess

pasamio
Joomla! Ace
Joomla! Ace
Posts: 1318
Joined: Thu Aug 18, 2005 9:27 am
Location: San Jose, CA, USA
Contact:

[32]Using classes for component installation custom steps

Post by pasamio » Mon Feb 18, 2008 4:58 am

Introduction
At the present moment components have the ability to run custom installation scripts by utilising the "com_install" and custom uninstall using "com_uninstall". The problem with this is that if one is to implement a multi-installer, these functions can become redefined for multiple component installs which then causes an error.

Proposal
Instead of relying on the com_install and com_uninstall functions, a special class (named like the extension) handles the special installation routines. In addition to running two functions, com_install and com_uninstall, we can easily expand this to handle more than just two functions and encapsulate support functions so that the global function namespace isn't littered with these component specific functions.

For example say we have a component called "Hello", which creates a special class called "HelloInstaller" which is included in a special file (much like install.php or uninstall.php, perhaps this could be called "installer.php"). Within the installer we add support for various calls:

Check (or pre-install)
This is a basic sanity check run before installing the component so that the component can flag anything it thinks is an issue. We run existing pre-install checks with in the installer but we don't give the component a chance to check for anything. This would allow a component to check and cancel a possible installation.

This function should return true on success or false if the installation should be halted. It should also pass back a message if it halts the installation with the error in it.

Install
This would function the same as it does in the existing environment. This would also allow for the installation to be rolled back if part of it failed as well in addition to displaying a message.

This function should return true on success or false if the installation should be halted. It should also pass back a message if it halts the installation with the error in it.

Upgrade
The upgrade function allows the developer to build their own upgrade functionality into the installation system. This would allow the developer to build their own database update and conversion scripts into the installation upgrade method. This method would be triggered as part of the upgrade after all of the files have been replaced with their new versions. This also allows a single package to be used as an installer or an upgrade. In the case of an upgrade the Joomla! installer needs to merely check the file list of the existing on disk component and then do a comparison with the new file. Any file that isn't in the new file can be deleted

This function should return true on success or false if the installation should be halted. It should also pass back a message if it halts the installation with the error in it.

Uninstall
This would behave like the existing "com_uninstall". It does not matter what it returns.

Sample
This is a sample of a potential class. If doesn't do anything but demonstrates how such a class could be layed out. As it is a class it means that support functions can be deployed that allow a neater design.

Code: Select all

class HelloInstaller {

	function install() {
		// do stuff
		if($success) return true;
		else return false;
	}
	
	function uninstall() {
		// do stuff
		// uninstall doesn't return a value
	}
	
	function upgrade() {
		// do stuff
		if($success) return true;
		else return false;
	}
	
	function check() {
		// do stuff
		if($success) return true;
		else return false;
	}

}
Implementation
This would require a slight change to the way the installer behaves and having some extra checking code to see if the appropriately named class has been defined (e.g. class_exists). This then paves the way for multi-installers to work properly without clashing.

A new entry would need to be added to the installer XML file to designate where this installation class would exist.

Impacts
Users
The users notice no difference. Component support for upgrading is provided however which can make their life easier. This also allows for multi-installers to be created that won't cause errors.

Third Party Extensions
Third party extensions do not need to be updated, the old style method can still be supported. However migrating to using the new method is quite easy for third party developers, it is just a matter of adding a class and renaming a few functions.

Performance
This has minimal impact on performance as it is only done during component installation, upgrading and removal. The main issue would be a slight increase in memory usage and parsing time if the disparate functions (install/uninstall) are combined into the same file.

See also
Installation system check improvements White Paper (http://forum.joomla.org/viewtopic.php?f=500&t=266084)
Sam Moffatt
Updater, Installer and Authentication Systems
JoomlaCode Backend Systems
Pie.

pasamio
Joomla! Ace
Joomla! Ace
Posts: 1318
Joined: Thu Aug 18, 2005 9:27 am
Location: San Jose, CA, USA
Contact:

Re: Simplify installation of multi-part extensions

Post by pasamio » Mon Feb 18, 2008 5:05 am

Additional comment: due to the nature of the way components are installed at present, if two components were in a package and both had com_install defined then this would cause an issue. As such this depends on my alteration of the custom installation system.

4. Dependencies
Using classes for component installation (http://forum.joomla.org/viewtopic.php?f=500&t=266332)
Sam Moffatt
Updater, Installer and Authentication Systems
JoomlaCode Backend Systems
Pie.

pasamio
Joomla! Ace
Joomla! Ace
Posts: 1318
Joined: Thu Aug 18, 2005 9:27 am
Location: San Jose, CA, USA
Contact:

[33]Library Installer

Post by pasamio » Mon Feb 18, 2008 6:06 am

Introduction
With the release of 1.5, Joomla! has a new method of organising the mess that was 1.0's "include" folder. The new "libraries" folder brings a Java like approach to organising the support files for the 1.5 framework and the third party libraries that Joomla! uses.

The problem with this is that whilst the system is great, there is no way for users to easily extend the common directory. Additionally the development of package installation methods also proposed for 1.6, the ability to build shared libraries into components and modules means that we can promote true object orientated development and reuse without having components reach into other components and modules reach into components to provide information.

Proposal
Allow for installable, upgradeable and uninstallable libraries including some of the sample core libraries.

Implementation
There exists a sample of how this could be achieved already (http://extensions.joomla.org/component/ ... Itemid,35/). It requires a location to store manifest files (for simplicity sake, this is stored in a different directory to the actual libraries) and an installation adapter to install the files. It also has a generic list component to manage installed libraries.

Impacts
Users
Users are not impacted as this would be another tab in the install/uninstall list and would integrate into the universal installer.

Third Party Extensions
Third party extensions are not impacted by any of these changes but can take advantage of the feature.

Performance
This is only done at install time or when viewed in the administrator. This has little impact on performance.
Sam Moffatt
Updater, Installer and Authentication Systems
JoomlaCode Backend Systems
Pie.

User avatar
H13
Joomla! Ace
Joomla! Ace
Posts: 1545
Joined: Sun Dec 10, 2006 6:39 pm
Location: Czech Republic
Contact:

Re: Installing or Upgrading components, ...

Post by H13 » Mon Feb 18, 2008 10:18 am

willebil

Great! Thank you for your info...

Jan
- Phoca Cart - Joomla eCommerce App - https://www.phoca.cz/phocacart
- Phoca Gallery - powerful image gallery
- Phoca Restaurant Menu - https://www.phoca.cz/phocamenu
- Phoca Download - download manager for Joomla

Jonathan Cameron
Joomla! Apprentice
Joomla! Apprentice
Posts: 34
Joined: Wed Sep 12, 2007 7:55 pm
Location: Pasadena, California

Re: Simplify installation of multi-part extensions

Post by Jonathan Cameron » Mon Feb 18, 2008 6:32 pm

Sam,

Yes, what I would like to see is the functionality of PackageManager incorporated into the Joomla core.

Thanks!

-Jonathan

RoscoHead
Joomla! Explorer
Joomla! Explorer
Posts: 318
Joined: Mon Jul 30, 2007 11:01 pm
Location: Melbourne, Australia
Contact:

Re: Installing or Upgrading components, ...

Post by RoscoHead » Mon Feb 18, 2008 11:39 pm

A component can be "upgraded" if the <install> tag in the install XML has an attribute method="upgrade". I believe all this does is skip the checks for existing files/directories, but it does allow a component to be upgraded without having to uninstall/reinstall.

ROSCO

User avatar
masterchief
Joomla! Hero
Joomla! Hero
Posts: 2247
Joined: Fri Aug 12, 2005 2:45 am
Location: Brisbane, Australia
Contact:

Re: Installing or Upgrading components, ...

Post by masterchief » Tue Feb 19, 2008 9:15 am

I just want to point something out: that "upgrade" management and "package" management are two separate topics. They are certainly related but the differences in implementation are profound.

I like the simplicity of the initial proposal because it covers most of the bases that the regular 3PD would come across in the Joomla!-verse. For the dev's that need more, you can actually do that now if you know how (it's a bit of work but can be done).

I like the idea of supporting the <upgrade> tag. It could act the same as the <install> tag but disabling the "does this already exist" checks. You could really go to town with dependency checks, upgrade options in the xml, etc, but realistically this can all be supported in an "upgrade.php" file that is provided by the 3PD.

My thoughts for the upgrade tag would be this. The installer:

* unpacks the file as normal
* parses the XML file
* determines that it's an upgrade file
* looks for a special "beforeUpgrade" file - this would be used by the developer to do any dependency checks that are required. Returns a JException object (or an array of Exceptions) or true
* copies the files to the appropriate locations
* looks for a special "afterUpgrade" file and runs it

Then hopefully viola! We are upgraded.

beforeUpgrade could be used to backup tables, prepare rollbacks, etc, at the discretion of the developer. Possibly we need some helper methods to make it easy - dunno.

I think that would be a fairly simple approach and still leaves the 3PD with plenty of room to do their own thing during the upgrade process.
Andrew Eddie - Tweet @AndrewEddie
<><
http://eddify.me
http://www.kiva.org/team/joomla - Got Joomla for free? Pay it forward and help fight poverty.

User avatar
H13
Joomla! Ace
Joomla! Ace
Posts: 1545
Joined: Sun Dec 10, 2006 6:39 pm
Location: Czech Republic
Contact:

Re: Installing or Upgrading components, ...

Post by H13 » Tue Feb 19, 2008 10:23 am

but realistically this can all be supported in an "upgrade.php" file that is provided by the 3PD
Hi, the problem is not an upgrade script as I said... It is very easy to do an upgrade script...The problem is that before user wants to upgrade, he must uninstall the previous version. The correct behaviour is, if I uninstall some component, all data and tables will be removed from database (no 'pollution' of database by components which are not used). But if user wants to upgrade, the data and tables should be not deleted while uninstalling.(but it cannot manage some 3PD script because this script is removed while uninstalling before removing/keeping data in database)

The second problem is, why do e.g. two ZIP packages (one for installation - install tag in XML and one for upgrading - upgrade tag in XML). If you do some new version, you never know if user will install this version as new or if he will upgrade - so you must do two ZIP packages)

There can be two buttons (upload & install and upload & upgrade). If user wants to install, new tables will be created in database and new data will be copied into server disc. If user wants to upgrade, no new tables will be created (only old files will be overwritten and maybe new files will be added)... very easy for user, very easy for developer because he will publish only one ZIP package and user will decide if he install or upgrade...

The same happens while uninstalling (uninstall or uninstall because of upgrade)

There can be some problems too. E.g. if developer do new database table structure. User cannot run an upgrade script because upgrade script doesn't do anything with database but if developer change the table structure he must do the migration script anyway or there cannot be an upgrading of component, only new installing because of new database table structure...

Jan

User avatar
masterchief
Joomla! Hero
Joomla! Hero
Posts: 2247
Joined: Fri Aug 12, 2005 2:45 am
Location: Brisbane, Australia
Contact:

Re: Installing or Upgrading components, ...

Post by masterchief » Tue Feb 19, 2008 10:36 am

The Dev can do anything with an "upgrade" script. You can access the database object from within it - backup tables, modify schema whatever. Was that your concern?
Andrew Eddie - Tweet @AndrewEddie
<><
http://eddify.me
http://www.kiva.org/team/joomla - Got Joomla for free? Pay it forward and help fight poverty.

User avatar
willebil
Joomla! Guru
Joomla! Guru
Posts: 762
Joined: Thu Aug 18, 2005 12:06 pm
Location: Netherlands

Re: Installing or Upgrading components, ...

Post by willebil » Tue Feb 19, 2008 10:46 am

Upgrading itself as described here is pretty easy. But I would like to out forward two considerations:
* Dependency validation (this especially is important when you need to know from which version you updgrade, and per version the required actions can differ).
* Consider the situation the updated files are copied, but there is an error during execution of the update SQL. You then need to revert the situation like is done now during normal installation.

If you don't implement basic features for this, you will most likely have a lot of discussion when someone upgrades the extension.

RoscoHead
Joomla! Explorer
Joomla! Explorer
Posts: 318
Joined: Mon Jul 30, 2007 11:01 pm
Location: Melbourne, Australia
Contact:

Re: Installing or Upgrading components, ...

Post by RoscoHead » Tue Feb 19, 2008 12:05 pm

This is also partially related to my other suggestion here: http://forum.joomla.org/viewtopic.php?f=500&t=265668

ROSCO

User avatar
LocaLizeR
Joomla! Explorer
Joomla! Explorer
Posts: 331
Joined: Thu Sep 15, 2005 4:44 am
Location: Hungary
Contact:

Check add-ons for components during install/uninstall

Post by LocaLizeR » Tue Feb 19, 2008 3:15 pm

1. Summary
Joomla! supports complex extensions, including components, modules and plugins in a single project (like Joom!Fish).
Some 3rd party components have a smart installer and when they have associated modules and plugins, they will install them with the same process. The developers of the majority of the 3rd party components distribute the associated modules and plugins separately and they should be installed separately, however, they belong to the same component.
And this is the starting point of the problem. When you uninstall a component, for which you installed such optional modules and plugins as a separate process, may be left on the server by the admin and become unnecessary.,

2. Goals
2.1 When the administrator uninstalls a component, Joomla! checks whether optional extensions were installed.
2.1 When the checking process returns any result, the user is prompted to uninstall the separately installed add-ons.
2.2 When a module or plugin is installed first belonging to a component, Joomla! should check it and allow to complete the process, when the component is installed.

3. Affects
Awaiting community comment.
Jozsef Tamas Herczeg // Member of the Hungarian Joomla Translation Team :: Follow me on Twitter: @jtherczeg
:: "Do not give fish to the hungry man teach him how to fish instead" ::

User avatar
H13
Joomla! Ace
Joomla! Ace
Posts: 1545
Joined: Sun Dec 10, 2006 6:39 pm
Location: Czech Republic
Contact:

Re: Installing or Upgrading components, ...

Post by H13 » Wed Feb 20, 2008 8:50 pm

It seems like the system I described will not work, because if you uninstall the component before upgrading, Joomla! remove all menu link data to the component. So after upgrading, all menu items to the component are destroyed ... :-(
- Phoca Cart - Joomla eCommerce App - https://www.phoca.cz/phocacart
- Phoca Gallery - powerful image gallery
- Phoca Restaurant Menu - https://www.phoca.cz/phocamenu
- Phoca Download - download manager for Joomla

pasamio
Joomla! Ace
Joomla! Ace
Posts: 1318
Joined: Thu Aug 18, 2005 9:27 am
Location: San Jose, CA, USA
Contact:

Re: Installing or Upgrading components, ...

Post by pasamio » Thu Feb 21, 2008 2:38 am

I'd much rather take the approach that if there is an upgrade tag pointing to say an upgrade.php file and the component is already installed then I would like it to switch to upgrade mode and let the upgrade.php file take control. It would have access to everything the installer knows and it can then do its own database checks, upgrades and file copies and removals itself. Instead of trying to codify the logic into the installer, which we're going to miss something, we give it to the developer. If they need dependency checking then they can provide the logic. You simply upload a component, if its already installed and it has a <upgrade> tag then it does the install stuff. You don't need special patch packages (unless you want to) and you can use full packages to provide the functionality.

So a full package can do a regular install like we know and love now but it can also handle the upgrade. The user downloads the same package and uploads it and it works regardless. Adding that amount of logic isn't too hard.

Adding dependency checking would be nice, but putting stuff like database upgrades into the XML file or installer to handle is going to lead to problems. Look at what Debian does. Dependency checking and package acquisition is all the installer system handles, the rest is handled by scripts, post-install, pre-install, upgrade, etc.
Sam Moffatt
Updater, Installer and Authentication Systems
JoomlaCode Backend Systems
Pie.

RoscoHead
Joomla! Explorer
Joomla! Explorer
Posts: 318
Joined: Mon Jul 30, 2007 11:01 pm
Location: Melbourne, Australia
Contact:

Re: Installing or Upgrading components, ...

Post by RoscoHead » Thu Feb 21, 2008 2:59 am

pasamio wrote:I'd much rather take the approach that if there is an upgrade tag pointing to say an upgrade.php file and the component is already installed then I would like it to switch to upgrade mode and let the upgrade.php file take control. It would have access to everything the installer knows and it can then do its own database checks, upgrades and file copies and removals itself. Instead of trying to codify the logic into the installer, which we're going to miss something, we give it to the developer. If they need dependency checking then they can provide the logic. You simply upload a component, if its already installed and it has a <upgrade> tag then it does the install stuff. You don't need special patch packages (unless you want to) and you can use full packages to provide the functionality.
I agree, I think the current method="upgrade" attribute is not the best way to go, as it kind of forces the developer to create 2 different install packages.
pasamio wrote:So a full package can do a regular install like we know and love now but it can also handle the upgrade. The user downloads the same package and uploads it and it works regardless. Adding that amount of logic isn't too hard.

Adding dependency checking would be nice, but putting stuff like database upgrades into the XML file or installer to handle is going to lead to problems. Look at what Debian does. Dependency checking and package acquisition is all the installer system handles, the rest is handled by scripts, post-install, pre-install, upgrade, etc.
Certainly it can, but aren't computers supposed to make life easier for everyone, including developers? ;)

And you bring up another great idea - package acquisition. Wouldn't it be great if you don't have the correct version of com_xyz, it is automatically downloads and installs for you (after asking of course)? There's already an extensions repository, it could be expanded to work like CPAN...

ROSCO

mreiter
Joomla! Apprentice
Joomla! Apprentice
Posts: 24
Joined: Fri Sep 22, 2006 9:06 am

Re: Installing or Upgrading components, ...

Post by mreiter » Thu Feb 21, 2008 9:55 am

First of all I think this subject is very important to improve usability of the components. I would like it to be included for 1.6.
I agree, I think the current method="upgrade" attribute is not the best way to go, as it kind of forces the developer to create 2 different install packages.
Good idea! I just wonder if there could be a mechanism to kind of oblige developers to write the upgrade logic when one chooses "install". If it's not the case it will be simply like it's by now: every component does it it's own way. So if there is no way to oblige the developers then I would stick to the original idea: provide an "upgrade" button.

User avatar
willebil
Joomla! Guru
Joomla! Guru
Posts: 762
Joined: Thu Aug 18, 2005 12:06 pm
Location: Netherlands

Re: Installing or Upgrading components, ...

Post by willebil » Thu Feb 21, 2008 10:18 am

And you bring up another great idea - package acquisition. Wouldn't it be great if you don't have the correct version of com_xyz, it is automatically downloads and installs for you (after asking of course)? There's already an extensions repository, it could be expanded to work like CPAN...
This exactly is what j!package was targeting at...it is all been designed once, but implementing this is a huge undertakement. Suggest we target at upgrade logic from the installer for 1.6, this already is challenging enough to create an ACID upgrader. Once this is in place, the work on linking it to JED (or other directories) can be targetted at later releases.

User avatar
H13
Joomla! Ace
Joomla! Ace
Posts: 1545
Joined: Sun Dec 10, 2006 6:39 pm
Location: Czech Republic
Contact:

Re: Installing or Upgrading components, ...

Post by H13 » Thu Feb 21, 2008 12:01 pm

Some insteresting thing about <install method="upgrade" ...>

I have used this tag + method and made 3PD upgrade script, so if user installs (upgrades) the component:

1. all component files will be copied (if there are some on the disc, they will be overwritten)
2. After this action, it goes to install.component.php script where user can choose:
a) install - in this case, SQL query will be executed (new tables will be created). User gets message about sucessfully installing (if there is some SQL error he gets message about SQL error ... good for developer info)
b) upgrade - in this case, nothing will happens, no SQL query will be executed. User gets message about sucessfully upgrading (there is a check if the database tables exists, if not, he gets SQL error message too).

User doesn't need to uninstall the previous component (thanks to upgrade method) ...
This istallation (upgrade) process is very easy and can be used if the database table structure is changed... Just get information in install.component.php script about table from database and do changes...

It works great and can be used in 1.5 but there is someting what is wrong for me. If user upgrades this way and has SEF enabled, every menu link to the component will be invalid ( index.php?Itemid=20&option= ). If he goes to menu link and save this link, it will be repaired...
If the SEF is disabled, everything works great...

Maybe the method upgrade should stop from destroing the SEF url link too... (or maybe I do something wrong :-( )

Jan
- Phoca Cart - Joomla eCommerce App - https://www.phoca.cz/phocacart
- Phoca Gallery - powerful image gallery
- Phoca Restaurant Menu - https://www.phoca.cz/phocamenu
- Phoca Download - download manager for Joomla

jflaker
Joomla! Fledgling
Joomla! Fledgling
Posts: 1
Joined: Sat Feb 23, 2008 2:02 am

Module/componnent/mambot install from web

Post by jflaker » Sat Feb 23, 2008 2:22 am

Install site components, modules and mambots from their source on the web.

The process of installing additional features can be simplified by being able to pull the module directly from the web into the site installer.

While I see I can install from url, it would be nice to see a list of things available to install by clicking. The selection can possibly be filled by an RSS feed an AJAX fill of the URL.

This suggestion is very high level, leaving plenty of room for thought.

VanCrey
Joomla! Apprentice
Joomla! Apprentice
Posts: 22
Joined: Mon Dec 17, 2007 10:57 pm

Re: Library Installer

Post by VanCrey » Sun Feb 24, 2008 12:39 pm

Hello,

thats also one idea, that I had. Some more comments

Extension

1. The "Library" should be installed over the Installer Mechanism.
2. The "Library" should be able to provide in the "<install>" xml a list of dependencies. If the dependency is not given, the Installation should be fail
3. In all other installable elements (template, component, module, plugin) it must be also possible to define "dependencies". The defineable dependencies should be not only restricted for libraries!
4. It should be not possible to uninstall a extension, as long as there is a dependency which points to the extension.

Result

Its possible to get a better control about all the dependencies to ensure a more stable Joomla System

pasamio
Joomla! Ace
Joomla! Ace
Posts: 1318
Joined: Thu Aug 18, 2005 9:27 am
Location: San Jose, CA, USA
Contact:

Re: Library Installer

Post by pasamio » Sun Feb 24, 2008 1:45 pm

1) This is what the sample linked extension already does once installed.
2-4) Dependencies is something I believe Wilco will look at with his JPackage project. Dependencies are far greater than libraries as a module may also depend on a component and the tables it provides. Libraries provide a slightly more critical role as they fill in what has been previously dumped into either components or plugins/mambots (which really sucks). Dependencies are a separate issue to this and I don't want to mix up the complex topic of dependencies in with this one as that is another problem to solve. It is useful to prevent people doing stupid things that break their Joomla! site (either due to sheer curiosity or not knowing and understanding the ramifications of their actions, e.g. people wondering what happens when they disable the Joomla! authentication plugin). Additionally something like the core framework won't be uninstallable but might be upgradeable ;)
Sam Moffatt
Updater, Installer and Authentication Systems
JoomlaCode Backend Systems
Pie.


Locked

Return to “Accepted - Archived”