I came across this in late 2007, and forgot to blog about it. Just catching up, and wanting to post it for reference.

While working with page layouts in MOSS, a few of use sometimes encountered a strange message when we requested the page:

Only Content controls are allowed directly in a content page that contains Content controls.

We'd verify that there wasn't anything in our page layout(s) or master page what was not consistent with ASP.NET syntax. Sure enough, everything in the page layout was sitting (properly) inside an ASP Content server control.

Rather than repeating all the things we looked at to try to resolve the issue, I point you to Rich Finn's article, which ultimately helped me figure out what was going on (see his update at the end of the post).

In a nutshell, ensure your page layout markup uses this casing for all Content web server controls:

<asp:Content . ></asp:Content>

and NOT this:

<asp:content . ></asp:content>

Note the capital "Content" v. the lower case "content" in the second instance. That one issue caused SharePoint to freak out.

I haven't fully confirmed whether or not the last set of asp:Content controls was the issue, or if it was an inconsistency with the opening/closing tags. Nor have I found out what it was that made the controls lower case (could be Visual Studio copy/paste settings), but to be safe, just make sure it's all capitalized and you won't encounter the grief that I did.

There is one other post out there by Waldek Mastykarz which mentions an issue with the PlaceHolderPageTitle placeholder. I haven't confirmed that the PlaceHolderPageTitle is in fact the root of all evil, but he seems to indicate a similar symptom if you don't include it in your page layout. In my tests, I did NOT have the PlaceHolderPageTitle, and my page layout still worked correctly after I fixed the case issue for the Content web server control.

I hope this helps you.

Final Note: I encountered this problem in November 2007; I do not remember whether or not I had SP1 installed at the time. If I have a chance to test this again, I will update this post.

[Update: December 2008]
It's been a while since I've had to do any custom SharePoint dev, but I sure am glad I was able to spot the error when I saw the "parser error" message again (when ASP.NET error messages are enabled).

First update: I can confirm that the issue still exists in SP1.

Second update: as I suspected back then, it's the very last Content control that causes the error. So make sure at least the last Content control is properly cased.

(Not in my native Windows environment anyway.) 

I have a few spare moments at work right now. I've got Windows Server 2003 x64 with a local installation of SharePoint as my development environment. (You can debate the merits of this v. using a VM, but I prefer to have direct access to my hardware.) I wanted to check out the VS extensions, so I can quickly do "one-offs" instead of creating full solutions everytime.

I downloaded the extension which can be found here. Tried to install, and boom!

"This product cannot be installed on 64-bit versions of Windows." [OK]

What! No! Not OK. Some digging, and reading the comments on the SharePoint Team Blog, I came across this post: http://blogs.msdn.com/mattbremer/archive/2008/06/17/why-do-visual-studio-extensions-for-wss-3-0-not-support-64-bit-platforms.aspx

Heavy sigh… time to take a closer look at Ted Pattison Group's STSDEV…

I have a custom publishing site definition. It was, of course, based off the default publishing site definition. I re-organized some features around, and added custom versions of required features just so I could control everything a little more to my liking. Anytime we do this, however, we run the risk of "what did I break?" syndrome.

One of my clients was using the Content Editor Web Part on one of her page layouts (instead of using a RichHtmlField – long story). She noted that she could not select the "Use Predefined Table Format" in the Table Editor web dialog. Hmmm… I didn't do anything specific to disable that capability, so I needed to do some digging.

Since I was using a custom publishing site definition, I needed to determine if this behaviour was happening with the default Publishing Portal definition. Sure enough, adding a CEWP to the home page of the Publishing Portal yielded the same effect: I could not use the predefined table formats. I then check the Press Releases default page, which does have a RichHtmlField for me to play with. I can use the predefined formats here. I proceeded to add a CEWP to the zone at the bottom of the page, and here I can also use the predefined formats. Interesting…

I fired up my favourite search engine, and came across this posting from Microsoft: How to enable the "Use Predefined Table Format" setting when you use a Windows SharePoint Services template in SharePoint Server 2007. Cool! But note the location of the CSS: /_LAYOUTS/1033/STYLES/HtmlEditorTableFormats.css. In my case, I have the French language pack installed, which means I have to account for the 1036 LCID also.

I checked the master pages and page layouts that PublishingLayouts feature use, and note that there is not a reference to that CSS. Nor is it in the page layouts found in the PublishingResources feature. What gives? What's the correct syntax?

No matter. I'll just add a link to the CSS by building out the path to the right LCID folder, using something like System.Threading.Thread.CurrentThread.CurrentUICulture to get the LCID. After some frustrations (which I won't get into here), I quickly realized that this would not work in my scenario (Canadian English is not 1033) either.

I looked at the source code for my out-of-the-box publishing portal (the Press Releases page). I noticed that core.css also comes from the LAYOUTS/1033/Styles folder. Some more digging, and I realized that I did not need to speficy the full path, like this example taken from BlueBand.master:

• <SharePoint:CssRegistration name="<% $SPUrl:~sitecollection/Style Library/~language/Core Styles/controls.css %>" runat="server"/>

but instead I needed simply this:

• <SharePoint:CssRegistration name="HtmlEditorTableFormats.css" />

and SharePoint takes care of the rest, building out the path to the appropriate Styles as required, like this:

• <link rel="stylesheet" type="text/css" href="/_layouts/1033/styles/Htmleditortableformats.css?rev=guYGdUBUxQit03E2jhSdvA" />

Here is a great post which talks about what's going on, and what rendres HtmlEditorTableFormats links. It explains why I could not find it in any of the master pages or page layouts: the RichHtmlField web control inserts CSS links to HtmlEditorTableFormats.css and HtmlEditorCustomStyles.css OnLoad() . <groan! />