There isn’t a week that goes by where I don’t get an email asking me this very question.  More often than not, its because someone has been using the Content Editor Web Part (CEWP) when they should have been using the Publishing HTML field type.  This mistake typically goes unnoticed until a customer needs to roll back to a previous version of a page or when they run a content deployment job.  So what goes wrong?  Well, the CEWP doesn’t store version history, it doesn’t participate in any publishing approval workflow and it does store absolute URLs rather than relative URLs.  The first problem means you’ll have to go to site backups to get access to previous versions of content, the second problem means that users will see updates to the content in the CEWP even if an editor hasn’t approved the page for publishing and the third problem means that all your hyperlinks will resolve to the wrong address (e.g. http://staging.adventure-works.com/ vs http://www.adventure-works.com/).

Thankfully, all of these problems can be avoided by using the Publishing HTML field type.  I’ve talked at length with Andrew Connell (MVP) about this and I know it’s something he is passionate about so I asked him to write up a guest post to explore the topic.

Ryan Duguid
Technical Product Manager
Microsoft Corp

Andrew Connell on Field Controls and Web Parts

One of the most common problems I see with people developing Publishing sites stems from the lack of understanding in the core differences between Web Parts & Field Controls and when to use them. Many a consultant have dug a deep hole in this area. My goal in this post is to make you aware of the differences to make educated decisions when selecting one over the other.

What follows is a discussion with respect to MOSS 2007 Publishing sites (aka: WCM sites), but all the concepts apply to any Windows SharePoint Services 3.0 based site.

When creating editable content regions on a page layout, enabling content owners to add and manage their own content, developers/designers are presented with two options: field controls or Web Parts. These two options are very different and Publishing site developers should be aware of the differences. The fundamental difference comes down to where the data is stored.

Web Parts
Web Parts come straight from ASP.NET and their data is stored in a personalization store. Microsoft was nice and baked the personalization store into the site collection’s content database. Data in a Web Part is stored within the context of the PAGE (i.e.: URL) & the user (which could be the shared user or a specific person). This does allow the content in Web Parts to be uniquely personalized by authenticated users.

In addition, developers and designers can only create Web Part Zones on the page layout. Content owners can then put any Web Part in the zones and any content within them.

Field Controls
Field Controls are much different from Web Parts. They are more like windows into list items. A field control pulls data (in display mode) from a particular column in a list item and writes back to that column in edit mode. Pages in a Publishing site are stored as items in a list; the Pages list. Because they are in a list, they can leverage all the benefits a list has to provide, but visioning & history is the most important here. Just keep one thing in mind: field controls are simply gateways, or windows, to the data.

When a developer places a field control on a page layout, they have the ultimate control of where it is placed on the page and any rules such as if the content owners can insert tables or images into the content. The content owners can only work within the rules defined by the developers.

What is the significance?
Great question! From my experience, MOST customers (90%+) who are rolling out a Publishing site, or Web-based content management systems such as MOSS 2007 WCM, are doing so because the following aspects are important to the project:

• Consistent lookand feel (aka: a corporate brand)


• Empower content owners & subject matter experts (SME) to maintain the content


• Free up IT staff from updating content submitted by SMEs


• Structured organization of contentand a versioned and/or historical record of the content

The challenge here is that Web Parts pose a problem with this approach. Because their data is stored in the ASP.NET personalization store in the context of the page (it’s URL mind you) & the user. However with field controls, the data is saved with the page’s list item. This means that when the page is updated, a new version is created and the old data is retained with the page.

Another challenge is with URLs in the content… especially relative URLs. Take the Publishing HTML field type & the Content Editor Web Part (CEWP). The CEWP does not store relative URLs… it stores only absolute URLs. Even if you enter a relative URL into the editor, it will be converted to an absolute URL. The rich text editor that the Publishing HTML field type is tied to does not convert relative URLs to absolute URLs.

If structure and history is important on your site, you should ONLY consider field controls for your content. If you want to have a more relaxed authoring environment where structure & history isn’t important, Web Parts are better. What if structure & history is important… does it ever make sense to use Web Parts? Sure! Use them for providing functionality like stock quotes, consuming news feeds, or rolling up content (as in the Content Query Web Part). In this scenario, the only data that’s stored is configuration data… not true content.

To summarize: the content in Web Parts is not versioned and there is no history, but the content in field controls is versioned & a history is retained (provided the Pages library has versioning enabled, which it does by default).

-AC

Andrew Connell
MVP Office SharePoint Server
www.andrewconnell.com/blog
Sr. SharePoint Instructor – Ted Pattison Group
http://www.tedpattison.net/

Hi, I’m Cern McAtee, a technical writer for Office SharePoint Server 2007. I’m pleased to announce that the Office SharePoint Server 2007 content team and the Global Readiness team have combined efforts to write and publish a new walkthrough guide for content deployment: End-to-End Content Deployment Walkthrough.

What’s covered

This downloadable guide is aimed at IT pros planning to use content deployment with their enterprise sites using Microsoft Office SharePoint Server 2007. The guide takes you through the steps for setting up source and destination site collections, creating a deployment path and job, and then running the job to see how it populates the destination site collection with the content from the source site collection. One important thing to note when it comes to doing content deployment is that when you first set it up, the destination site collection must be empty. You can create the destination site collection using either the Blank site template, or by using the Stsadm createsite operation to create an empty site.

In addition to the walkthrough, we have also published a set of topics about Administering Web content management that cover publishing and content deployment operations. These topics are intended for IT pros who manage publishing and content deployment for their enterprise sites. More WCM topics that cover cache settings and profiles, document conversion, and variations will be published soon.

Send your feedback

We’re very excited about publishing this walkthrough guide and the new WCM content, and we’re especially interested in your feedback on this new content. There are three ways you can provide feedback on this content: First, in each topic you will find a “Click to Rate and Give Feedback” control with a text box for supplying feedback. Second, you can send us mail at o12ITdx at Microsoft.com. Third, you can use the “Leave a Comment” interface in this blog to provide comments, either about this blog entry or about the newly published content.

We look forward to hearing from you and to continuing to improve this content in partnership with you!

Thanks,

Cern McAtee
SharePoint Enterprise Solutions content team