We’ve seen that installing Orchard themes and modules simply requires copying files into well-known directories. If we were to create a second Orchard site, we could simply copy our modules and theme into the Modules and Themes directories under the Orchard.Web project for the new site. However, we’ve already seen a better way to share modules—the Orchard Gallery.
Though the Orchard team has supplied the Gallery with many useful modules, most of the nearly 400 packages (as of the writing of this book) have been contributed by Orchard users. Though we created our theme and modules to satisfy the needs of the Daisy’s Gone website, there’s nothing that would prevent us from sharing our creations with the Orchard community.
Note
Our theme and modules were intentionally kept simple. It’s arguably reasonable to share a module or theme with limited functionality. Just be sure not to call it a 1.0 product! In fact, sharing a pre-1.0 version is a good way to help shape your project by getting early feedback.
We’ll first package up our theme. “Daisy’s Theme” isn’t likely to
win any UI contests, but you never know who might find our minimalist
approach to design appealing. To start the process, we’ll return to the
command line and enable the Orchard.Packaging module:
orchard> feature enable Orchard.PackagingEnabling features Orchard.PackagingPackaging was enabled
Once this module is enabled, we’ll be able to use it to create, install, or uninstall packages. Orchard uses the Nuget package format (.nupkg files), which like most package manager formats, are basically just ZIP files with some metadata included. Let’s first create our theme’s package file:
orchard> package create DaisysTheme C:DevOrchardPkgPackage “C:DevOrchardPkgOrchard.Theme.DaisysTheme.1.0.nupkg” successfully created
If you browse to the directory C:DevOrchardPkg in Windows Explorer you’ll see the packaged theme.
If you want to take a look inside to see what’s been packaged up, simply
change the extension from .nupkg to
.zip. After that, you’re able to
explore the files. You’ll see some metadata files along with the contents
of our theme.
Recall that the “DaisysTheme” theme was based on the “TheThemeMachine” theme. The template files for that theme weren’t packaged up with ours, so anyone who installs our theme will need to have that base theme installed. Fortunately that’s a standard theme, but we can see that dependencies aren’t automatically handled in theme packaging. Also notice that our alternate templates were also packaged for us.
Packaging up our two modules will be a similar task. We’ll again use
the command line to create Nuget packages. Let’s start with our Contrib.PlacesField module:
orchard> package create Contrib.PlacesField C:DevOrchardPkgPackage “C:DevOrchardPkgOrchard.Module.PlacesField.1.0.nupkg” successfully created
I made note of the fact that our modules shouldn’t be considered version 1.0, but from the package name Orchard seems to think otherwise. What’s actually happening is that the command to create the package is using the Theme.txt and Module.txt metadata files that we modified when creating our theme and modules.
If you thought to set a proper version while working on those
chapters, your package names more accurately reflect the state of our
extensions. After making sure we have alpha-appropriate version numbers,
when we create the JWPlayer module
package the filename looks right:
orchard> package create JWPlayer C:DevOrchardPkgPackage “C:DevOrchardPkgOrchard.Module.JWPlayer.0.1.nupkg” successfully created
Now that we’ve packaged our modules, we have two choices for
installing them on other sites. If you wish to share with the community,
you’ll need to create account on the official Orchard Gallery site located
at http://gallery.orchardproject.net/. Once you have
that account, you can upload and manage your theme or module. Once in the
gallery, you can download and install your modules on any of your Orchard
sites just as you did with modules such as Bing.Maps.
If your development efforts were paid for by a client, or you’ve
created a business use module that shouldn’t be exposed in a public
gallery, you can still make use of the packages that we’ve created. We’ll
again return to the command line where we’re able to install and uninstall
modules from .nupkg files. In a new
site, simply run the install
command:
orchard> package install Orchard.Module.JWPlayer
C:DevOrchardPkg Orchard.Module.JWPlayer.0.1.nupkgYou could also install your packaged themes and modules using the admin dashboard. If you click either “Modules” or “Themes” on the admin menu and select the “Installed” tab, you’ll find links to “Install a module from your computer” and “Install a theme from your computer,” respectively. Simply browse to the .nupkg file and select it to install it. Once installed, enable it when prompted.
Now that we know how to package up our extensions, we can consider
how and to where we’ll deploy our Orchard sites. In general, deploying an
Orchard site is no more complex than deploying your own ASP.NET
applications. You simply need to copy the content files and binaries from
the Orchard.Web project to your
server.
To create a deployment package from the source, you could use Visual Studio’s publishing feature, found under Build→Publish. You can deploy to your filesystem to get a package that you can copy to a server. Another option is to clone the source, as described earlier in this book, and run the build.cmd file that’s found at the src root. This build file isn’t part of the zipped source bundle that we’ve been using.
Deploying an Orchard site to a shared hosting provider requires a
bit more consideration than a typical ASP.NET application. For security
reasons, many shared hosts won’t allow your applications to run under
Full trust. Orchard will run under
Medium trust, but is optimized for
Full. If you are able to find a host
that supports Full trust, you’ll be
better off in terms of site performance, as Orchard will be allowed to
use all of its optimization techniques.
If you take a look at the worker process (w3wp.exe) for your app pool in Windows Task Manager, you’ll probably notice
memory pressure is a bit higher than you would have expected. My
development site is currently running at about 300MB, but I’ve also seen
it reach nearly 700MB. Most shared hosts don’t advertise hard memory
limits, but when they exist you’ll likely see your app pool recycled
more frequently than you’d prefer.
Another cause of app pool recycling is inactivity. If your site
isn’t accessed for some period of time, the worker process will be
recycled. Again, shared hosts might be more aggressive as to how
frequently your app pool is recycled. Since Orchard’s startup time tends
to be relatively slow, there’s a Warmup module that will periodically generate
semi-static versions of pages that should always be served
quickly.
Enable the Warmup module by
visiting Modules→Features and clicking
“Enable” on “Warmup.” After enabled, click “Performance” under the
“Settings” menu option. In the “Warmup” tab, enter relative URIs (e.g.,
“/john-zablocki”) for the pages you want to be cached. You can choose to
generate these pages on a schedule, as well as when content is
published.
If your Orchard site is a hobby site, such as DaisysGone.com, you’re unlikely to be willing to fork over hundreds of dollars each month to have a dedicated server. If you can afford it, though, this option will give you full control over your server and the ability to configure the hardware to meet your site’s needs.
A cheaper alternative is to get a Virtual Private Server (VPS).
You can generally get your own VPS, complete with Remote Desktop access, for under $30. For that
price, you’ll find 1-2GB RAM and 25-50GB of storage. However, that
usually doesn’t include SQL Server access or storage. You’ll often have
to pay a separate licensing fee for SQL Server with a VPS solution. By
contrast, shared hosts will usually include a shared SQL Server in their
plans.
Deploying an Orchard site to the cloud is a reasonably straightforward effort. On EC2, you’ll just launch your instance and move your Orchard files out via FTP or your preferred file transfer method. Again, you’ll have to consider the cost of resources, in particular, SQL Server.
Another script that may be found in the source root when cloning the repository is ClickToBuildAzurePackage.cmd. Assuming you’ve installed the Azure SDK, this batch file will create an Azure package under an artifacts directory. In this Azure ZIP file, you’ll find a file named ServiceConfiguration.cscfg that you can edit with details from your Azure account. There is a detailed tutorial for deploying to Azure in the Orchard documentation.
Orchard offers a MultiTenancy
module, which allows a single instance of Orchard to host multiple
Orchard sites. This module is best suited for shared hosting, where you
might likely pay for each dedicated app pool you are allotted. Your site
that’s infrequently hit might also benefit from the one that is hit
often and keeps both sites alive. Of course, sharing an app pool means
one site could bring down another as well.
When you install a module from the gallery, you’re allowing another
developer’s code to run inside of your application. All developers
occasionally write some bad code. You might think that the Lolcats module you just installed is innocent
enough, but it actually spawns a background thread that downloads and
caches all the cats posted to http://icanhascheezburger.com/ for the past five
years.
If you start to notice performance problems after installing or updating a module, try disabling that module. It’s more than possible that Orchard’s performance could be impeded by an errant module. Also, limit the number of modules you have installed or deployed as ASP.NET will perform better with fewer assemblies to load.
Once your site is deployed, you’ll need to consider how you are going to manage content and code. Your process will vary quite a bit based on whether you’re creating extensions or just content types. Regardless of which use case best describes your Orchard experience, you’re likely going to want to stage your site.
If you’re maintaining an Orchard site that’s effectively just Orchard out of the box, having regular backups is probably sufficient. There’s not much of a need to stage a site that isn’t actively being developed. It’s certainly useful, however, to have a place to test modules from the gallery before enabling them on a live site.
If you’re creating custom content types, alternate templates, or otherwise modifying content, you’ll benefit from having a staging version of your site. Changing content types certainly could impact the behavior of a site. It’s best to experiment with these modifications in a safe place.
If you’re actively developing an Orchard site, whether by creating widgets, modules, or themes, you’ll want a standard development experience. Of course, you’ll use source control. You’ll want a local version of the site and probably a QA and staging version as well. In short, treat Orchard development as you would development with any of your other web projects.
New versions of Orchard are released periodically. Unfortunately, Orchard doesn’t yet have in-place upgrades as you might find in other popular CMS platforms. Instead, the basic upgrade path involves creating a new site deployment from the new release. In other words, you’ll extract the release package (ZIP file of source of precompiled web files) to a local directory.
Create a new IIS site that points to this new release directory, but don’t go through the “Getting Started” wizard. Copy the themes, media, and App_Data from your live site to this new site’s directory. If you’ve installed any modules, copy those as well.
To test the upgrade on the database, you’ll probably want a local copy of that as well. If you’re using SQL CE, you’ve already created a copy in the previous step. If you’re using SQL Server, you could just restore locally from a production backup. You’ll also have to update the connection string information in Settings.txt in the directory for your recipe, which is found under App_Data.
Now browse to the site and login. Orchard should have run any migrations for modules that might have been upgraded in this new release. Assuming everything went well (i.e., you performed full QA of your site), you’re ready to deploy the update to production. Back up the existing site and its database and follow any of the deployment methods detailed in this chapter.
The Orchard team will no doubt continue to improve on the experience of developing and maintaining Orchard sites. As the community grows, you’ll likely see that hosting companies are adopting Orchard as a hosting add-on. Some shared hosting companies already offer Orchard sites via one-click installation from application galleries. At the same time, as the codebase moves from version 1.4 to the next major release, many of the considerations we discussed in this chapter may be moot.