The Sitecore Page Editor: Unleashed

Today I had the honor of presenting once again to the Sitecore Users Virtual Group, this time on how to best utilize the Page Editor, as well as some helpful extensions.

The Webcast

The Example Code
You can download the full Visual Studio Solution used for this demo, including a version of the Dynamic Key Placeholder prototype updated for Sitecore 6.5 Update-4. The solution also includes TDS projects with the items needed to run the site.

The Page Editor: Unleashed Source Code

Other Helpful Resources

Sublayout Development with Custom Items and Scriptlets (as seen in example code)

StackOverflow: Create Content Folder

Converting Data Source Paths to IDs (John West)

Add Presentation Component Data Sources to the Links Database (John West)

Handling Presentation Component Settings (Adam Conn)

Dynamic Placeholder Keys (Original Article, including working pre-6.5 version)

Layout Deltas What Ifs (Adam Conn)

Programmatically Updating Layout Details (John West)

Advanced Database Crawler (Alex Shyba, as referenced with indexing data source content)

Cropper (screen capture tool)

Read more... Comments (3)

TDS and Sitecore.* DLLs

One fail-safe feature of Team Development for Sitecore that has bit me a few times is its prevention of Sitecore.* DLLs from copying to your web root during a build. Though I appreciate TDS lookin out, there are times when you have non-module libraries, or modified Shared Source libraries, that you do want deployed on build. To work around this, you can utilize the BeforeFileReplacements build target. Place the following in your TDS csproj, just before the closing </Project>, and edit DeploySitecoreBinaries as needed for your assemblies.

<Target Name="BeforeFileReplacements">
    <!-- restore certain Sitecore.* DLLs that TDS does not copy -->
    <!-- BeforeFileReplacements will be called after TDS has deleted Sitecore.* from its Output, but before it deploys -->
    <ItemGroup>
      <DeploySitecoreBinaries Include="$(SourceWebPhysicalPath)\Bin\Sitecore.SharedSource.Search.dll;
$(SourceWebPhysicalPath)\Bin\Sitecore.Sharedsource.dll;
$(SourceWebPhysicalPath)\Bin\Sitecore.Sharedsource.PartialLanguageFallback.dll;" />
    </ItemGroup>
    <Copy SourceFiles="@(DeploySitecoreBinaries)"
DestinationFiles="@(DeploySitecoreBinaries->'$(_OutputPath)bin\%(RecursiveDir)%(FileName)%(Extension)')" />
  </Target>

Read more... Comments (4)

Sitecore Workflow Emails with rss2email

One of the coolest features added by Sitecore way back in 6.2 was Workflow RSS Feeds. My WeBlog cohort Alistair Deneys discussed them a bit back in 2009. I even recall at Dreamcore 2010, Michael Seifert feigning the approval of a press release onstage, using a workflow RSS feed on his smartphone. You can even setup RSS feeds in Outlook, which is a great option for PC users who deal with that wonderful piece of bloatware on a daily basis.

Workflow RSS feed links in the Workbox. You can see we're very busy moderating comments here at Techphoria414.

The content and functionality of the RSS feed is great -- it would take a lot of effort to reproduce it in a custom email action. The example below doesn't even show the field-by-field change comparison that's included when an item is updated.

Despite the possibilities with RSS, I feel this functionality is really underused. RSS after all these years is still a bit foreign to many non-technical users, and the reality is that in a business setting people aren't paying attention to RSS feeds in the same way they do their email. We even encountered a customer recently who couldn't add RSS feeds to their Outlook client because of a network group policy! So we set out to find a simple solution that allowed us to securely turn the content of the RSS feed into emails for our users. We found it in a cool little tool called rss2email.

Rss2email does just what it says -- translates an RSS feed into email. It's a small python script which you configure from the command line, then run on a scheduled basis. It's pretty simple to set it up for Sitecore Workflow RSS:

