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/

Today, we’re excited to announce the launch of a standards effort for Enterprise Content Management systems that Microsoft has been driving with several other major vendors (IBM, EMC, Alfresco, OpenText, SAP, Oracle) called “Content Management Interoperability Services” (or CMIS, for short).

The goal of CMIS is to define a web services standard for interacting with Enterprise Content Management systems like Microsoft Office SharePoint Server, EMC Documentum, IBM FileNet P8, etc.

Why: Integrating multiple ECM systems is hard

We’ve heard from many organizations that want to use SharePoint, but have other ECM systems or applications in place that they need SharePoint to work with. Often these deployments are the result of different business units that deployed different ECM systems or that were “inherited” from mergers or acquisitions, or the organization may be transitioning from one ECM system to another over time.

Having multiple ECM systems introduces integration challenges: Enterprises (rightly) want their users to be able to access and manage all content in the way that best meets their needs, regardless of which system it actually live in. For example, users want unified access to all the content they need to work with on their team site, organizations want their electronic discovery applications be able to find content and suspend its disposition across any ECM system.  But in practice integrating these ECM systems is a challenge because each has its own interfaces. Even though many capabilities in each system are fundamentally similar (e.g. most ECM systems have a notion of “check in/out” & version history, and of different Content Types), and most systems’ interfaces are “open” for anyone to integrate with, tying them together requires integration “connections” for every link between systems. (For example, Microsoft Search Server and Office SharePoint Server support an open “connector” model for indexing content stored in other systems – and Microsoft even provides connectors for some common ECM systems like EMC’s Documentum and IBM FileNet).

This connector approach generally suffers from a few limitations:

• 1) Each link between systems requires a different “connection”: For example, the Enterprise Search connector for IBM FileNet is different than the one for EMC Documentum, and neither one would help an organization that wants to use an IBM or EMC Search product to index content stored in SharePoint.


• 2) Connections tend to be “special purpose”: Because today each point of integration requires additional work, most integration connectors tend to be very specifically-focused on particular scenarios. For example, while the Enterprise Search “connectors” enable Microsoft Search products to index content stored in a Documentum or FileNet system, customers who also want to browse their Documentum or FileNet content on the home page of their SharePoint portal will need to use a separate kind of connector for that (probably a Web Part).

So while today integration is technically possible, it’s not as simple as it could be.

To truly make it simple for ECM systems to interoperate, we need a standard set of ECM interoperability interfaces – that way, every system could support the same interfaces and they could work together without the need for special purpose “connectors” between each pair of systems. And that’s exactly what the CMIS standards effort attempts to define.

What does the CMIS specification define?

The CMIS specification defines a standard “domain model” for an ECM system – a set of core concepts that all modern ECM systems have, like Object Types (which in SharePoint we call “Content Types”), properties, folders, documents, versions, and relationships – and the set of operations that can be performed on those concepts, like navigating through a folder hierarchy, updating a document, etc.

The specification does NOT try to include all the capabilities of an ECM system – because many of these are simply too different between ECM systems. But the specification does attempt to include the fundamental concepts that are (a) relatively common across current ECM systems, and (b) enable the common integration scenarios that we’ve heard from customers to date.

The specification then defines how to bind the CMIS “domain model” to two different web service protocols: SOAP (Simple Object Access Protocol), the web services protocol used by many ECM systems (including SharePoint), and Atom, a newer web services model used in many “Web 2.0″ applications.

You can download a preview copy of the specification here.

Who else is involved in the CMIS effort, and how long has it been going on?

Of course, this isn’t a new problem, and it’s not one that any one company can solve on their own. So back in 2006 Microsoft started working with IBM and EMC on the CMIS effort – since all of our organizations realized the need to enable better interoperability between our systems. Since then we’ve expanded the effort to include several other organizations: Alfresco, Oracle, OpenText, and SAP.

Over the last two years, this group has worked together to create and refine the specification, including validating it using actual prototype code that each company wrote on top of our products.

What’s next for the CMIS specification?

The next step for the CMIS specification to become an open standard that all ECM systems can implement to facilitate interoperability is to transition its development into a public standards organization – and that’s the step we’re taking today. We’re submitting the CMIS specification to a new CMIS Technical Committee being formed in the OASIS consortium, so that all interested parties can join the effort and continue to refine the specification into a final “1.0″ version. (Click here to learn more about joining OASIS Technical Committees). We anticipate that it will take around 1 year for the OASIS Technical Committee to complete work on the final 1.0 version… but from this point onward, the exact schedule will be determined by the committee.

