Enhancing the Chrome For Sitecore MVC Placeholders, Renderings & Edit Frames
While working with Sitecore’s Experience Editor (formerly Page Editor), I ran into a frustration with the placeholders. When they’re empty, you have that nice open area with the “Add Here” button to put a rendering in place. After that first rendering, however, I found that it wasn’t easy to get back to the “Add Here” buttons without using the hierarchy button. Once or twice was fine, constantly was annoying.
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:
I’ve posted the source code on GitHub for folks to look over. Hopefully this helps to enhance your Experience Editor usage!
I started down this path with a simple frustration: Sitecore DLLs. Of the three .NET CMSes I deal with regularly (Umbraco, Episerver, and Sitecore), Sitecore is the only one that doesn’t distribute their product via NuGet. (In fact, the update procedures for Sitecore are very burdensome, but that’s a whole other story.)
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.
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.
A note on something I ran into yesterday. I’m using web deploy to publish from Sitecore to my local environment (to simulate eventual real-world build scenarios), and I found that out of the box, the process will override the security on the Website folder, setting IUSR and Network Service accounts to read-only access. These have to remain as Sitecore sets them for certain functions to work, including using the update installation wizard.
After you create a publish profile, go to the Properties/PublishProfiles folder and open the .pubxml file. At the end of the PropertyGroup node, put this in:
I ran into this yesterday, and after getting a little help from the TDS documents and their support, I have a solution to share.
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.
Exploring Episerver Part 1.5: Working Locally, Database, Source Control, and Configs
A couple of start-up thoughts I had for a Friday evening...
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.
Finally, with the config files, I always use config transforms to make changes beyond the base file. That way, if you do any upgrades in the future, you can just overwrite the base config with the new base, and your changes will fall into place. I suggest grabbing the SlowCheetah Visual Studio extension to do your transforms; once you use it, it’ll add a NuGet reference for you. Also, take advantage of having both build-level and publish-level transforms; you can make changes based on Debug and Release states for building, then modify it further based on the publish profile you use. Note that if you need to create web.config transforms based on publish profiles, you’ll need to go into the Properties menu, select the specific profile, and right-click to choose “add web.config transform” (don’t select “add transform” or you’ll get transforms based on the publish profile itself!).
Now that the Episerver Ascend conference is done in Vegas, and I had a good time meeting other developers and fellow EMVPs, I figured this would be a good time to start teaching myself Episerver. And since Sitecore is now my primary day job, it’ll be a night task that I’ll be fitting in as I can.
I’ve decided that I need a website of my own, and I was looking for a new host, so I decided to combine all this into a starting Episerver project. So here we go!
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!
Meantime, if you have questions, you can ask here (I’ll do my best to answer), check out Episerver World for help, or post on Twitter using the hashtag #EpiDev. That’ll usually get some attention from folks, including other EMVPs, that might be able to help you. I always recommend, if you have a longer question, to post it on the forums at World and then tweet the link out.
I just found out there’s a zip-line at this conference event I’m going to in November. I checked the website of the place, and it doesn’t specify a weight limit. But I consider it more motivation to get under 300 by that point to give myself a better chance. :) In other news, the 340 barrier has been crossed. :)
This was a question I asked about, and I thought I’d share it around. I’m sure many EPiServer developers are on Twitter (if not, you should be) and see the update notices from Allan Thraen (if you don’t follow him, you should). You can head into Visual Studio, fire up the NuGet Package Manager, and grab those updates from the EPiServer NuGet feed. (If you haven’t tried Visual Studio 2015 yet, I recommend it...get the Community edition since it’s free and seems to have most of the power of Professional, but you’ll love the new NuGet Package Manager).
So I go in there, and I see those updates and grab them. But then on the nugget.org main feed, I see many other packages crying out to be updated. Entity Framework, Newtonsoft.Json, and others that want me to help them be current...
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.
Glad to see EPiServer was already thinking what I was thinking, though!
IIS Application Pool Recycling - I Did Not Know That!
So I’m definitely classifying this in a “I did not know that” category, and after talking to one of my colleagues, he didn’t know it either. So, it makes for a good blog! (And for those who’ve followed my blog, a change of pace from the weekly weight loss report.)
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.
It’s really going to depend on your business model and audience, so plan accordingly!
Yeah, we forgot to do pictures and measurements again, although my new profile picture is one I took the Monday after weigh-in. So that’s me over 90 pounds and five months later...go back and check out the first post in this series to see where I started. I actually found a picture my wife and I had taken at Morton’s back on Valentine’s Day in Atlantic City, and it’s insane how different we both look now.
The weekend did get a little out of control, so I’m compensating with some liquid days...no salad, just protein drinks until dinner, and making sure I take in water. It seems to be helping. The crazy thing is, I’m really losing 7+ pounds a week at times, I’m just putting myself in a hole to start! Gotta stop doing that...after the beach vacation anyway. :) We’re going to do one cheat day to enjoy the beach fare, but otherwise the plan is to haul down the protein powders and bars.
With a speaking spot at the EPiServer Ascend conference locked in, I’m setting my goal: get below 300 pounds before I leave on November 7. That 15 more weigh-ins to go. I need to hit a little more than 3 pounds a week between now and then to do it...I’m going to Vegas under 300. Positive mental attitude!
We didn’t have an official weigh-in last week, so we’re moving right into the end of month 4 on the diet. And then I found I’m falling behind, so I’m going to catch up with this past week, and resume measurements at the end of month 5.
Good week, just under the 5 pounds I was aiming for. I think decreasing the amount of salt involved, and not downing a ton of water right before bed, helped out this week.
Buckle-down time. With a beach vacation at the end of August, I want to push ahead and drop as much as I can before that. So no more breaks between now and then, it takes too long to recover. And even when we’re at the beach, I think we’re planning for one day to enjoy the local cuisine, but otherwise sticking to the plan.
What’s amazing is, despite the little breaks, if I can maintain a 5 pound/week loss average, by the time we go to the beach I’ll be 50 pounds down, and by the time of the EPiServer conference in Vegas in November I’ll be 100 pounds down, from now. So the late-August goal is now 312.5, and the early-November goal is now 262.5...I haven’t been that light probably since high school.
Month three is in the books, which means it’s time for another full set of measurements. The biggest lesson this past month is throwing in “free” meals is a bad idea. It takes a while to recover from it...I think there’s an expectation of how under a “normal” diet, a shock to the system can actually cut weight, but with this diet, it doesn’t really work. The other thing is finding some more cost-effective replacements for things...we hit up the local Vitamin Shoppe and took in the IP vitamins (multivitamin, potassium, omega-3, and calcium-magnesium) and they found us some near matches; in the case of the multivitamin, more tailored to what men or women need.
