In line with my new company name, I have decided to host my own blog with my new domain name. Interestingly, it’s also running WordPress. I will be moving these old blog entries to the new location.
I thank the crew at SharePointBlogs.com for giving me a (free) venue from where I can contribute to the SharePoint community, in however a tiny way it might be. I do hope to be more disciplined in writing more, especially as we learn more about SharePoint 2010.
Thanks for reading!
Hey everyone in Vancouver (area), next SharePoint User Group meeting is tomorrow (!!). Good techie topic, esp. for those of you who are involved in infrastructure or architecture. Details here: http://www.vanspug.com
I came across this post earlier this month, didn't book mark it, and GMail's web history kind of failed me (only b/c I wasn't exactly sure what search term to use). So, I'm sticking it here. Thanks Zlatan!
How to update/reset the ListView Web Parts on your page: http://dotnet.org.za/zlatan/archive/2009/01/07/updating-listview-web-part-views-in-sharepoint-2007.aspx
I have been negligent in announcing this back in September, when we had our first meeting that piggybacked off of the .NET BC User Group (and thanks to them for that).
Tonight will be the group's third meeting, and the topic will be of intrest to most who need to customize SharePoint's UI. Two of my colleagues from Haba¤ero Consulting Group will be talking about themes, from design to deployment. You can read a more about the talk here, at the VanSPUG site: http://www.vanspug.com.
BTW, the site itself is still work in progress. If anyone in the Vancouver area would like to contribute, please contact me at sherman@habaneros.com.
We have yet to decide on the next topic for December, and group administration stuff (like finding voting for various positions) are slated to happen in January. If you have any comments or questions, please fire them off to me at the above email address, or contactus@vanspug.com.
Both from Andrew Connell.
Title: Implementing a Brand in a SharePoint Server 2007 Publishing Site
Summary: Learn how to select the best approach for implementing a brand in a Microsoft Office SharePoint Server 2007 publishing site.
http://msdn.microsoft.com/en-us/library/dd221375.aspx
Trackback to Andrew Woodward: http://www.21apps.com/agile/unit-testing-sharepoint-getting-into-the-object-model/
I just read this off Michael Ganotti's blog; wanted to post here for my own reference. Search is something that I'm not that close to. Good to see that there are so many useful tools/aids/samples available.
From the project page on CodePlex: The Search Community Toolkit is comprised of a number of tools and code samples that have been contributed to enhance the Microsoft search experience (Microsoft Office SharePoint Server 2007 (MOSS) Search, Search Server 2008 and Search Server 2008 Express).
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:
but instead I needed simply this:
and SharePoint takes care of the rest, building out the path to the appropriate Styles as required, like this:
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! />
sherman