Best Practices for Building Sites in dotCMS


Published on

Presentation covering several simple and straightforward tips and tricks to help with and improve your web site deployment in dotCMS, from the dotCMS Boot Camp 2010 user conference.

Published in: Technology
  • Actually, in your case, that is the perfect reason *TO* use VTL files. Generally, a lot of users don't have that complex of a setup though. Early on, especially in pre 1.9, it was common to see stuff built with tons of VTL files unnecessarily. In a lot of those cases, there was no particular advantage to that over using, say, a simple widget.

    But definitely, VTL files exist for a reason and can serve an important purpose with good implementation.
    Are you sure you want to  Yes  No
    Your message goes here
  • Slide 12 - why is suggested to use VTL files sparingly? We are using dotCMS version 1.7a and have found that, even in later versions, import/export is dodgy ( So, we are using VTL files everywhere possible and store them in SVN. This makes it very easy to figure out changes have been made and, using WebDav/Cadaver it is also very easy to migrate changes with a script.

    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Best Practices for Building Sites in dotCMS

  1. 1. Best Practices for Building Sites in dotCMS @fienen - Presenters: Michael Fienen – Pittsburg State University, nuCloud LLC, .eduGuru Maria Bouza – dotCMS
  2. 2. What we're looking at... <ul><li>Container Must-haves
  3. 3. Template vs. Containers
  4. 4. Using VTL Files, when and where
  5. 5. Widgets
  6. 6. URLMap for Detail Pages
  7. 7. Custom Forward Pages
  8. 8. Valid HTML and 508 Compliance </li></ul>
  9. 9. Container Must-haves <ul><li>Functional Template Include </li></ul><ul><ul><li>Inserted at the top of templates to include data and information
  10. 10. Loads before <html> tag
  11. 11. No visual elements included
  12. 12. Good for: </li></ul></ul><ul><ul><ul><li>Global Variables
  13. 13. Macro testing
  14. 14. Timestamps for CSS/JS cachebusters </li></ul></ul></ul>
  15. 15. Example Include Container:
  16. 16. Container Must-haves <ul><li>Meta Container </li></ul><ul><ul><li>Page Title, Friendly Name and Title for Page details
  17. 17. HTML Page Meta tags: $!HTMLPAGE_META </li><ul><li>Good for meta keywords, descriptions, or other things you need in the <head> per page  </li></ul><li>Include all common CSS Files
  18. 18. Include all common JS files
  19. 19. Lives inside the <head>...</head> tags </li></ul></ul>
  20. 20. Example Meta Container:
  21. 21. Container Must-haves <ul><li>Statistics Container </li></ul><ul><ul><li>Create one container that holds your Statistics code, such as Google Analytics
  22. 22. Container will normally be included at the end of all templates
  23. 23. If multiple hosts, use Host Property to hold Account ID </li></ul></ul>
  24. 24. Example Analytics Container:
  25. 25. Template vs. Containers <ul><li>dotCMS uses Yahoo Grids (a CSS framework) to create HTML used in templates: </li></ul><ul><li>Try to create small number of templates
  26. 26. Templates should be created only for different layouts, the functionality should all be handled through widgets </li></ul>
  27. 27. Template vs. Containers <ul><li>All reusable sections of the HTML should be created as Containers (max contents 0)
  28. 28. All sections of the site that are editable should be created as Containers (max contents > 0)
  29. 29. Doctype should be added to template
  30. 30. Head section (<head>) should be created in the template to allow to have specific JS and CSS files on each template </li></ul>
  31. 31. Looking at Containers
  32. 32. Using VTL files, when and where <ul><li>Limit use of VTL files only to Simple Widgets
  33. 33. Should not be used as “widgets” parsed from containers, content or templates
  34. 34. Should be saved to a central location on the site (/application/velocity)
  35. 35. Limit to “application” like functionality
  36. 36. Good as building blocks of complex widgets
  37. 37. Used for source code in some macros
  38. 38. Don’t abuse them! </li></ul>
  39. 39. Widgets <ul><li>Simple Widgets: </li></ul><ul><ul><li>Use them for dynamic code that does’t need parameters
  40. 40. Good for generic, dynamic tools (listings, detail page bodies, etc...) </li></ul><li>Structured Widgets (Widgets that receive parameters) </li><ul><li>When the widget needs to be reused on different sections of the site
  41. 41. When we need to send parameters to the widget
  42. 42. As a front end for macro setup </li></ul></ul>
  43. 43. Structured Widget for Macro
  44. 44. URLMaps for Detail Pages <ul><li>Create URLMaps for structures (1.9)
  45. 45. Better for SEO purposes (human-readable):
  46. 46. Easier to print and share
  47. 47. Make sure your structure has at least one unique field to tie to.
  48. 48. Example: </li></ul>
  49. 49. Building a URLMap
  50. 50. Set Up Custom Forward Pages <ul><li>You already do this for your home page when you set up the /cmsHomePage virtual link (Vanity URL in 1.9)
  51. 51. You can also do this with typical error pages with: /cms###Page </li><ul><li>Works with 400, 401, 402, 403, and 404 </li></ul></ul>
  52. 52. Custom 404 Page Example
  53. 53. Valid HTML and 508 Compliance <ul><li>Garbage in – garbage out. Validate templates before loading them in. </li><ul><li>HTML Validation http ://
  54. 54. 508 Compliance http :// </li></ul><li>TinyMCE won't do your job for you (even if it wants to try)
  55. 55. Microsoft Word hates the internet </li></ul>
  56. 56. Thanks Boys and Girls! Questions? Hunt me down: dotCMS Cheatsheet: