Hi Edwin,

I just purchased MultiSites and I am testing it for a project which involves one central site and 10+ regional sites. So far testing is ok, yet I have some questions about future upgrading situations. I could not find any documentation on these but maybe I'm wrong; if so, please tell me.

Upgrading Joomla - no, I do not mean from 1.5 to 1.6+ but just an ordinary upgrade from, let's say, 1.7.3 to 1.7.4. How does this work with MultiSites? Especially regarding the fact that MultiSites is said to be, in a way, a core hack?

Upgrading MultiSites itself - does this have any specific issues?

When it comes to upgrading and managing components, modules and plugins, it seems to me that in the Tools panel, actions can be made only for one slave site at a time. If this is correct, this seems a bit inefficient when managing 10+ identical slave sites. Or can I avoid this by making a template? I did not take time to do that.

I hope you can help me.

With kind regards,
Frits Jongbloets

Let remember some definitions.
Update generally means that you have bug fixes and no DB layout modification.
Normally an update is identified with the build number (the 3 part of the number)
(ie. JMS 1.2.75 ro 1.2.76)

The upgrade generally mean that you have a change in the functionality and that the DB layout is modified. This is the release number that is in second position (ie JMS 1.2.x to 1.3.x)

When you have incompatibility between version, this is reflected with the major number.
In general you have a migration operation to do to import the data from an older version.
(ie. product Version 1.x.y to Version 2.x.y)


Joomla does not apply those rule and gave their own definition that is different of the commonly adminitted definition.
Sometimes, inside a build they perform an upgrade and change the DB layout.

So to reply to your question, the key element is to arrive identifying if the update perform by joomla is a real update or an upgrade.
If this is an update, that mean that only the joomla PHP code is updated like you have that with joomla 1.5.
Now with Joomla 1.7, when you click on the "update" button, you may have an upgrade without any mention of that.
The upgrade require to apply the DB layout modification in each slave site DB.

Read the user manual chapter 8 that explain again the difference between update and upgrade.

Hi Edwin,

Regarding the slave site upgrade using JMS I have a few additional questions.

I understand that we sometimes do not know if the database tables are changed with an update to an extension so it is probably better to treat all updates like they are upgrades.

I'm trying to understand all the options and limitations to upgrade the slave sites:

Option 1: Install upgrade into master site. If tables are different then the Site Manager tab will display a 'refresh tables' icon and then we need to click into each slave site and re-save the template. The limitation is that this could become difficult if you have hundreds of slave sites and could also cause trouble if you are using dynamic variables in the site template.

Option 2: Access the administration of each slave site and install the extension through the slave site installer. The limitation is that this is very time consuming to access each slave site if you have hundreds of sites.

Option 3: Install the extension into the Master site. Go into the 'Tools' menu and click to update all the slave sites with the extension. The user can select to simply upgrade the extension and the tables (the config in the slave will remain the same) or 'overwrite' the config with the config from the extension in the master. The limitation here is that JMS Multi Sites does not contain all the tables for all extensions so you would need JMS to write some type of custom patch to include your extension in the Tools upgrade functionality.

Have I correctly understood the options above and their limitations?

What is missing from these options?

Have I missed any limitations?

Option 1 to refresh the slave site can not be used for the upgrade as this does not touch the current table that may have a different layout after an upgrade.
The refresh icon just display that you have a difference in the number of tables present in the slave site and that perhaps you need to take an action to update or upgrade. You can use the refresh is this is just an update.

Option 2: is the only option available today for the upgrade and assume that the extension is able to correctly upgrade the MySQL table layout.
Some extension fails to perform the upgrade and some succeed.
So this depends on each extension themselves.

Option 3, When an extension share its content, you can use the JMS Tool menu to uninstall and re-sharing the extension.
If you uninstall an extension with content inside, the uninstall will delete the table and you will lose the content.
When an extension is not defined in JMS, you have to use the option 2.

The main limitation concern the ability of an extension to perform its upgrade correctly. Some (like JomSocial) are doing that very well and they save inside the DB a kind of layout version. Some other extension use the current verion of the extension to compare with the new one to determine the algorithm of the upgrade. In this case, the upgrade is not performed as in a slave site you can only install an extension with the same version number as the master. So identical version number will result by no upgrade performed by the extension.

Hi Edwin,

Option 1: OK I understand this.

Option 2: This is actually causing me some concern. I was aware that we needed to install upgrades directly into each slave site however I had no idea that sometimes this does not work at all.

Q1: I can see this for example with NoNumbers extensions. Is the limitation regarding version numbers imposed by JMS or Joomla? If it is imposed by JMS why can't we override this?

Q2: What are our options if an extension does not upgrade via the slave install? Does this mean JMS needs further development or is this something that will never be overcome?

Q3: Now that we are into Joomla v2.5+ I have noticed that many developers are offering live updates via an API key or via Joomla upgrade (such as Easy Blog, JCE, Rockettheme etc.) Does this make any difference to resolving this issue? Is it safe to use this feature with JMS?

Q4: Have you published a list of extensions that are upgradable/un-upgradeable with JMS?

Q5: Could I COPY the extensions directory in the JMS template instead of using the symbolic link. Would this solve the issue?

Option 3: I still don't understand why the JMS Tools menu cannot be used to install upgrades into slave sites (and propogated to their children) if the extension is not shared. If the extension upgrade is installed in the master why does the 'install from master' not work in the same way as when the extension did not exist in the slave? Why can't JMS install the extension package and let the extension installation work as if it was being re-installed and/or upgraded in the slave directly from the slave admin?

We all understand that there are limitations at the moment but it's important for us to know if there is a path to upgrading the slave sites en mass (and at all) in the future. In the short term we really need to know what extensions to avoid.

Thanks and regards.

Hi Edwin, just a quick bump regarding the questions in my previous post.