Redirect Umbraco 7

Redirect A Url To An External Domain In Umbraco 7

One of my clients has an Umbraco 7 site that pretty much takes care of itself other than a few minor content updates here and there. Today that client asked we set up a redirect from an internal URL to an external domain for their job postings. Normally this is an easy change using IIS rewrites in the web.config with the IIS Rewrite Module. But this site is hosted on GoDaddy and like all GoDaddy things, what I thought was easy turned out to be a bit more of a challenge.

After a bit of research I found you can redirect Umbraco URLs using the UrlRewritingNet component that’s built into Umbraco 7. Here’s an example of how to configure Umbraco 7 to redirect an internal URL to an external domain using the UrlRewriting.config config file.

To configure a URL rewrite open the configuration file located at /Config/UrlRewriting.config and add a rewrite rule like the example below. I found that rewriting to an external URL was more tricky than an internal virtual URL so here are a couple specifics to keep in mind when setting up a new rule for an external URL:

  1. Set rewriteOnlyVirtualUrls=”false” attribute inside <urlrewritingnet
  2. The virtualUrl is the source URL of the page you are redirecting from. The value in this attribute must start with http(s)://domain otherwise the rule will be ignored
  3. destinationUrl is the destination for the redirect
  4. redirect should be set to “Domain”

Here’s an example of the UrlRewriting.config file that will redirect an internal URL to an external domain.

<?xml version="1.0" encoding="utf-8"?>
    rewriteOnlyVirtualUrls="false"   >
           redirect="Domain" />



My Top 5 Reasons To Start Using CI/CD

For the first half of my career we moved code from our local machines -> dev -> test -> production the old cowboy way, just by copy & paste from one environment to the next. It’s quick and easy but also riddled with holes. Now we’ve got better ways of doing things with processes like CI/CD and source control systems like Gitlab and Github. Here are my top five reasons why you should have a CI/CD process or pipeline set up into your development workflow:

  1. Each commit can be traced to a specific environment allowing developers to see what code is in production or test at any given time.
  2. If you’re pasting files around, you can easily blow away or overwrite something you didn’t mean to.
  3. CI/CD pipelines let you can roll back commits and changes with the click of a button if you break something. Thus keeping you from scrambling to find that backup folder you created (or didn’t) before moving the code to production.
  4. Check in your code and forget. CI/CD pipelines will automatically move your changes to your environments for you.
  5. Pipelines will run unit and integration tests before deploying code. If the tests fail the migration is halted so breaking changes never make it to production.

This getting started guide for Gitlab is a good place to start with CI/CD.