In my previous post, I described a simple alternative to using Umbraco Courier for basic staging sites and how it could be accomplished through just a few lines of custom code.   In that post, however, I did not cover any means to set and store the host names for which we wanted to display the staging data.

The most logical place for this setting is the “Culture and Hostnames” dialog.  A simple “Staging” checkbox should do the trick nicely:

 uStageDialog.jpg

However, we don’t want to touch the core dialog.  Instead we want to replace the original with our own.  This way our plugin is much less invasive and easier to install/uninstall.

We do this on the TreeControllerBase.MenuRendering event:

  TreeControllerBase.MenuRendering += TreeControllerBase_MenuRendering;  

Below we simply remove the original dialog and substitute our own!

  private void TreeControllerBase_MenuRendering(TreeControllerBase treeControllerBase, MenuRenderingEventArgs menuRenderingEventArgs)  
     {  
       //Only do this for the assignDomain menu  
       if (menuRenderingEventArgs.Menu == null || menuRenderingEventArgs.Menu.Items.All(x => x.Alias != "assignDomain")) {   
         return;  
       }  
       //find original dialog and it's index  
       MenuItem oldItem = menuRenderingEventArgs.Menu.Items.FirstOrDefault(x => x.Alias == "assignDomain");  
       int i = menuRenderingEventArgs.Menu.Items.FindIndex(x => x.Alias == "assignDomain");  
   
       //remove original dialog (and our new dialog if it's already been added  
       menuRenderingEventArgs.Menu.Items.RemoveAll(x => x.Alias == "assignDomain");  
       menuRenderingEventArgs.Menu.Items.RemoveAll(x => x.Alias == "stageSetup");  
   
       //finally create our new replacement dialog   
       MenuItem stageSetup = new MenuItem("stageSetup", oldItem.Name);  
       stageSetup.Icon = oldItem.Icon;  
       string dialogURL = string.Format("{0}?id={1}", "/umbraco/ustage/dialog/assigndomain2sv.aspx", menuRenderingEventArgs.NodeId);  
       stageSetup.LaunchDialogUrl(dialogURL, "Set Domains for Staging and Live Sites");  
   
       //and insert it into the menu items collection  
       menuRenderingEventArgs.Menu.Items.Insert(i, stageSetup);  
   
     }  

The key difference in our version of the dialog controller is that we have an additional flag for whether the domain is a staging domain or not. To handle this staging data, we inherit from base “DomainsApiController” and add our own action in which we call not only the base “SaveLanguageAndDomain” method, but also our logic to save the staging domains in a separate table (again, to keep separation from core).

  [HttpPost]  
     public PostBackModelWithStaging SaveLanguageAndDomainsStaging(PostBackModelWithStaging model)  
     {  
       //first populate standard PostBackModel with required properties including domains  
       PostBackModel baseModel = new PostBackModel();  
       baseModel.NodeId = model.NodeId;  
       baseModel.Valid = model.Valid;  
       baseModel.Language = model.Language;  
       DomainModel[] dms = new DomainModel[model.Domains.Count()];  
       int i = 0;  
       foreach (var d in model.Domains)  
       {  
         var dm = new DomainModel(d.Name, d.Lang);  
         dms[i] = dm;  
         i++;  
       }  
       baseModel.Domains = dms;  
   
       //Call the base SaveLangueageAndDomains, passing in its baseModel that it wants  
       baseModel = base.SaveLanguageAndDomains(baseModel);  
   
       //update staging version with updated base in case there are changes  
       model.NodeId = baseModel.NodeId;  
       model.Valid = baseModel.Valid;  
       model.Language = baseModel.Language;  
       DomainModelWithStaging[] dms2 = new DomainModelWithStaging[baseModel.Domains.Count()];  
       i = 0;  
       foreach (var d in baseModel.Domains)  
       {  
         var dm = new DomainModelWithStaging(d.Name, d.Lang,false);          
         
         //get proper staging setting assigned to domain model  
         dm.Staging = model.Domains.Where(x => x.Name.ToLower() == dm.Name.ToLower()).FirstOrDefault().Staging;  
         dms2[i] = dm;  
         i++;  
       }  
       model.Domains = dms2;  
     
       //save data to database  
       if (model.Valid)  
       {  
         model = ProcessDomainsForStaging(model);  
       }  
       return model;  
     }  

As you can see above, we also have a new "PostbackWithStaging" model to include the staging data and a new “StagingDomain” class, which inherits from the core "Domain" class and handles the CRUD operations for us. 

To handle the deletion of domains from the dialog, we attach to the delete event of the domain.  Our full list of new event handlers are now listed below:

       //Prepare the stagingdocument on save  
       ContentService.Saved += Saved;  
         
       //replace original dialog with custom menu on menuRendering  
       TreeControllerBase.MenuRendering += TreeControllerBase_MenuRendering;  
   
       //handle delete event of StagingDomain to delete staging table info  
       StagingDomain.AfterDelete += StagingDomain.DeleteStagingInfo;  

All that is left is to ensure the table exists on startup:

  protected override void ApplicationStarted(UmbracoApplicationBase umbracoApplication, ApplicationContext applicationContext)  
     {  
       Database db = applicationContext.DatabaseContext.Database;  
   
       //Check if the DB table does NOT exist  
       if (!db.TableExist("uStageDomains"))  
       {  
         //Create DB table - and set overwrite to false  
         db.CreateTable<uStageDomains>(false);  
       }  
     }  

That’s it!  We now have our staging information controlled alongside our culture and hostnames data.  We retrieve it like so within our contentfinder;

  private static bool IsStagingDomain(string domain) {  
   
       StagingDomain sd = new StagingDomain(domain);  
   
       return sd.IsStaging;  
        
     }  

The full plugin (as well as full source code) is available here. We welcome any improvements, enhancements, or suggestions. Thanks!

Other Posts in This Series

Looking for help in Umbraco? We're an Umbraco Certified Partner. Contact us and let's talk about how Liquid can help you!

Save

Save

Tags:
Steve Bridges

About Steve Bridges

Currently serving as Liquid's CIO and Director of Application Development, Steve possesses nearly 20 years of experience in professional software development.  He cut his technical teeth in the financial industry where he spent a decade developing websites, applications, and line of business applications for a credit card company. It was there he developed a love for marketing and found a home in agency life.   A lifelong Lehigh Valley native, he jumped at the chance 5 years ago to join the Liquid family.  

Published Apr 29, 2015