Sitecore has two kinds of item XML representation, or flavors if you will.

Serializer XML is the heavyweight format, containing everything Sitecore needs to know to get the item from one solution and paste into other: all attributes, field values in all versions and languages. It is used by the packager.

To get serializer xml programmatically:

item.GetOuterXml(deep);

XSLT XML is the internal interpretation that is fed to XSL renderings (tranformations). This is the lightweight brother, containing only item attributes and field ids. No field values, only the current version and language. You would want to know how it looks like if you code XSL renderings.

To get XSLT xml programmatically:

ItemNavigator navigator = Factory.CreateItemNavigator(rootItem);
writer.Write(navigator.OuterXml);

In the next (3.0.13, soon to be released) version of demo site, we have added the option to output item XML in both flavors to demonstrate what it feels like:

http://<demositeurl>/?xml=    => Serializer XML flavor of the current item (no children)
http://<demositeurl>/?xml=&deep=true    => Serializer XML flavor of the current item and all descendants
http://<demositeurl>/?xml=&xslt=true    => XSLT XML flavor of the current item and all descendants (always 'deep')

Thanks to John West for the idea.

The Email Alert add-on allows the visitors of a web site to subscribe to different areas of interest and receive a notification when a certain article is updated.

Email alert will be included in the next build of the SC Printers Inc demo site, and below is the quick installation walkthrough. The module requires Sitecore MailingList to work, so I assume you have it working (i.e. the mails are sent out OK)

Install the package

Download and install the package, update configuration according to readme.

Define target groups

The package will install /sitecore/content/Target Groups branch. We want the users to be able to subscribe to news and product areas; it should be possible to subscribe to monochrome and color laser printers separately. With that in mind, define the following structure instead of the sample one:

Update site templates

Next we need to update templates of the product and news items; add /sitecore/templates/Email Alert system/EmailAlert.Target Groups template as a base template to Product and News item templates:

This will add the Target Groups field to products and news.

Bind items to target groups

Now when relevant templates have the Target Groups field included, use it to define relationship between items and target groups.

It's simple for news: find the News Item template, and edit the standard values so that 'News' checkbox is checked in target groups field:

Because products have two separate branches (monochrome and color) that are based on the same template but should belong to different target groups, we need to set the checkboxes manually:

Then update product masters to make sure that new items are automatically set up in future.

Add the subscription page

The subscription page will allow extranet users to subscribe to target groups they are interested in.

Email alert installs a sample 'Subscribe' sublayout. Pick a page and setup presentation to add the sublayout:

With Printers Inc, the page is tweaked to match the site design and the ability to create new users is removed:

Now extranet users can use the page to subscribe to one or more topics.

See it working

Now the module is finally set up. Next time editor wants to update the product, she opens Content Editor, updates some details:

and then clicks save:

Because laser printers are watched by email alert, comment notification pops up and editor enters a brief description of the change.

Nothing happens until the product is published; after the publish email agent kicks in and sends notification emails to all users subscribed to particular target group (Product -> Laser):

The templates are customizable at /sitecore/system/modules/EmailAlert/Settings.

Everyone knows that it's bad-bad-bad to substitude headers with text styles. Using headers, however, is good-good-good because search engines love them (and for semantics, which always loses to search engines).

It's easy to remember about them in 'document-like' pages with clear title, chapters, etc. On navigational pages, headings are probably omitted more often.

For SC Printers Inc demosite I believe it means that following headers should be added (among others):

(front page and section pages)

(product list)

Could this somehow backfire?

It's a bad practice for a page to link to itself, unless its an anchor. It is a small difference, but it's all about the details, isn't it?

Preferably, both markup and visual appearance should be different. For demosite, it means:

instead of

instead of

(although I don't think the site needs a third link home anyway)

instead of

In xslt, it's as simple as a check for "@sc_currentitem/@id = @id" or "@sc_currentitem/@id = sc:GetLinkItem(...)/@id".

Below is the difference between xslt of vertical menu (the most complex of 3 changes). Before:

<a href="{sc:path(.)}" class="text_2">
  <!-- link content we don't want to duplicate -->
</a>

After:

<xsl:variable name="tagname">
  <xsl:choose>
    <xsl:when test="@id = $sc_currentitem/@id">span</xsl:when>
    <xsl:otherwise>a</xsl:otherwise>
  </xsl:choose>
</xsl:variable>

<xsl:element name="{$tagname}">
  <xsl:attribute name="href"><xsl:value-of select="sc:path(.)" /></xsl:attribute>
  <xsl:attribute name="class">text_2</xsl:attribute>

  <!-- link content we don't want to duplicate -->
</xsl:element>

Wouldn't it be nice if <sc:link /> could handle it by itself? It is a breaking change, unfortunately.