Better SiteStudio "Best Practices" - Secondary Pages

I've read a few blogs, webcasts and discussions about "best practice" for SiteStudio. They all seem to talk about the same obvious ideas. What I've been thinking about are some real-world issues and solutions, especially for scalability. Here's two I'm playing with now regarding secondary pages.

1. Use Primary Pages sparingly - rely on Secondary Pages
Forgive me for starting with a simple one... but I'm seeing websites where every page is generated from a primary layout. Yuck. This means every new page will need a new section. Every section in the entire site is stored in a single project file which quickly becomes stupidly massive. Only designers can edit sections. Sections need all sorts of settings done right or your site could become corrupted, even vanish. The content workflow processes are useless because sections can't be workflowed, you'll get a site full of sections with blank pages. Avoid this mess by using secondary pages.

What's the difference between primary and secondary? Well, let's start by understanding website sections. A section is the equivalent of a directory on a filesystem. The section however is a "virtual" directory - it's not a physical directory on any filesystem, it doesn't actually exist anywhere, the section is "generated" on demand. Anyway, if I go to a real directory in a normal website, I'll see a directory listing. Actually most websites are set up so that instead of seeing the listing, I'll see a default page, usually called index.htm - sounds familiar? In UCM terms this "default" page is your primary page, assembled using your primary layout. (Example: http://www.mydomian.com/mysite/mysection/index.htm)

But just as a directory can contain any number of files, a section can display any number of web pages. The primary layout can only display the one assigned content item as index.htm - so the secondary layout is used to display any other content item requested as a web page. The region in the secondary layout is not assigned to a particular content item, it is assigned as "replaceable." To see any content item in this section, simply append the ContentID to the section's URL and presto! there it is. Any item whatsoever can appear as a web page in this section (depending on security, conversion settings and so on) so you'll never need to modify any sections ever again! Woohoo! (Example: http://www.mydomian.com/mysite/mysection/ID000001) One final tip on this issue - you can (and usually should) use the same layout as the primary and the secondary, no probs.

2. Generate SEO-friendly filenames using SSUrlFieldName
The problem with secondary layouts is that the filename is just the ContentID, typically just a number with no file extension. Yuck! That's going to ruin your Google ranking and cause all sorts of confusement. (Example: http://www.mydomian.com/mysite/mysection/ID000001)

Give yourself real file names with the config value SSUrlFieldName. Create a metadata field (let's call it Bob) and then append your config.cfg file with SSUrlFieldName=Bob and presto! your web pages now use whatever filename Bob says. There is a catch - old mate Bob must know a unique filename for every content item, regardless of where it gets used. Bob can't talk about two items called about.htm (he gets confused) and expecting your contributors to give Bob the unique filename is delusional. The solution is to auto-generate it using the ContentTitle, the ContentID and a file extension. Replace spaces with dashes, truncate and then remove the leading zeros. (Example: http://www.mydomian.com/mysite/mysection/about-1.htm) Set this up as a global rule (newcheckin onsubmit) on your contribution instance - or as a archiver import rule on your consumption instance.

*****
I'll write a few more of these...