Ken's Blog

I did some research on Google (the programmer’s best friend) and found this article by Sitecore MVP Jason Wilkerson. He describes a process that adds a custom chrome around the renderings, which is useful, but not precisely what I was looking for since it just affected the renderings. Then I found this article by Sitecore MVP Anders Laub, which discussed wrapping an accordion around renderings at the placeholder level. Again, not what I was looking for, but it was the clue to put things together.

Basically, I adapted Jason’s technique into Anders’ code, and set up the pipeline connections for both renderings and placeholders. The result is a consistent approach for both, making the chromes for them easily selectable for users to access. I even added a little color from the Experience Editor ribbon to make them stand out!

One last styling I threw in was for edit frames. I’m using Glass Mapper to generate the edit frames, but I believe the standard edit frames would render the same way. I added a border around each edit frame to make it more identifiable; I tried added a similar chrome, but clicking the header activated the rendering. There might be a way to work this technique into the edit frames as well, and I hope someone figures it out and passes it on!

Below is an image of what the Experience Editor looks like with all of this enabled:

Those of you who’ve dealt with Sitecore or Ektron are probably familiar with the idea of a “Library” folder, where you stash the DLLs you need from the product to reference in Visual Studio projects. (Side-note: please don’t store ALL of the product’s DLLs, just the ones you need!) The process then involves individually referencing each DLL in each project, which you can imagine could take a bit of time. Plus, if you need to make changes, it could take some time, and then you have some inconsistencies in deployments across projects.

Of course, a NuGet package would solve this problem, but as we noted, Sitecore doesn’t do this. And I’m not sure on the legalities/ethics/etc of putting Sitecore DLLs out on the open NuGet servers. Fortunately, there’s another way, and there’s a side-benefit to this suggestion.

First, create a folder at the solution level called .nuget. (I had to name it .nuget. when naming the folder to make it catch with a period at the start.) Inside that, create a nuget.config file. Also, create a subfolder called packages-local.

Open the nuget.config file, and paste this in:

<?xml version="1.0" encoding="utf-8"?> <configuration> <solution> <add key="disableSourceControlIntegration" value="true" /> </solution> <packageSources> <add key="Local" value="packages-local" /> </packageSources> </configuration>

Two things to note here:

The disableSourceControlIntegration setting means that you won’t need to store the contents of your “packages” folder in source control. When someone downloads your code and builds, it’ll grab all the packages from the appropriate sources.

The packageSources setting specifies (for this project only) what sources to use for getting packages. A lot of the time, this is set more globally in Visual Studio, but in this case, we’re telling NuGet to look in our “packages-local” folder to store our own packages.

Now, we can use the NuGet Package Explorer to create our own package. In my case, I created one called Sitecore Essentials and brought in the DLLs I needed. Then I applied the package to the projects necessary. Nice and clean!

If you do something similar, I recommend using the version number to note what version of the product you’re working with, then the version of the package. For example, I’m on the latest Sitecore (as of this post), so I used 8.1.1.0 for Sitecore 8.1 Update 1, initial package creation. If I need to add DLLs, I’ll go to 8.1.1.1, etc. And when Update 2 is out, it’ll be 8.1.2.0. Again, nice and clean!

These settings will keep the packaged files with your source control, but have it recognized by the Visual Studio NuGet UI for purposes of maintaining the updates. It should also work for doing builds on a build server where it’s told to restore NuGet packages, though I haven’t tried that far as yet. But since everything else is treating it like a nuget.org based package, that should too.

The situation was that I was telling my TDS projects in Visual Studio to generate  a Sitecore update package (.UPDATE file) after building. The build worked fine, but the update package would throw an error. Of course, like what sometimes happens in these situations, the error message is thoroughly unhelpful.

Because this is using the Visual Studio build process, you can get a little more information out of the compiler. Go to the Tools > Options menu, then under Projects and Solutions, choose Build and Run. Change the two verbosity dropdown to “Normal” instead of “Minimal.” Now when you build, you’ll get some better information to work with.

What usually is happening is some illegal character in a rich-text field is causing the problem. This will usually come up as a message saying a hexadecimal value is an invalid character, giving you that hex value (like 0x03 or like). Of course, it just tells you that there is an error, not where the error is. Still, we’re on the right track!