When will Microsoft include support for CMIS into SharePoint (or other products)?

Of course, Microsoft’s goal (which is shared by all of the companies participating in the CMIS effort) is for the CMIS specification is to become the interoperability standard that we can incorporate into our products to reduce the complexity of managing & integrating multiple ECM systems… and today’s announcement is an important step in that process.

As the specification goes through the OASIS Technical Committee process and approaches a final 1.0 version, we’ll provide more information on when and how you’ll see support for CMIS for SharePoint and other Microsoft products.

Ethan Gur-esh, Program Manager.

The SharePoint IT Pro Documentation team has launched a new blog. This is a great place to find out about new and upcoming SharePoint documentation and provide your feedback.  Check it out here:  To the SharePoint.

On the 20th May, we released two hotfix packages focused on Content Deployment.  These packages delivered performance improvements and addressed a number of known customer pain points.  The hotfixes have been rolled in to the Infrastructure Update for Office Servers that was released today so if you’ve been experiencing issues with Content Deployment, download the pack, install it and you’ll get federated search thrown in with the deal.

The updates can be downloaded from the links below:

Infrastructure Update for Microsoft Office Servers (KB951297) – x86
Infrastructure Update for Microsoft Office Servers (KB951297) – x64
Infrastructure Update for Windows SharePoint Services 3.0 (KB951695) – x86
Infrastructure Update for Windows SharePoint Services 3.0 (KB951695) – x64
Infrastructure Update for Microsoft Office Project 2007 (KB951547) – x86

Installation Instructions are available from the links below:

Deploy Software Updates for Windows SharePoint Services 3.0
Deploy Software Updates for Office SharePoint Server 2007 – This article also applies to Project Server 2007, SharePoint Server 2007, Search Server 2008 and Search Server 2008 Express.
Install the Infrastructure Update for Microsoft Office Servers (Office SharePoint Server 2007) (This article will go live later today)
Install the Infrastructure Update for Microsoft Office Servers (Search Server 2008) (This article will go live later today)

 While you are installing the Infrastructure Update, I’d recommend you have a read of the following blog posts on Content Deployment:

1. SharePoint ECM Team Blog on “End to End Content Deployment Walkthrough“


2. Stefan Goßner’s “Deep Dive into the SharePoint Content Deployment and Migration API“


3. Spencer Harbar’s “Ensure your platform hygiene…“

Here is a summary of the Content Deployment issues addressed in the Infrastructure Update:

Incremental bug fixes:

• Incremental import can fail if a feature with a custom content type has been reactivated on the destination.


• Unpublished pages do not get unpublished on the destination.


• Reinheriting permissions on the source does not propagate incrementally.


• Deleting a permission level on the source causes a “Permission level cannot be found.” exception during incremental import.


• Incremental behavior with the Recycle Bin improved. Incremental import fails with a “FatalError: You cannot perform this action on a checked out document.” exception.


• “Violation of PRIMARY KEY constraint” error during export.


• Document “Title” field does not get deployed by incremental deployment in some cases.


• In some cases, making permissions changes on the source or destination will result in a “The specified name is already in use.” error.


• Deleting or renaming an item then creating one with the same name causes incremental deployment to fail.


• Incremental deployment fails when pages have independent permission settings.


• Deleting a file and folder can cause incremental deployment to fail in some cases.

Other bug fixes:

• Removing a User from a group does not propagate to the destination during incremental deployment.


• Some source web settings related to search are not propagated to the destination.


• Content Deployment can time out incorrectly on large deployment jobs.


• Miscellaneous SQL deadlocks.


• Quick deployment jobs behave incorrectly when Variations is used.


• Quick deployment fails when pages are Quick Deployed while the Quick Deploy job is running.


• Running One-time jobs manually can fail.


• In some cases, a content deployment job can get stuck in a “Preparing” state forever.


• Deployment sometimes unghosts items that are ghosted on the source.


• Custom master page settings on the source are not propagated to the destination during deployment.


• Content deployment fails when compression is disabled.

If you want more details on the Content Deployment issues addressed in the Infrastructure Update, visit the Microsoft Help and Support site:

WSS: http://support.microsoft.com/kb/952698/
MOSS: http://support.microsoft.com/kb/952704/

Ryan Duguid
Technical Product Manager
Microsoft Corp