Upgrading your module to be Orchard 1.8 compatible

Tags: Orchard 1.8, Orchard, upgrade, development

So what should I do with my module to make it 1.8 compatible? Although 1.8 is not yet here (1.7.2 just released) it's not too early to deal with this question, since without intervention your modules won't even compile with the latest (soon-to-be 1.8) Orchard source.

  • Since Orchard 1.8 targets the .NET framework 4.5 if your module runs on 4.0 it won't compile (given that it references any other project in the Orchard solution, what it most possibly does). Thus, you have to re-target your module to .NET 4.5 (or 4.5.1 even if you need it) from under its project properties/Target framework. This will possibly also create an App.config file what you need to remove (see this SO post).
  • Remove the Web.config file from the Views folder as it is not needed.
  • Overwrite the root Web.config of the module with the Web.config found in any of the built-in modules' root of this fork by Erik Oppedijk (or if you're reading this from the future where the fork is already incorporated into the main source, you can just use it instead - and BTW congrats, time traveller!). This will restore the broken IntelliSense for Razor templates.
  • Remove the following sections from static folder Web.configs (e.g. Script, Styles, Content):
    <appSettings>
        <add key="webpages:Enabled" value="false" />
    </appSettings>
    <system.web>
        <httpHandlers>
            <!-- iis6 - for any request in this location, return via managed static file handler -->
            <add path="*" verb="*" type="System.Web.StaticFileHandler" />
        </httpHandlers>
    </system.web>
  • If you're using VS 2012 IntelliSense in MVC 5 Razor templates won't work at all. To add IntelliSense support you should install ASP.NET and Web Tools 2013.1 for Visual Studio 2012. With VS 2013 you won't experience any issues.
  • Change OrchardVersion to 1.8 in the Module.txt file.
  • Finally: make use of 1.8's awesome paradigm shift, The Shift: we now store every content part data in the InfosetPart too: this is a huge performance boost. Read Bertrand's blogpost on how to shift your modules. Also the Orchard Dojo Library has some snippets for the infoset Store()/Retrieve() calls (look for opropstoreretrieve and oproprecordstoreretrieve) so you don't have to write them.
    Remember that most of the time you can remove import/export implementations from content part drivers as infoset data is automatically imported/exported. This is not true for content parts that you not explicitly migrate but let migrate itself over by time.
  • Also because of The Shift : there are no more site settings part records and after you migrate your site settings data with the Upgrade feature all of the site settings tables will be gone too. This means that if your module fetched site settings records (what it really shouldn't) or even the tables directly with SQL (what it REALLY shouldn"t) then you'll have to change to access the same data in the corresponding content parts instead.
  • And BTW: carefully test your module. There are supposed to be no major breaking changes but a lot of work has been done, so who knows...

The very same steps are required for themes too.

If you'd like to also read about how to migrate data from records to the infoset, read the follow-up post.

So let's shift to fifth gear! (Ehe, get the pun, haha... Oh, OK.) Happy shifting!

No Comments

Add a Comment