The last diagnostic step here is to go to the properties on the TDS project causing the problem, then click on the Validations tab. Check on the Enable Validations checkbox, then check on the link for code “TDSA012″ - this will cause any of the specified illegal characters to trip the Visual Studio error process. Enter the character you were given before in the Additional Properties box and click Add, then run the build one more time. This time, when you get the error, you’ll be told exactly what item and what field the problem is in.

To fix it, you’ll need to edit the Sitecore item and field to dump the illegal character. Something I noticed, however, is that you can’t see the illegal character in Sitecore’s editor (neither rich text or HTML mode). I found that copying the HTML markup of the rich text editor into Notepad++ revealed the characters...they came up as letters in black marks for me. I can’t guarantee this will work for you, but give it a go. Also, note that if multiple versions of the item trip the error, you’ll need to modify each version to get the package to generate.

First, on working locally with the website. You can of course install Episerver via NuGet and work with it, but without a license, you can’t effectively use it outside of your local machine. Most CMSes I work with, I publish it out to a full IIS website with a hostname setting, like “local.mysite.com” - you’ll find you can’t do that with Episerver, at least not without getting a lot of annoyware all over your site. If you run the site through Visual Studio’s IIS Express, you’ll have no problems, but to keep from constantly having to start your site, you’ll want to disable the Edit and Continue function in the debugging. If you do like the publishing to IIS idea (to take advantage of config transforms...coming up later), you can do it, but you have to push to a site specifically using the “localhost” name to avoid the annoyware.

Next, the database used in our standard setup can be found in the App_Data folder. If you look for it in Visual Studio, you won’t see it unless you turn on the “show all files” function. If you’re running SQL Server Express, you can copy that database file to another location and attach to it in SQL Management Studio to bring it into SQL Server, instead of running as LocalDB. Especially if you’re using the localhost publishing above, you might want to do this to protect your content (luckily your data modeling comes from your code).

For source control, I’d say put everything in there except the “modules” folder. Based on my initial look at everything, since that folder contains the CMS itself and you can get that from NuGet, there’s really no need to keep it in source control. I’d also consider leaving out the “App_Data” folder; the GeoLiteCity.dat file comes from the CMS install, the database isn’t something you’d put in source control typically (and if you moved it out, it wouldn’t be here anyway), and the log files don’t need to be kept forever certainly.

The first thing you’ll need is Visual Studio, and I highly recommend getting 2015 at this point. The Community edition will work just fine, and it’s free. After that, go into the Tools > Extensions and Updates and search the online catalog for Episerver. You’ll find the Episerver CMS Visual Studio Extension. Install this, and you’ll have the installers you’ll need for Episerver projects.

When you go to create a new project now, you’ll see an Episerver entry on the menu, with a single option to create Episerver projects. Once you pick that, you’ll get three options. Forget you ever saw the Alloy (WebForms) option...we’re dong MVC. :) From here, I’m assuming you’re like me and new to Episerver, so here’s how I’m proceeding.

First, create an Episerver project off the Alloy (MVC) model, which you’ll use as a reference. There’ll be some parts of this we’ll use as a guide, and others we’ll just swipe. :) But that’s why they put it out there, to give you some ideas on where to start.

After that, in another Visual Studio instance, create a blank Episerver project. This will give you the best-practices structuring for a project that you can work with. The one folder I want to point your attention to straight off is the “modules” folder. See it...see it...now ignore it. That’s actually where the Episerver CMS UI is kept, and I’d advise not touching it or putting anything in it. One thing I’m not sure of as I write this is if you can remove it from a production environment, if you don’t want people accessing the CMS from there. There are configurations that you can change to kill access as well, and that might be your safest bet.

When you’re ready to create your first item, using “add new item,” you’ll see there’s an Episerver category here as well. This will give you some starting templates to work from as you put together your site. Which we’ll do next time. In the meantime, you do have one piece of homework.

Episerver uses a continuous release model, and pushes their updates out via NuGet. In Visual Studio, you can add their feed URL: http://nuget.episerver.com/feed/packages.svc. You can then go into the NuGet Package Manager and check for updates to your Episerver install; start with the Episerver CMS entry, as that will encompass most of the updates from the other packages. After the install, open the NuGet console in Visual Studio and run “update-epidatabase” to update your database schema to match (if you don’t do this, the next time you run the site you’ll get an error telling you to do it). So get your project updated with the latest version of Episerver before you start programming!