1. Download and Install Python 2.x
2. Download and unzip rss2email to a location of your choice, e.g. c:\rss2email.
3. Copy config.py.example, rename it to config.py and edit as needed. The settings I changed were:
1. DEFAULT_FROM (something like sitecore-no-reply@mydomain.com)
2. FORCE_FROM=1 (to ensure the default from address is always used)
3. SMTP_SERVER (obviously)
4. Edit r2e.bat to include an absolute path to python.exe. You could also place python.exe in your PATH.
5. Execute "r2e new <youremail>". This just gives r2e a default email address and creates its data file.
6. Get the URL of the workflow feed you wish to have emailed. Note: The feeds you pull from the Workbox are specific to each Sitecore user! Be sure to get your user to provide their own feed URL.
7. Execute "r2e add <feedurl> <useremail>". You likely will need to put the feed URL in quotes.
8. If you have a lot of existing items in the feed and want to avoid sending the user a slew of emails on first run, execute "r2e run --no-send"
9. Create a windows scheduled task that executes "r2e run" on a regular basis.

Your user will now receive an email for each new item entering the Workflow or Workflow State. I'm not giving the rss2email setup process justice, so be sure to reference the rss2email Getting Started guide. Once you have it running, the results are pretty great. In fact, the above screenshot was actually taken from my Google Mail account, not an RSS reader.

We have a small number of users who need these emails, so maintenance of r2e settings is not a huge issue. On a larger install, it would be interesting to find a way to adapt rss2email, or automate the addition/removal of users and their feeds. But quick and easy is what we were looking for, and this certainly delivered. Big thanks to Lindsey Smith for this tool.

Read more... Comments (2)

Glimpse Debugging for Sitecore

While I have my gripes about the implementation of Sitecore.Context as essentially a repository for global variables, there is no doubt that the concept provides a great deal of the flexibility of the platform. But this flexibility can also create headaches in debugging. Context item, database, language, device... and further how they're used to construct and apply renderings. There's a lot going on in constructing just a single page. How can we securely expose information about the context to help debug published pages, even in production?

Glimpse is a debugging tool which espouses that "what Firebug is for the client, Glimpse does for the server." It securely and transparently adds a client-side debugging interface to your output pages.

Out of the box, Glimpse provides all kinds of information on what's going on with the server side of your ASP.NET Webforms or MVC application. What if we could extend this UI to include information about the Sitecore Context and other page information? The Glimpse site already provides a lot of great information on what Glimpse does and how to install Glimpse. It also provides a nice tutorial on its dead-simple plugin architecture.

To create a Sitecore plugin for Glimpse:

• Install Glimpse using NuGet.
• Create a new class library in your solution.
• Reference Glimpse.Core, System.ComponentModel.Composition, and System.Web assemblies
• Create a new class that implements IGlimpsePlugin
• Mark your class with the attribute [Glimpse.Core.Extensibility.GlimpsePluginAttribute()]
• Implement the GetData method to return a List of object arrays containing your debugging data
• Implement the Name property to return the string "Sitecore"
• Drop your new assembly into your Glimpse-enabled application

The result may look something like this:

click to enlarge

Download an example Glimpse plugin for Sitecore

You can either integrate this project with your solution if you'd like to make modifications, or include the built assembly as-is in your Glimpse-enabled project. It provides some basic information about the page, but I could certainly envision extending this to include more information, akin to the Sitecore Debug view.

Read more... Comments (0)

Changing Item Templates With Sitecore PowerShell

So I'm starting to explore the Sitecore PowerShell Console module from Adam Najmanowicz, and I think the community could benefit from a few more example scripts. I'm working on some enhancements to WeBlog that will allow you to more easily use different templates for each blog, which required me to change the template of a large number of entries. PowerShell made this easy once I figured it out:

