Some Workarounds to Missing PAPI Functions

Stefan writes about why you shouldn't use undocumented APIs (or 3rd party tools that use them) when working with MCMS.

Part 1 - Technical Background
Part 2 - What would YOU do?
Part 3 - How to identify 3rd party products using undocumented program internal intefaces

I can totally understand where he is coming from. There are probably good reasons why the code isn't available in the first place. As Stefan mentioned, using undocumented code without knowing what the limitations are could cause serious problems like database inconsistencies. You definitely don't want to get one of those.

Trouble is, the ability to tailor fit tasks to meet business requirements is often a critical success factor in projects. Having "missing" PAPI methods mean that we don't get to customize that aspect of the system and therefore incur administrative overheads. If we can't automate it, someone's got to do the job. Of course, having a person/team dedicated to the overall administration of the site is ideal, but even if you have the delight of having people to help, it's nice (sometimes important) to automate some tasks.

The good news is: there are workarounds. Though not for all missing features and even so, not all gaps are filled 100%. Nevertheless, its better than putting critical systems at risk. Here are some such workarounds:

• Creating custom channel properties. Use shadow postings to store channel custom property values or store them in a separate database table using the channel's GUID as the primary key.
  
• Managing users in rights groups. If you're using the MCMS Enterprise edition, you could create NT Domain groups and use ADSI scripts to programatically assign users here.
  
• Assigning rights groups to channels, resource galleries or template galleries. Nothing much can be done here (none that I know of). But you could work with the idea that new container items inherit the rights groups assigned to its parent.
  
• Moving channels, template galleries or resource galleries. Moving channels is a big thing because it means changing the friendly URLs of all postings within it. But if you really need to do so, create copies of all container items and delete the originals (Note: The PAPI provides postings and templates with a .MoveTo() method which you can use). However, the drawback of this approach is that the "moved" container will have a new GUID. Alternatively, if keeping the GUID is important, instead of deleting the originals you could mark them as hidden (thereby potentially bloating the system with lots of hidden channels) and write code to deal with requests to these hidden items.

This list is by no means exhaustive! If you know of other creative workaround solutions (legit ones, of course), do post it :-)

HyperLink Dependancy Report Generator

Authors often ask for a list of postings that link to a particular posting/channel before deleting or moving it. Here's a sample that I've written to help address this. It's a simple console application that scans all placeholder content for hyperlink. If it finds that the address belongs to a posting or channel, it records it in a CSV file.

Download the sample

MSDN book excerpt: "Enhancing Performance with Caching"

Microsoft has published a chapter of the book, Building Websites with Microsoft Content Management Server, on MSDN!

It's about enhancing the performance of your MCMS website with caching. It introduces the different caching mechanisms used by MCMS and demonstrates how you can apply output caching to postings, channels and even controls. Joel and Stefan wrote most of this chapter, and they did a really great job with it!

Read the chapter here.