Q1) NoNumber extension use a special installer that is a temporary component that is installed to install the real component later. One the real component is installed, the temporary component is removed.
So it is not possible to re-install the NoNumber extension from a slave site if you don't first install the "installer" component in the master and make sure that it remains present (not deleted).
JMS just verify the joomla version that is present in the installed directory and when the installed directory is deleted (case of NoNumber), it is impossible to retreive the version number.
This extension use an experimental installer that has limitation. So contact NoNumber in case of problem with their installer.

Q2) The concept of JMS is to share the same PHP code of joomla and also of all their extension installed.
If an extension can not be re-installed in a slave site due to specific installer this must be analyzed on case by case as this can be specific to the extension.

Q3) I don't know.

Q4) NO. You must contact each extension to know if they proceed with update or upgrade.
This is not an information that we have. Only the developer of the extension know or perhaps publish in the release not if the new version is an update or an upgrade.

Q5) Copy a directory will not resolve the DB layout issue.
If you copy a directory, this also mean that you will have to maintain the synchronization of the files and folders manually. So we don't think this is a good idea.

Option 3, we don't know all the specific code written by each extension to proceed with the upgrade of the DB layout. Only the extension knows what must be performed to modify the DB layout structure. This is the reason why you have to re-install it into a slave site to let the extension proceed as usual and overwrite the existing PHP code with exactly the same version as previously installed. As the PHP code is re-installed over the current one, JMS just verify that you re-install the same version.

Hi Edwin,

OK this is becoming clearer now.

Just to check my understanding:

Situation 1: When we see a message in the JMS Tools that says "Install from Master" (with a minus icon) this means that JMS is installing the extension based on the installation pattern that is understood by JMS (known as the Definition).

In the above, the extension may be defined in JMS but this is only for the first installation of the current extension. If there is a subsequent upgrade to the extension then JMS Tools cannot be used because the Definition in JMS may not apply to the new version of the extension (and the definition would need to be re-analysed and updated in JMS). This is the reason why the Upgrades needs to be installed from the Slave.

Question 1: Is the above understanding correct?

Situation 2: When we see a message in JMS Tools saying "Define From Master" (with an x icon) then this means that JMS does not have an installation definition and does not know how to install the extension so it does not follow any pattern, it just copies the database tables and creates the relevant symbolic links to the files exactly as they exist in the Master.

Question 2: Is the above understanding correct?

Question 3: Would it be possible to store the entire extension installation package in a directory in the Master and use the JMS Tools menu to run the installation in the Slave sites from the original ZIP. So in this case JMS Tools just eliminates the step to login to each slave site. Wouldn't this also eliminate the need to define every extension in JMS (because the installation or upgrade pattern is already contained in the package)?

Question 4: Regarding an upgrade from an extension in a Slave, how would we know if the extension upgrade has failed in the database (due to the situation arising from the version number already upgraded in the master)? Is the only real way to compare the database tables?

Looking forward to hearing your responses.

Kind regards.

Q1: Yes JMS tools does NOT update the layout of the MySQL table when the upgrade of an extension require this layout modification.
"Installation from the Master" mean that the MySQL tables present in the master are copied into the slave site.

Q2: "define from master" mean that just the definition of the extension is defined in the slave site to appear in the menu of the slave site but the table required for this extension are NOT created as JMS does NOT know them.
So your understand is INCORRECT.
It does NOT copies the database tables as they are unknown.

Q3: Installation from a directory is something that you can user in the Joomla extension manager. Trying to do that from the JMS tool require a develop that prohibitive as a solution already exists when you login in the back-end of the slave site.

Q4: I know it is not easy to know if an extension perfor an update or an upgrade as this is not an information frequently published by the author of the extensions.
Personnally, before proceeding to the installation of an update, I always test it on a local environment where I have duplicated the production environment.
So that I can see if the extension has proceed with an update or an upgrade when I compare the DB table structures.
So when you have a "live" environment, we thing that test the update/upgrade offline is a good practice. This is the method that we are using for our websites.

Hi Edwin,

Thanks for your detailed responses.

Regarding Q3, I am interested to explore the possibility of installing the extension ZIP package from the Master Tools Menu directly into the slave sites (and propogating to children).

Do you agree that this would save significant time? We could avoid logging into each slave site to access the extension manager - especially if we have hundreds of slave sites.

Can you please confirm if this is possible via further development of JMS?

What are the key issues that would stop this feature? (I know we would first need to test each extension package on a staging environment to ensure the upgrade works however after this process are there any other issues?)

Thanks and regards.

I don't see how you will be able to use the Zip for the installation in the slave site without to login in the back-end of the slave site.

To perform an upgrade, you need that the standard joomla installer is called from the slave site to let execute the specific PHP code from the slave site.

So I don't see how you can do that otherwise.

For me, what you are describing should not work.
All I can suggest is that you test your idea.

Hi Edwin,

I've been looking into the Joomlart Extension Manager. It seems to contain a number of features that would be required for my suggestion (i.e. a repository for extension packages and also a function to compare version to see what has been updated).

Have you studied the Joomlart Extension Manager component to see if it can help enhance JMS?

Perhaps there is a way to adapt it's functions to assist with the slave site upgrade process.

Please let me know what you think about this.

Kind regards.