$master = [Sitecore.Configuration.Factory]::GetDatabase("master");
$entryTemplate = $master.Templates["YouPhoria/Blog/Entry"];
cd master:\Content\Home\Blog\;
Get-ChildItem -recurse | ForEach-Object { if ($_.TemplateName -eq "BlogEntry") { $_.ChangeTemplate($entryTemplate) } };

And there you go.

Obligatory note: You could also do this using Revolver, a command prompt module from my WeBlog partner in crime Alistair Deneys.

Read more... Comments (2)

T414 Sitecore Best Practices Part 3: Sublayout Development with Custom Items and Scriptlets

The T414 Sitecore Best Practices Series is a screencast overview of the foundational pieces we use at Hanson Dodge Creative in our Sitecore development projects. Part 3 demonstrates our approach to creating Sublayouts using custom item classes (generated by the Custom Item Generator shared source module) and scriptlet-based user controls for efficient, clean Sitecore development that's Page Editor friendly. I've outlined this approach in a previous post as well.

Part 1: Introduction to TDS is available here.

Part 2: Solution Structure and Working with TDS is available here.

Read more... Comments (0)

T414 Sitecore Best Practices Part 2: Solution Structure and Working with TDS

The T414 Sitecore Best Practices Series is a screencast overview of the foundational pieces we use at Hanson Dodge Creative in our Sitecore development projects. Part 2 dives into the specifics of Visual Studio solution structure, TDS project configuration, and using TDS.

Part 1: Introduction to TDS is available here.

Part 3: Sublayout Development with Custom Items and Scriptlets is available here.

UPDATE:
Sean Holmesby of Igloo Digital has a nice series of posts that also get into some details of TDS use and configuration, including some known "gotchas" that you may run into.

UPDATE #2:
If you're having trouble getting your Sitecore.* DLLs to copy on build, check this out.

Read more... Comments (3)

T414 Sitecore Best Practices Part 1: Introduction to TDS

Over the next 3 days I'll be posting a series of screencast videos that demonstrate the standards and best practices we've developed for Sitecore projects at Hanson Dodge Creative. The foundational pieces of our standards include Team Development for Sitecore (TDS), the Custom Item Generator shared source module, and scriptlet-based sublayout development. Part 1 of the series is a shorter video providing a high-level introduction to TDS and the separation of development and web roots on your filesystem.

You can also view the Prezi that I created for this screencast.

Part 2: Solution Structure and Working with TDS is available here.

Part 3: Sublayout Development with Custom Items and Scriptlets is available here.

Happy Sitecoring,
Nick Wesselman / techphoria414

Read more... Comments (4)

It's On: WeBlog Summit at Sitecore HQ

I'm excited to announce that in less than two weeks, I will be representing Hanson Dodge Creative at the WeBlog Summit in Copenhagen, Denmark at Sitecore HQ. Mark van Aalst, Alistair Deneys and I have been working on WeBlog (formerly EviBlog) for over two years now, each from our own corner of the world. Now, for the entirety of the third week of October, we'll be together in the same place, working toward our goal of creating world-class blogging functionality for Sitecore CMS. We are very grateful to Sitecore for hosting us and providing us access to the great minds they have amassed.

If you've ever had a feature idea for WeBlog, now is the time to let us know! Post your ideas to the WeBlog Forum on SDN.

- Nick Wesselman
@techphoria414

Read more... Comments (0)

A Failsafe For non-Debug TDS Builds

Another advantage of Team Development for Sitecore is that deployment to your various environments can be configured as part of the Solution's Build Configurations, allowing you to easily deploy either right from your desktop or as part of an automated build process. The side effect of this is that if you don't remember switching to say, your QA server's build configuration, you can easily deploy in-progress code to an environment that's not your local machine. (I will not confirm nor disconfirm I've done this.) Though you probably don't want your production environment fully configured in TDS anyway, even a deploy to a QA or UAT server would be enough to get someone knocking on your door asking why "everything is broken." Read more... Comments (1)