Sitecore WebAPI – Hooking into the route setup

Setting up routes in MVC and WebAPI is pretty straightforward in Sitecore provided that its done in the correct pipeline. When I first started attempting to add routes, I quickly discovered that doing this via the Global ASAX wasn’t reliable. The reason for this is that the routes are setup in the initialise pipeline.

Fortunately Sitecore has this process mapped out in the the config file so all I needed to do is swap out the DefaultRouteMapper that comes out of the box. Lets look at the entry in Sitecore:

<setting name="Sitecore.Services.RouteMapper" value="NAMESPACE.CustomRouteMapper, ASSEMBLY_NAME" />

Continue reading

Advertisements

Back to Basics: Sitecore validation – part 1

This is the first post in a series about back to basics. All to often I come across Sitecore projects that commit a number of sins. Hopefully this will tie together with the continuing series on working with the Sitecore platform instead of against it. So with that in mind, the first few parts will be about field validation in Sitecore.

Field validation is often overlooked. I think in part because the template editor has a quick and dirty interface for setting all the common properties such as name, source, shared etc. But to setup the validation, help text and the like you have to go into the field itself.

However, the content editors experience can be greatly enhanced with good validation with clear, concise error messages. It also means that as developers, we can enforce a little safety in our environment and increase our chances that our code will get data in the right ‘shape’.

A short history lesson

Before Sitecore 5, validation was done with regular expressions and a generic error message. This would fire and the user would see a popup with that message. After a while this would get pretty annoying as the editor couldn’t really see which fields were invalid and, in some cases, the warning wasn’t a critical error. Inevitably, unless all of the fields were required and the error messages could be made verbose enough, validation was turned off.

Even now Sitecore 7.x supports this functionality but using it is an incredibly bad idea.

Sitecore validation done right

Validation done right means you need to use the validators built into Sitecore (or add your own) using the various multi-lists directly on the field item for your template. If you do so, you have the advantage that as the editor builds their content, they get visual cues as to which field is incorrect. This appears as a red bar next to the field and colour spots to the top right (in the content editor). You also have the advantage that you can set the levels of these errors and class some as critical meaning the user can’t progress without fixing and you can make others ‘a bad idea’.

More importantly, these are all written in .NET code. What this means is that when you write your own, you’ll be able to unit test them under various conditions and more easily have them as part of your continuous integration builds.

In summary

This post was particularly short as an introduction to validators but they are more of a ‘show me the code’ topic. Its also pretty near to Christmas and I have small people to entertain! 🙂

In my next post on this topic, I’ll look at writing a very simple validator, registering it with Sitecore and setting its error level. More importantly, we’ll look at making it have different options per language and so handle some interesting scenarios. We’ll also have a unit test setup for it and I’ll put it on Github for reference.

 

SwitchMasterToWeb – updated for content search & analytics

A couple of weeks ago I was tasked with setting up our UAT environment, in doing so, I duly dug out the latest copy of the Scaling Guide for the appropriate version of Sitecore, and of course, dug out the trusty SwitchMasterToWeb.config.

So, some hours later, I pushed all the necessary code for our UAT content management and content delivery servers. I was disappointed to find that our indexing was not being built on the content delivery nodes. I eventually tracked it down and found that it appears to be the index update strategy. After patching it out

My Complete File

So here is my version of the switch master to web configuration

<?xml version="1.0" encoding="utf-8" ?>
<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/" xmlns:set="http://www.sitecore.net/xmlconfig/set/">
  <sitecore>
    <settings>
      <setting name="Analytics.DefaultDefinitionDatabase" value=“pub“ />
    </settings>
    <sites>
      <!-- OPTIONAL FOR CHANGING TO PUB DB -->
      <site name="shell" set:content="pub" />
      <site name="modules_shell" set:content="pub" />
      <site name="testing">
        <patch:delete />
      </site>
      <!-- OPTIONAL FOR CHANGING TO PUB DB -->
	  <site name="MySite">
		<patch:attribute name="database">pub</patch:attribute>
	  </site>
    </sites>
    <IDTable>
      <!-- OPTIONAL FOR CHANGING TO PUB DB -->
      <param connectionStringName="master" set:connectionStringName="pub" />
    </IDTable>
    <databases>
      <database id="master">
        <patch:delete />
      </database>
      <!-- OPTIONAL FOR CHANGING TO PUB DB -->
      <database id="web">
        <patch:delete />
      </database>	  
      <!-- STILL NOT 100% SURE THIS IS NEEDED, BUT IT WORKS FOR US -->
	  <database id="pub" singleInstance="true" type="Sitecore.Data.Database, Sitecore.Kernel">
		<Engines.HistoryEngine.Storage>
          <obj type="Sitecore.Data.$(database).$(database)HistoryStorage, Sitecore.Kernel">
            <param connectionStringName="$(id)" />
            <EntryLifeTime>30.00:00:00</EntryLifeTime>
          </obj>
        </Engines.HistoryEngine.Storage>
        <Engines.HistoryEngine.SaveDotNetCallStack>false</Engines.HistoryEngine.SaveDotNetCallStack>
      </database>	  
    </databases>
    <search>
      <configuration>
        <indexes>
          <index>
            <locations>
              <master>
                <patch:delete />
              </master>
            </locations>
          </index>
        </indexes>
      </configuration>
    </search>
    <scheduling>
      <agent type="Sitecore.Tasks.CleanupFDAObsoleteMediaData">
        <databases hint="raw:AddDatabase">
          <database name="master">
            <patch:delete />
          </database>
        </databases>
      </agent>
      <agent type="Sitecore.Tasks.DatabaseAgent">
         <patch:delete />
      </agent>
      <agent type="Sitecore.Tasks.DatabaseAgent">
         <patch:delete />
      </agent>
      <agent type="Sitecore.Tasks.DatabaseAgent" method="Run" interval="00:10:00">
        <param desc="database">core</param>
        <param desc="schedule root">/sitecore/system/tasks/schedules</param>
        <LogActivity>true</LogActivity>
      </agent>
    </scheduling>
    <contentSearch>
	  <indexUpdateStrategies>
                <!-- OPTIONAL FOR CHANGING TO PUB DB -->
		<onPublishEndAsync>
		  <param desc="database" patch:instead="param[desc='database']">pub</param>
		</onPublishEndAsync>
                <!-- THIS CAUSES INDEX ISSUES ON THE CONTENT DELIVERY NODES -->
		<syncMaster>
		  <patch:delete />
		</syncMaster>
	  </indexUpdateStrategies>
	  <configuration>
	     <indexes>
                    <!-- THIS SHOULDN'T REALLY BE ON CONTENT DELIVERY -->
			<index id="sitecore_master_index">
				<patch:delete/>
			</index>
                <!-- OPTIONAL FOR USING A PUB DB -->
			<index id="sitecore_web_index">
				<patch:delete/>
			</index>
		 </indexes>
	  </configuration>	  
	</contentSearch>
  </sitecore>
</configuration>

Please note, this version also changes the content delivery servers to use the ‘pub’ database which we have set up as a publishing target to allow the content editors to have the ability to view a pre-live version of the content by publishing to the web database.