Sitecore Tidbits: Rules, Traffic Types, Item Buckets Search, and Refresh WFFM Action

Marco Tana Marco Tana
February 21, 2013
Sitecore , Web Development , Digital Marketing

Today I am introducing a new blog series called Sitecore Tidbits. Every post will be a collection of various topics from simple UI enhancements to complex architectures. There won't be a specific topic per post but mostly a channel for me to share specific experiences with Sitecore development. Once in a while, you'll see other Roundedcube "Cubers" contribute or even have their own post under this umbrella. So, I hope you enjoy it and let us know if there are any specific tidbits you want us to discuss. Also, since I won’t get too deep in any of these, just post a question in the comment section and I'll reply as soon as I can.

Data Fields: Rules

Have you ever used the Rules field? I know that it's a system field, but why not use its conditional power for our own use in our templates? You may want to use it for Geo-IP, where if the user is coming from a specific region, you can redirect them to a specific page. Or send an email if the user is in a specific role. Anyway, if you do use it, here are some options for the field:

- rulespath: specify the path (not ID) where the action and conditions are stored; by default, the Rules field points to /sitecore/system/Settings/Rules/Common (for example, if you want to show rules from the ones you see for conditional renderings, specify this in the field's Source: rulespath=/sitecore/system/Settings/Rules/Conditional Renderings)

- hideactions: true|false; by default, the actions are shown; sometimes, though, you don't want any actions and you just want to let the author select a condition for some specific action that's been predetermined; for instance, the content item is only meant to show up when specific conditions are met;

Just remember that if you have multiple options, separate them with an ampersand (&).

DMS: Traffic Types

Sitecore DMS Executive Dashboard Traffic Types

Have you ever wondered how you can specify which traffic is of specific type? Sitecore automatically identifies simple ones like direct and search engines (see trafficTypes pipeline). But, when you look at the Executive Dashboard or some other reports, you don't really see other ones like Paid, RSS, and Email (see full predefined list at /sitecore/system/Settings/Analytics/Traffic Type). To "enable" it, use campaigns. In the paid campaign, you can specify the traffic type. So when the campaign is triggered (either programmatically or explicitly through URL), the visit's traffic source is then considered as "paid". You should now see visits for this particular traffic type in the executive dashboard and other reports.

Item Buckets: Alternative to simple search

You can use the new API's that comes with Item Buckets for site search. Natively, Sitecore has the SearchManager. With Item Buckets, you have several options: BucketQuery, BucketManager, or item axes extensions. Each of these areis very simple to use but has have powerful options such as pagination, template filtering, date ranges, tags, and several others. You can also extend it with your own extensions if necessary. Since Item Buckets use Lucene.NET, you can easily create your own index using a configuration.

If you use Item Buckets (or even SearchManager) as it is, you will get its powerful indexing and searching capabilities but you will not get typical search engine features such as hit highlighting, faceted search, etc. To get those, install SOLR (it's Java-based so you might cringe a bit) and follow the instructions in the item buckets developer guide.

Web Forms for Marketers: Simple Refresh Action

Here's a simple action that refreshes the page after form submission. Why use it? Well, sometimes you may just want to prevent the "dreadful" repost issue since WFFM uses the postback method for submission. This simple refresh essentially just refreshes the page your form is on.

public class RefreshPage : ISaveAction

{

#region ISaveAction Members

public void Execute(Sitecore.Data.ID formid,

Sitecore.Form.Core.Client.Data.Submit.AdaptedResultList fields, params object[] data)

{

System.Web.HttpContext.Current.Response.Redirect(System.Web.HttpContext.Current.Request.Url.ToString());

}

#endregion

}

If you wish this to be backwards-compatible, make sure to also inherit and implement the now obsolete ISubmit interface.

That's it for this inaugural edition of Sitecore Tidbits. Thanks for reading. And again, let us know if you have any questions or have any topics that you would like to hear about in future posts.

comments powered by Disqus

STRATEGIC PARTNERS