+1-888-365-2779
Try Now
More in this section

Forums / General Discussions / Enable all Modules before upgrading might be a good idea.

Enable all Modules before upgrading might be a good idea.

9 posts, 0 answered
  1. Markus
    Markus avatar
    2763 posts
    Registered:
    25 Nov 2005
    07 Mar 2013
    Link to this post

    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

     

     

  2. Arno
    Arno avatar
    249 posts
    Registered:
    08 Sep 2010
    02 May 2013
    Link to this post
    Can someone from Telerik please advice whether or not modules should be enabled while upgrading, to prevent future issues?
  3. Vlad
    Vlad avatar
    498 posts
    Registered:
    15 Jul 2016
    07 May 2013
    Link to this post
    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:
    <systemConfig>
        <applicationModules>
            <add version="5.3.3900.0" startupType="Disabled" name="Blogs" />
            ...
        </applicationModules>
    </systemConfig>

    When modules are installed or upgraded, they update their versions in the SystemConfig. Every time a module is initialized (if it is enabled), Sitefinity checks if the current module version is greater than the persisted one. If so, Sitefinity call the Upgrade method of the module. The module upgrading process is independent of Sitefinity and other modules upgrading.
    That's why we do think that enabling all modules on upgrade could fix something.

    Maybe, if you have a module which is temporary disabled and you consider to enable it later on the production server, only in this case, its recommended to enable the module while upgrading.

    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.

    Regards,
    Vlad
    the Telerik team
    Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
  4. Arno
    Arno avatar
    249 posts
    Registered:
    08 Sep 2010
    07 May 2013 in reply to Vlad
    Link to this post
    Thanks for that Vlad!
  5. Markus
    Markus avatar
    2763 posts
    Registered:
    25 Nov 2005
    07 May 2013 in reply to Arno
    Link to this post
    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
  6. Vlad
    Vlad avatar
    498 posts
    Registered:
    15 Jul 2016
    09 May 2013
    Link to this post
    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
    Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
  7. Markus
    Markus avatar
    2763 posts
    Registered:
    25 Nov 2005
    04 Jun 2013 in reply to Vlad
    Link to this post
    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
  8. Vlad
    Vlad avatar
    498 posts
    Registered:
    15 Jul 2016
    05 Jun 2013
    Link to this post
    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
    Do you want to have your say in the Sitefinity development roadmap? Do you want to know when a feature you requested is added or when a bug fixed? Explore the Telerik Public Issue Tracking system and vote to affect the priority of the items
  9. Markus
    Markus avatar
    2763 posts
    Registered:
    25 Nov 2005
    05 Jun 2013 in reply to Vlad
    Link to this post
    Dear Vlad

    Thank's for the clarification.

    Markus
9 posts, 0 answered