Well, it could be. :) Some of my EMVP colleagues noted that there are packages that don’t play well necessarily with EPiServer once they’re upgraded. So I think your safest bet here is to let EPiServer define the requirements in their packages. If they need Entity upgraded, they should set the minimum requirements for that, and any other package that was integrated because of their install. (Fun fact: after updating EPiServer in my Alloy project this morning, I tried to update NuGet.Core, figuring it’s safe...I was actually told it was too high a version for one of the EPiServer packages.)

Other stuff you might use, like Bootstrap, JQuery, the Optimization Framework, etc, you’re safe to upgrade on your own. You may need to keep a log of your own as to what to upgrade and not upgrade, and if you’re in a multi-developer environment, maybe designate a developer as the upgrade “master” so they can keep the log, etc.

I’d also toss this advice at anyone cross-developing in Umbraco, since they’re the two .NET CMSes I know of that do NuGet-based updating. We won’t mention Sitecore’s...that upgrade process can be a serious pain, especially if you’re way behind in your updates!

Update: I had someone at EPiServer reach out to me to ask about this post, which is always cool and makes me as a developer feel valued for feedback. They noted that there should be package constraints in their own packages, so I fired up a blank MVC site and brought in EPiServer to test it out. After I upgraded EPiServer, I went to each package left over in NuGet to update them. Some I was able to do, others I could only do to a certain level. So it does look like EPiServer has limiters on working versions of certain packages.

I think the only thing I could think of to add is to put the maximum package level in as a equals instead, so components are upgraded as EPiServer is. That way, there’s certainty from the vendor which works with which, while keeping the project as up-to-date as possible. Since EPiServer is releasing product updates through their NuGet every two weeks, you’d never be far out of step with general updates with this method.

I was talking with someone and in passing, they mentioned that IIS has a timeout for application pool recycling. At first I’m thinking the idle timeout, which defaults to 20 minutes and which I think most .NET developers know about and alter to suit their needs (or put in a keep-alive function). But they actually meant a real full recycling of the application pool, as if you did iisreset. It’s happening by default. It might even be happening now!

Here’s an article about it: http://blogs.iis.net/owscott/why-is-the-iis-default-app-pool-recycle-set-to-1740-minutes. Basically, every 29 hours (because Microsoft didn’t want it set to a strict 24 hours and 29 was the first prime number past 24), your application pool recycles. Great for health, but think about what this means. Every 29 hours, whether you’re in the middle of the work day or late at night, your application pool loses session state, application state, and caching state. And now, I think, you’ll see why I’m bringing this up...

I have a client who has, at times, said the site seems slower to them at certain times of the day. I know their network isn’t the best in the world (heck, they know it too) and I chalked it up to that. But what if this was an instance of a recycle event happening? There’s a lot of cached data in play here...user profiles, menus, news articles, etc...and to have to go back to the server not when I told it to, but because of an arbitrary system reset, is potentially a pain in the butt. I imagine if you’re running in the cloud, or running load-balanced servers, you’re more immune to this. But we all know some projects aren’t that distributed.

So, what can you do? Fortunately, there is an override. Head into IIS, go to your application pool, and choose advanced settings. Scroll down to the bottom, and you’ll see that “1740″ setting that represents 29 hours. Make that a big fat 0, and your application pool won’t recycle at all due to time. However, there’s probably value in doing it periodically, so if you look a little lower, you’ll see where you can set specific times to recycle. Aim for some off-peak hours, like the middle of the night. 

Weight: 364.5 pounds (start: 431 pounds) - 5.5 pounds/week average BMI: 46.8 (start: 55.3) Body Fat: 40.9% (start: 44.9%) Chest: 53″ (start: 60″) Neck: 18.5″ (start: 21″) Arms (L/R): 19.75″/19.5″ (start: 21.5″/21″) Thighs (L/R): 30″/30" (start: 36″/37″) Calves (L/R): 19.25″/19.5″ (start: 21″/20.5″) Waist: 56.5″ (start: 62″) Hips: 62.5″ (start: 69″)

Current picture:

Starting picture: