For this post, I’ve tried to specifically focus on development practices. My rankings are my opinion based on a combination of the item’s importance and how frequently it is (or isn’t) done. So without further ado:
Last week I blogged about the power of Sitecore’s HTML Cache. I have found it so powerful that I become frustrated when I come across a component that cannot be cached. In this post, I’d like to introduce a couple of minor enhancements to extend its functionality.
Sitecore utilizes a number of layers of caching to help improve website performance. For the most part, these cache layers have been abstracted away from the developer. However, the most powerful caching layer is almost certainly the most underused layer. And arguably one of the most underused features in the entire platform.
Coveo recently released it’s new Coveo for Sitecore connector and updated Search UI controls. I shared some of my initial impressions after working with the Beta here: http://blog.velir.com/index.php/2013/12/12/coveo-and-sitecore-7-whats-new-and-improved/. I’ve been really excited to dig deeper into this product and have just begun my first full implementation.
A few weeks ago I embarked on my second Coveo implementation. This was to be my first using Coveo 7 and the out-of-the-box controls that come packaged with the Coveo .NET Front End. My previous implementation utilized Coveo 6.5 and the Coveo Web Service.
After following Coveo’s fairly simple instructions found in their online help section: http://onlinehelp.coveo.com/en/ces/7.0/Developer/developing_new_controls_in_visual_studio.htm, I created a custom control but immediately ran into the follow error:
I ran into a little bit of trouble when working with AngularJS routes the other day and thought I would write up a quick post about it. My task was to build an application containing 1 – n number of tabs. When clicking on a tab, some HTML dynamically loads into the view. I decided to use AngularJS routes to handle the tab-switching.
After working on a project that had a very large content migration that saw us publishing and republishing large numbers of items, I began to greatly desire some sort of indicator to see the progress of my publishes. So, I decided I wanted to add a progress bar to the standard Sitecore Publish dialog box.
On nearly every Sitecore site I’ve built, we’ve had a need to display 2 separate sections of the content tree in a single treelist field. The most common use-case being, having a folder to hold components local to the current item, and a shared folder for all items to use. Until now, I had never taken the time to take that code and make it generally applicable to any Sitecore site, opting to port the code from one site to another. So without further ado, the Multi-Root Treelist:
The other day I ran into an odd error while trying to configure the Search Interface for my newly installed Coveo 7 Front-End. After firing up the front-end, I selected ‘Edit this Interface’. Under the ‘Search Hub’ tab selecting the ‘Content’ link caused the following error: Unable to cast object of type ‘Coveo.CES.Web.Search.Admin.AdditionalPagesConfigSection’ to type ‘Coveo.CES.Web.Search.Admin.AdditionalPagesConfigSection’.
Hello Blogosphere! I’m happy to announce the launch of OptimizedQuery. I hope for this blog to evolve quite a bit in the coming months but my main goal is to provide easy to understand answers to technology and programming questions.
My inspiration for starting this blog came from working with a few development products that are, in my opinion, quite under-documented. Many common situations have tripped me up far longer than necessary. If I can save one person the hours I’ve spent looking for documentation that doesn’t exist, I will feel I’ve accomplished something valuable.