Development Blog

Logs are a fantastic resource for a developer. When done correctly, they allow us to quickly and easily pinpoint what is going wrong so we can actually do something about it.

Sitecore has a VERY extensive logging system built in. You can view the logs at any time by going to your Sitecore root folder, and finding this path:

/Data/Logs

For my site, it is C:/Sitecore/Tutorial/Data/Logs

This is, however, A LOT of logs.

Luckily, there is a fantastic tool called Sitecore Log Analyzer (SCLA).

Sitecore's built-in Log Viewer is under Sitecore -> Reporting Tools -> Log Viewer, and allows you to open up recent logs and view them like so:

SCLA, on the other hand, is an external tool that you can run from your desktop. It even integrates into the context menu, if you so choose.

Point it at your Log folder, and BAM! All of your errors and logs, nicely managed in real-time, with full-on sorting.

When we left off last time, we were able to load a header image from a defined item. This is great, but the implementation had many holes.

For one, we grabbed the parent of the current item, so any pages that don't have the SiteRoot as a parent will error out.

Two, we grabbed data off of the item using a static string, which can very quickly and easily break if the field changes without our knowledge.

To solve #1, I took advantage of Sitecore.Context to grab the current startpath of whichever "Site" the item is currently in - gotta think multi-site right away, after all!

var rootItem = Sitecore.Context.Database.GetItem(Sitecore.Context.Site.ContentStartPath).GlassCast<_Identity>();

You will notice that after loading the SiteRoot item, I use GlassCast to make it an item of type _Identity - this was the template where the SiteLogo was defined, which the SiteRoot inherits. This casting allows me to grab the Image directly:

LogoImageUrl = rootItem.SiteLogo.Src;

If the field "SiteLogo" ever changes, the IDE will give a nice warning and refuse to build, rather than forcing us to step through debugging steps to discover what happened.

The output is still the same, sans the text I removed:

Grabbing the SiteRoot is probably something I will want to do often, so let's break that out into it's own method.

I may get burned at the stack for using a Static method in a helper class - even extension methods, which you can read about here are frequently taboo - but, it's my project, so I do it anyways!

public static Item GetSiteRootItem() { return Sitecore.Context.Database.GetItem(Sitecore.Context.Site.ContentStartPath); }

I feel that the reward is worth the lack of dependency injecting:

var rootItem = SitecoreContextExtensions.GetSiteRootItem().GlassCast<_Identity>();

Pretty clean, and if I find myself accessing _Identity often, I can easily create a method for that as well.

Ok, after learning a lot about Sitecore development, I am back and ready to get some stuff displaying!

One of the fundamental questions I had got answered: How do you get data from the backend onto the frontend?

It's suprisingly easy!

To display some text for our header, we just need an .ascx of this:

<%@ Control Language="C#" AutoEventWireup="true" CodeBehind="Header.ascx.cs" Inherits="Website.Components.Identity.Header" %> <div class="Logo"> <%= LogoText %> </div>

The Scriplets reference fields in the .ascx.cs backend, like so:

