Navigation

▼

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.
on

4 comments:

  1. Elena S20 December, 2011

    Excellent points Alvin, quite thorough! May I add in terms of extensions we may need to check on extensions in the GUI itself, template rendering extensions (for instance Dreamweaver extensions, XSLT Mediator or other languages mediators), Publisher extensions (custom resolvers, custom renderers) and Deployer extensions, did I miss anything? :)

    ReplyDelete
  2. Nivlong21 December, 2011

    Depending on the setup, we also have other scenarios to check for general troubleshooting (most of these could potentially affect markup).

    The expanded list includes yours plus workflow/event-system, templates updating things they shouldn't (now available in 2011), business connector for older systems, non-GUI-but-still-Core Service import programs/scripts, other uses (my favorite), non-checked-in template changes, non-checked-in components, template/publication target/configs/database settings for character encoding. I won't pretend I know how to make or fix all of the above, but know enough to include them in the "ultimate Tridion troubleshooting guide."

    On top of that the need to confirm publication, publication target, whether whatever you're reviewing was actually published, and sometimes even if you're in the right environment (gotta love the color-coded GUI tweak to remind you you're not in the right environment). Even associating a dynamic template to its schema is sometimes missed. These are more of the "basic" Tridion functionality, but you'd be surprised how many times I've heard "what template?" when a dev was trying to figure out why a regular or multimedia component wasn't published.

    Luckily (hopefully) the Pareto or 80-20 rule somewhat applies and 80% of the issues come from 20% of the possible problems. Well-designed systems make it even better... but I think I've just turned a comment into another post!

    ReplyDelete
  3. Nivlong22 December, 2011

    One more spot... on a pre-SP1 SDL Tridion 2011 install, apparently the browser was adding different tags in rich text fields. P tags for returns in IE (how I like them), BR in Firefox, and DIVs in Chrome. If you're seeing this, consider getting SP1 if possible. Alternatives are to stick with one browser and/or use a rich text filter (carefully).

    (thanks Nico Esterhuyse, Frank aka "puf," and the TridionNut for clarifying parts of the same issue and the fix)

    ReplyDelete
  4. Nivlong19 February, 2012

    I noticed a few search hits on "tridion 2011 richtextfield problem firefox" for my blog's stats. Contact SDL support if you're having issues.

    ReplyDelete

Feel free to share your thoughts below.

Some HTML allowed including links such as: <a href="link">link text</a>.