Enable all Modules before upgrading might be a good idea.

I am preparing a rather important update from 4.4 to 5.4 and stumbled upon a fact which I did not know but would like to share.

As of 5.1 you can disable modules in the backend which you don't need. I do it on every small business site where news, forums, events are not needed.

Now when you have a 5.1 site and have for example news, forums, events module disabled and upgrade that site to 5.2 then 5.3 then 5.4 the disabled modules  will not get upgraded.

So when you then activate on of these modules they are still in a 5.1 state. In order to fix this you must deinstall the module and install it again. Then they will be upgraded.

I have not checked this myself so this information might be considered wrong until otherwise proven :-) 

I am simply going to activate all modules before upgrading to be sure to be on the latest version. 

But it might be a good idea to check your App_Data/Sitefinity/Configuration/System.config where the module information is stored.

Markus

Can someone from Telerik please advice whether or not modules should be enabled while upgrading, to prevent future issues?

Hi Arno,

We cannot see any problems if some modules are not enabled while upgrading. Of course, if the module is disabled while upgrading Sitefinity, the module will not be loaded and will not start its upgrading process. However, it will be upgraded on its activation.
As Markus mentioned the information about modules is stored in ~/App_Data/Sitefinity/Configuration/SystemConfig.config:

Actually, there is a way to start a new site without even installing some of the modules. For example, if you want a new project without News, Forums and Events modules, you can place the following SystemConfig.config in ~/App_Data/Sitefinity/Configuration before initializing the site(start up wizard):

<?xml version="1.0" encoding="utf-8"?>

<systemConfig>

    <applicationModules>

        <add startupType="Disabled" name="News" />

        <add startupType="Disabled" name="Events" />

        <add startupType="Disabled" name="Forums" />

    </applicationModules>

</systemConfig>

In this case, the disabled modules can be installed later through the Modules management screen. However, if you want to completely remove those modules, so they will not appear in the Modules screen, you can add the the following SystemConfig.config:

<?xml version="1.0" encoding="utf-8"?>

<systemConfig>

    <applicationModules>

        <remove name="News" />

        <remove name="Events" />

        <remove name="Forums" />

    </applicationModules>

</systemConfig>

Hope this is helpful.

Thanks for that Vlad!

Dear Vlad

My concern was that the upgrades might sometimes or allways make changes in the database as well and if you disable a module in 5.1 and then upgrade to 6.5 for example some breaking changes might accure. 

That's why I thought having all modules upgraded all the time might have been a good idea.

Markus

Thank you for the clarification Markus,

I think I understand your concern. It is coming from the fact that we support upgrades only from previous version, i.e. instead of upgrading from 5.1 directly to 6.0, our recommendation is to upgrade 5.1 -> 5.2 -> 5.3 -> 5.4 -> 6.0. But It is, because we test only this upgrade path, otherwise we will spend months in testing. However, having in mind that the upgrading process is sequential, in theory, shouldn't be a problem to upgrade from any version to the latest. In my personal opinion, it is even better (I have upgraded a site from 4.0 to 6.0 without any upgrade errors and problems after that). Maybe, the recommendation would be 'try to upgrade to the latest directly, if fail - go through the versions in the middle'.

Yes, a module upgrade might make changes to the database, but these changes should be related only to the upgraded module and should not affects the other parts of the system, otherwise this have to be considered as a bug in the module. This is the idea of having decoupled modules.


Kind regards,
Vlad
the Telerik team

Dear Vlad

Some other post make me come back to this.

If I leave a module on 5.0 and upgrade all other to 6.0. Now when 6.1 comes out I would want to start using the old 5.0 module wouldn't that module be taken streight from 5.0 to 6.1 -> skipping the recomended upgrade pathes?

And if yes this would not have been tested by telerik and therefore we should enable all modules on update not?

Markus

Hello Markus,

The recommended (tested) upgraded path is for the whole system. Each module, if implemented correctly, should not depend on the system and the system should not depend on the module. So, there shouldn't be a difference if you follow or not the upgrade path for a particular module.
Actually, I think, it is even better not to upgrade the module, if you are not going to use it in the upgraded site. I can argument myself with the following example: let say that a module has an upgrade code from 5.0 to 6.0 and after 6.0 release we find a bug in this upgrade code, we can fix it in 6.1, but if the module is already upgraded to 6.0, it will not take benefit of the fix. I am not sure if we have had such case, but it is possible. In opinion, upgrading disabled modules is a good idea only when they will be used in the upgraded site.


Regards,
Vlad
Telerik

Dear Vlad

Thank's for the clarification.

Markus