The Seven Deadly Places... to Add Markup with SDL Tridion

Even in a "simple" SDL Tridion setup, there are several places to add HTML markup.

Pop-Quiz

How many places can you add or change HTML markup in an SDL Tridion setup (including "bad" places)?
  1. Components - entered into a rich text field (via the GUI by an end user)
  2. Filters - added or changed by a schema filter (done via XSLT defined in the schema)
  3. C# Template Building Block - added or changed by a template building block (TBB, typically from a .NET assembly or C# fragment)
  4. DWT Template Building Block - added or changed by a HTML layout template building block (typically with Dreamweaver-syntax)
  5. Component Template - added or changed by a non-modular component template (via XSLT or VBScript aka "legacy")
  6. Page Template - added or changed by a page template (or its corresponding TBBs)
  7. Presentation Server - everywhere else; okay this is a slight cheat, but in a complete WCM setup, we can't ignore the target presentation servers which include markup outside the Web content management (WCM) system such as:
    • HTML pages or the equivalent for the given Web programming framework/language
    • the appropriate in-line script, file, or compiled code that can generate HTML
This can be "deadly" because although you can sometimes guess where markup comes from, you can't be sure with a casual glance. Even harder is the fact that there are legitimate reasons for adding markup in any of these places including:
  1. Components - user should be able to add some appropriate markup (but maybe not others)
  2. Schema Filters - system may require or need to deny certain markup, down to the database that shouldn't be handled by templates
  3. C# TBB - some functionality create basic markup (e.g. generated list of links, breadcrumb, email link)
  4. DWT TBB - YES, IMO the majority of markup should be done here 
  5. Component Template - XSLT is a natural fit for XHTML, for those that enjoy the recursive goodness these types of templates offer
  6. Page Templates - depending on the target's framework, these templates may have the occasional "include" reference or links to CSS or JavaScript files
  7. The discussion of where HTML may exist on the presentation server depends on how the site was or will be set up but markup may come from existing pages, Master pages, controls, include files, etc.
The seven locations also hints at why anytime you ask for Tridion help you'll likely get a response to:
  • check the logs
  • check the content (components)
  • check the filter (sometimes missed)
  • check the templates (and what type they are)
  • check for extensions
  • check the transport package
  • check the rendered physical page
  • check the source of the browser-generated markup
  • (the source here doesn't always match the source of the physical file!), and finally to
  • check any JavaScript that can change markup after everything is done!
Oh and don't forget to publish (to the right target), confirm what publication you were in, and make sure it's wired up correctly, while you're at it. With this so complicated, why even use a WCM system (WCMS)?! I'll have to follow up in my next post for more.