namespace Website.Components.Identity { public partial class Header : System.Web.UI.UserControl { protected string LogoText { get; private set; } protected void Page_Load(object sender, EventArgs e) { LogoText = "Test!"; . . .

The class overrides UserControl and gives us a nice way to package data to the frontend!

We need to grab the image from our WebRoot, however, so it's time to...

Load some Items!

A lot of this was pulled from this guide.

Sitecore provides a Context item that lets us grab our current item

var item = Sitecore.Context.Item;

This isn't going to be correct for deeper pages, but for now we can grab our webroot using the database and ParentID

var parentItem = Sitecore.Context.Database.GetItem(item.ParentID);

Glasscore will provide us a way to grab the Image field using an Object, but for now let's grab it the old fashioned way. I found out this grabs the GUID, which isn't terribly useful for rendering the Image, so this guide showed me how to get the Media URL.

var image = (Sitecore.Data.Fields.ImageField)parentItem.Fields["SiteLogo"]; LogoImageUrl = Sitecore.Resources.Media.MediaManager.GetMediaUrl(image.MediaItem);

LogoImageUrl is another string Field that I render onto the .ascx

<img src="<%= LogoImageUrl %>" style="width:100px; height:100px;">

But something isn't quite right!

It looks like that Media Library URL won't work for rendering Images. Now what?

With the assistance of the wonderful Katie Grundle, we determined that my Media Library was acting up. Deleting all of the images and re-uploading fixed the problem:

As I mentioned before, the project I am currently on is big. REALLY BIG. Building takes 20 seconds or so, and then loading a page after build takes over a minute, leading to very slow iterative cycles.

This was especially infurating for CSS changes, as they were static files anyways, not code!

Complaining bitterly yielded a solution from one of my coworkers, Adam Brauer. He wrote a (slightly outdated) blog post on this issue for the Active Commerce blog. You can find it here

Copysauce is a simple script that you point at your Sitecore folder and your code folder, and you set it up to copy over certain files. Any changes detected on the code-base side (such as .css or .less changes) are copied over to the Sitecore folder, allowing changes to be seen instantly. Fewer builds lead to happier devs!

Configuration is easy - just edit a file called ".CopySauce.json", located in the root of your code folder. You will probably need to add the file to your .gitignore.

As part of my job, I was thrown back onto a large Sitecore project that I last built a month ago. It should be easy to get back up-and-running, right?

Wrong!

Pulling the latest code and building it wasn't enough - after all, as I found out in my work on Moosecore, items need to be built and synced over to the Sitecore instance, which runs on SQL (Sitecore can run on another databackends as well, but SQL is the most common).

TDS has a built-in function to Sync items between the code Project and Sitecore itself. From what I can gather, this process uses a clever bit of coding to setup a webservice on Sitecore that takes the serialized items that TDS generates in the code Project and compares them against the items in Sitecore, then generates a list of differences.

This process does not seem to have caching of any sort, and on large projects such as the one I'm on, will take several minutes to generate a list, and has to be regenerated each time you run it.

Once you have a list, you can mark which direction items should be synced: Sitecore -> Project, Project -> Sitecore, or Merge the differences.

Copying over files from the Project to Sitecore can fail for a number of reasons, one of which being that a required Template is missing, and has to be synced first before the item can be synced.

I didn't think this was a problem until I saw our setup: a fairly standard TDS setup of CORE, MASTER, and WEB. MASTER had the templates, so I had to cancel out of my current WEB sync, wait several minutes for MASTER to generate a differences list, sync the template, then wait several more minutes for WEB to reload a new differences list to sync that item over.

If TDS can detect that Item A needs Template B to sync, why does it not give me the option to sync both right away? If I am being forced to constantly switch between the difference lists, can I at least get some caching so it doesn't take 5 minutes each time I want to sync an item?

There are some alternatives out there that try to solve these problems:

Sitecore Unicorn is a lightweight and opensource item serializer that ensures the local copy of Sitecore is always up-to-date with the codebase by using Git and forcing merges right away. This seems like an ideal solution, but I don't thing Unicorn will play friendly with TDS, and I certainly don't have an option to switch to it. TDS has far more than item serialization to it, and more than just Unicorn would be required to replace it.

Sitecore Courier seems friendlier to use with TDS, as it looks for differences after the fact and creates a package that will install those changes to Sitecore. It's less efficient, as it doesn't seem to use the Git Diff, and therefore computes the changes itself, and it takes more steps, but it could be added to a build chain to keep your Sitecore up to date.

Sitecore Ship plays along very well with Courier - Ship lets you install Sitecore packages via HTTP request. Although less useful for local installs, Ship could simplify automation of using Courier in both local and server based Sitecore instances.

What I most want, however, is a way to just click a button that says "Sync Sitecore items from Git" that will take all of the differences between my last sync and now, then send them over to Sitecore to add them. Courier seems closest to this, but I'm not sure how well it keeps track of Git history.

Following the method of organizing everything into Component folders, SubLayouts now has a /Component/Identity folder where the header sublayout will live.

After searching around, I finally found the developer center where I can create this file. Can I do this in VS instead?

After searching around, I found that this was the dumb way to do it: I can just add the folder and file directly in VS, and it will copy over.

This is a lot cleaner, and will be easier to manage with Git.

In trying to show the inherited Logo image, I start getting confused with this line of code:

<xsl:variable name = "siteRoot" select="ancestor-or-self::item[sc:IsItemOfType('_Identity',.)]"/>

This seems to set a variable for this next bit, but the syntax confuses me and seems awfully unclear.

<div class = "Logo"> <sc:image select = "$siteRoot" field="Identity_SiteLogo"/> </ div >

This makes far more sense - grab the variable, and display a field from it.

After half of hour of trying to get the Header to render on the page correctly, and pulling the help of two team members, I find out that my placeholders were missing Keys! My placeholders now look like:

<sc:placeholder runat="server" key="HeaderRegion" id="HeaderRegionPlaceholder" />

New note:

Keys -> Sitecore

ID -> C# backend

I also learn that XSL is old and that I should use either GlassCast or CustomItemGenerator to grab the root element. Time to learn something new!

GlassCast

What is GlassCast?

From what I can tell, GlassCast takes items in Sitecore and generates code templates for them, and lets us convert items between each other as if they inherit each other like classes - because that's that it does, it generates classes for items. I think.

I use this tutorial as a loose guide, but frankly I have no idea what I'm doing. This seems like an excessive amount of work just to grab the Image off of a parent item.

First step is installing GlassCast, which is already confusing. There are several packages, and I'm not sure what each one is for.

I install the option that seems to make the most sense, which auto-installs the base package.

Next, I (probably) enable the Code Generation on the TDS project

The code generation relies on templates to run, which Hedgehog has graciously provided in a Github repository here

Following the tutorial, I add the following .tt files: GeneralExtensions, GlassV3Header, GlassV3Item, Helpers, Inflector, and StringExtensions

I select the GlassV3 .tt's as the transform files, but code generation fails.

As it’s the first time generating you may get an error that the file already exists. Just show all files in Solution Explorer and you’ll see the generated class file in the Models folder. Add this to the project and you should be able to continue to generate the file without the error.

I have to reopen VS and rebuild the project, but code generation finally succeeds and it seems to have worked.

If I were to build a store site solution that I would want to sell off, each client would (probably) want their own Logo's, headers, items, etc.

Therefore, the goal of this design is to seperate functionality from not only data, but also display components, which is what Sitecore seems to be good at.

A new folder in Templates called "Identity" will hold these. As I go to create the new template, I wonder - if I right click a folder to insert an item, why do I then get prompted with a drop down to set the location? It feels as if the process would be smoother if it would create in that location, and let me move it later if I messed up.

Anyways, the learnsitecore tutorial has a handy convention to follow for template naming:

A “_” prefix denotes that the template is a data definition template.

This will help clear up instances where _Footer is the fields for the Footer, and Footer is the view template, without long names such as "FooterView" or other nonsense along those lines.

The guide warns that I should prefix my field names with the component name, but let's go out on a limb and hope that however we end up grabbing components in the backend is smart enough to keep the names seperated.

I end up with this to start off with:

Now, to access the root of the site, I create another Component folder (I assume these will eventually become objects?) named "SiteRoot" and add the template "WebsiteRoot", adding _Identity as a base template.

Templates that are based on other templates, and then there can be a myriad of things that rely or base themselves off of a template - how on earth does anything even stay organized? I hold hope that there is a nice dependency tree chart somewhere.

At least it seems like Sitecore thought about this problem a bit; it turns out you can set icons and display names and help text for every item, detailed here

This alarms me, however, as I had assumed that icons were determined by the system, and therefore a reliable indicator of information.

Oh well - I pick a nice globe for my Web Root item and move on.

Now I can build my dream site, which is entirely about Mooses. Add a new item to Content based on the Root, then add a standard page; now to customize.

After working with older Sitecore Content Editors, the new interface looks nice for media uploads!

I'm really hoping this image resolves properly, it's not looking so good

Another note for my books:

A rendering are based on XSLT, which means that it can (or should) be used for presenting content only. It should contain no logic or actual functionality. A sublayout is a .Net web user control which gives you completely free hands to do whatever you want – also presenting simple content.

I don't see a reason to NOT use sublayouts based on this, and so will proceed in that direction.

A template, and a lot of clicking later, and I have a new test page that looks exactly like the home page! Round of applause everyone, we can go home now. The learnsitecore guide has excellent diagrams for this process if you are following along at home.

What's the difference? By building this new page "From Template", and using the new template that has the new layout as a standard value, I can make changes to the new layout and have it automatically apply to all of the pages that use that template. TLDR; Using templates to template.

Hitting publish lets me go to tutorial/test and access the new page, which is ideal for those users that don't want to use page editor all of the time.

Let's put the template to good use and update the .aspx

First I add a link to a stylesheet:

<link rel="Stylesheet" href="/components/design/css/default.css" />

Then, some placeholders, which turned out to be suprisingly easy:

<form method="post" runat="server" id="mainform"> <div class="Page"> <div class="HeaderRegion">[Header] <sc:placeholder runat="server" id="HeaderRegionPlaceholder" /> </div> <div class="BodyRegion">[Body] <sc:placeholder runat="server" id="BodyRegionPlaceholder" /> </div> <div class="FooterRegion">[Footer] <sc:placeholder runat="server" id="FooterRegionPlaceholder" /> </div> </div> </form>

Let's not forget the CSS to make it look... well, not good, but like something.

I added default.css in a new folder under Components called Design, like so:

It's just basic div coloring for easy viewing.

.Page { width: 1000px; } .HeaderRegion { height: 150px; width: 100%; background-color: Red; } .BodyRegion { width: 100%; background-color: Grey; } .FooterRegion { height: 150px; width: 100%; background-color: Blue; }

Time to start making something cool!

Immediately, this information strikes me as important:

Layouts and Sublayouts are .ascx Renderings are .xslt

Layouts hold Sublayouts and Placeholders Sublayouts hold Placeholders Placeholders hold Renderings

After throwing that into my notes, I continue on.

I need to make a folder for my components, so I do so in VS then use Sitecore Rocks to connect to my Sitecore instance so I can sync it over.

But wait! The "Sync with Sitecore" button that I've grown to love isn't there!

Turns out, I need to install Hedgehog's TDS

Queue a sudden shift in post topic!

TDS for Dummies

Based on the provided tutorial for TDS, this seems correct:

Sync was now present, but came up empty - turns out I need to run "Get Sitecore Items". Makes sense I guess, but I would have assumed Sync would do the same.

And, after all of that work, it turns out I still needed to manually create those folders for the template. Oh well.

Back to Layouts

I create a new Layout called "MainLayout" and point it the /Components/PageTypes folder in both Sitecore and the C# project.

The guide says to manage these layouts with a new project, but I think that's unnecessary, and opt to just include the file in my current project.

I build, it works, A+ for now.

Time to test: I swap out the sample Layout for Homepage with the new one I just made.

I work at a branding firm, and until now, I have been working entirely with ASP.NET websites.

Most of the company, however, works with Sitecore - a powerful CMS that I happen to know next-to-nothing about.

The other members of my company include some of the top Sitecore developers in the world, such as Mike Reynolds, and the entire team behind the popular Active Commerce module.

I will essentially live-blog; documenting every issue and feature I work through as I encounter them.

Why, you may ask?

There does not seem to be a good start-to-finish guide out there for Sitecore, and I hope to pave the wave for others who may follow my path.

As part of making combat more interesting, slimes now spawn in monster camps (the buildings). This screen cap is a result of having a way too high spawn rate and no checks to ensure the slimes stay on the playing field.

Mmm getting there on the UI rewrite. I especially like the AP bar, represented by a circle of swords that are either filled or empty.

Writing an AI was pretty fun and simpler than I thought. The decision making goes like this:

1. Do I have low health? Yes? Use a potion if I can. 2. Am I near an enemy? Attack it if I can. 3. Do I have a move card? Move closer to nearest enemy if I'm not next to it. ->Repeat from step 1 while there are still usable cards 4. Is there no good move? Waste my lowest value card and end my turn.

Look at all of this info. Turns, money, action points, card names, card costs.

It's disgusting to look at, but it works. I work in a function-first style system, which means I create basic prototypes of everything to see if meets criteria first. It has to be 1) Fun 2) Easy to understand AND 3) Good looking.

There's no point in spending an entire day making mana crystal graphics (my original idea for Action Points) only to realize once I play test that I want all cards to have costs, not just spell cards, and so mana wouldn't work.

Borrowed some placeholder art assets. Made a shop.

The Item cards go into the player's item deck, which is used in the game along with other type of cards. These cards are single use only, and do not return to the deck unlike other cards.