So, you’re a front-end developer, eh? And you’ve been told that you’ll be writing code, and that it’ll be moved into a Content Management System. Called Tridion. And you can’t find out where to download it because there’s not a version on Github. There’s some random blogs out there, a Stack Exchange, but it all feels nebulous. And now you’re wondering, “oh, crud, what’s this going to do to my code, ” Or maybe you’re wondering, “how can I get some basic Tridion knowledge before this interview at [Tahzoo || Trivident || Building Blocks || Content Bloom]? ”
It’s going to be fine. Let’s learn some things.
1. Tridion is (kind of) not open source
You’re a front-end developer. jQuery, Foundation, Backbone, Underscore, Angular, React, Sass, Stylus, Less, Node.js, NPM… your whole world is open source. WordPress is open source. Tridion is not.
Tridion is a .NET-based Content Management System. It is owned, developed, and supported by a company called SDL. Sorry, you can’t go to a Github repo, clone it, and try it out. While SDL offers free developer licenses for Tridion, be warned, there are quite a few steps involved in installing Tridion. You’ll need a Windows server, some databases, some powershell scripts, and an afternoon to yourself. Grab a snickers, it’s going to take a while.
“Kind of”
Tridion has a pretty sweet plugin framework, called Alchemy. It was developed by Alex Klock & Team over at Content Bloom, and Alchemy is open source. Tridion also uses these kind of… core plugins called Power Tools, which are also open source. Oh, and there’s also this thing that’s kind of an “add-on” for Tridion, where you can get a lot of goodies pre-installed, called DXA. DXA is totally open-sourced.
So, Tridion itself is not open source. But many of the things that make it awesome are. Not only that, SDL has a Github account — SDL is not our enemy just because their CMS isn’t open source.
2. Tridion has “Cascading Content”
You know how CSS works, right? Styles cascade; you set a font-family on your <body> and that style cascades down into your <p>.
Tridion does that. With content. It’s pretty rad, and it’s the thing that makes Tridion very different from just about any other CMS you’ve ever worked with. I’ve worked with Tridion, Teamsite, WordPress, and Drupal, and seen nothing close to an equivalent concept.
SDL calls this idea of “cascading content” a Blueprint.
So, here’s some basic Tridion terms. These are guaranteed to win points with that interview/backend-dev:
- Publication
- A Publication is where a whole collection of content and things live. Everything in Tridion is in some publication, somewhere. A publication could be a more abstract thing, and contain global content. Or it could be a more tangible thing, and contain the actual website.
- Blueprint
- All of your publications, and their relationships to each other. In the picture up top, what you’re looking at is an actual Blueprint. Every Blueprint is different. Tridion does not come with a Blueprint pre-installed.
- Localization
- In Tridion-speak, when you localize something, that means that you are “breaking an inheritance”. Think of how, in CSS, you set a
font-familyon your<body>, but now you want to have a different font for your<h1>. When you put that newfont-familyin, you’re actually, “breaking the inheritance” by overriding the style. In Tridion, content that exists in a higher publication also exists in each of those lower ones — unless you localize it. When you localize it, it has all of the same properties and characteristics, but now you can change them. Localization is bit like… increasing the specificity.
3. SDL Started as a Translation Company (and still is one)
You were asking for Tridion knowledge, right? So why is this important?
Well, a lot of people wonder why Tridion has this Blueprinting and “Cascading Content”. That’s because Tridion got its start over in Europe, and the idea of “Cascading Content” solves a big problem that European countries have: organizing and managing content for a bajillion languages.
The Blueprinting model means that you can also write all of your content in one language in one publication, let it cascade into a lower publication, where you then localize the content, and write it again in a new language.
Over here in America, we don’t have the same kind of need to publish a website in 437 languages, but the Blueprinting model offered something else that was a huge deal when SDL broke into the US market over a decade ago: managing content for multiple sites.
Remember the days of “m-dot” websites? Like m.amazon.com? A “cascading content model” was really helpful for building a mobile website because you could let the content be inherited into a new publication, where you had entirely different templates.
Templates. Right.
4. Tridion doesn’t care about your code
Don’t get upset. This is a good thing.
In Tridion, content, presentation, page, and layout are all completely separate and distinct things. Let’s introduce some new Tridion words that might explain this a bit better:
- Schema
- If you’re familiar with OOP at all, you know that you have classes and objects; objects are an instantiation of a class. Think of a schema as the “class” for a piece of content. You establish what fields are allowed for a kind of content, whether they’re required, repeatable, rich text, plain text, or a list. As a front-end dev, you should know what kinds of fields exist in the schema.
- Component
- The instantiation of a schema. Content authors edit components all day long. A component contains the the content — and just the content.
- Component Template
- This is where you come in. A component template (CT) is the HTML that wraps the content that goes around the component. When you write your code for a given piece of content, it’s actually for a component template.
- Component Presentation
- A component presentation is what happens when a specific component gets merged with a component template.
- Page
- A page is a collection of components. More accurately, a page contains components, and the component templates that the content author wants to use
- Page Template
- The HTML that wraps the component presentations.
Visually, it plays out like this:
You can grok two important things from this:
- Tridion’s default state is to keep code and content separate
- Tridion will never generate unwanted markup
5. You can fine-tune Tridion’s WYSIWYG
Under #4, I made the point that Tridion would never generate unwanted markup.
Of course, that leads you to ask, “wait, does it not have a WYSIWYG / Rich Text Editor? Because those things are pretty much the worst thing since since Frontpage for unwanted markup”
Yes, it does have a Rich Text Editor. But you have a lot of control over what happens with it. In reality, you decide how rich it should actually be.
First, take note that it’s a checkbox to switch a field from plain text to rich text:
Ok, it’s a bit much. Let’s zoom in:
So, let’s say you go ahead and click on Edit Formatting Features. You’ll find a lot of features:
6. Your code may not live in Tridion at all
Tridion is incredibly flexible; it knows very little about the code used to generate the website, if it even needs to know about the website at all. It really depends on the preferences of the Tridion client as to where the front-end code lives:
If they use static publishing
This means that Tridion is publishing the entire, fully-rendered, page template. It also means that your HTML for your templates lives in Tridion, too.
If they use dynamic publishing
It (usually) means that Tridion is publishing something like XML to a database, and some web application retrieves that XML content at request time. This usually means that the HTML for your templates lives with that web application. A very popular framework called DD4T (Dynamic Delivery 4 Tridion) serializes the content so that you can use an MVC framework of your choosing to deliver content at request time.
The CSS and JS goes…
… anywhere.
Your CSS and JavaScript could be kept in Tridion, and published to the site.
Or it could be kept out of Tridion, and follow a completely different flow to get to the site.
If it’s stored in Tridion, then your CSS and JavaScript could be broken up, and concatenated and minified when they’re published.
Or they could be a raw/ complete file.
Whether the CSS and JavaScript are in Tridion really depends on the client, their preferred workflow, and the architecture.
7. Yes, Tridion can do that
The question that I get most from front-end developers that are new to Tridion is, “Can Tridion do [thing]?”
The answer is usually “yes, Tridion can do that thing.”
The reason it can do that thing is because code is not hard-wired to content. You can make new component templates for the same content. You can use the same component templates for different content. Do certain pages need a specific JavaScript file? Should certain component templates call other component templates? It’s fine. Tridion is completely agnostic when it comes to code, which means that you have a lot more freedom in Tridion than you would in most other CMS.
When writing your front-end for a Tridion implementation, it’s like there’s no rules!
The rules for writing your front-end
Yes, Tridion is a blank canvas for code. And it’s because it’s a blank canvas that you should follow a few rules:
- Tridion’s schemas can’t contain logic (i.e.: you can’t have some rule in Tridion for, “if you fill out field X, show field Y”); don’t write front-end that assumes two fields [are || aren’t] filled out simultaneously
- Tridion doesn’t do complex validations on fields — your options are “required” or “not required”; don’t assume it’ll be exactly 3 lines of text, fewer than 200 characters, between 1 and 3 images, or no more than 5 CTAs; account for it in the template, your CSS, or make sure the content author knows what not to do
- Tridion doesn’t know if it’s producing valid or semantic markup; don’t wrap three blocks of text and an image in a
<p>or an<article>without knowing which schema and what field type is being used - Tridion doesn’t have a strong model for layout or “regions”; a content author controls layout by choosing a page template, choosing a specific component template, or setting the order in which those components on the page
- Tridion doesn’t know what the rules are for a page — “wrong component”, “wrong order”, “wrong number of components”, and “wrong page” are determined by the template; don’t write CSS that assumes a specific order in the DOM (avoid using
>, +, and ~), and don’t assume that your banner module will be at the top; you have communicate these rules to the backend dev, the content author, or both
In Summary
Tridion is one of the few Content Management Systems out there that I can confidently say, “not only is it not an enemy to good front-end, it’s actually a friend.” Tridion is insanely flexible — to the point that this is one of the chief complaints from clients.
In fact, It’s flexible-enough that you can probably break any of the rules I gave you if you find the right Tridion architect, and buy him or her the right drink.
Permalink
Very good and thorough article Frank. For those new to Tridion this provides a well balanced and easy to grasp overview of things inside and beside Tridion. I enjoyed reading it.
Permalink
Very useful overview, thank you. The main thing I’m wondering now is if a content editor can see a preview of their component in the final styling. That would be mainly to make clear immediately when text should be shorter to not break design. Any hooks for that?
Permalink
Hey Micros, that’s an excellent question.
No, there isn’t any way to do that. and that kind of stinks. Not only that, it’s deceptively sucky:
When you’re editing a page, you can add a component.. You can click on the component in the left side of the window, and then on the right side of the page editor, you have a preview option.
but that preview option only works if you’re using static publishing (i.e. the templates are actually in tridion). If it’s static publishing, then you’ll get the content wrapped in whatever HTML used for that template.
Now, If it’s static publishing, and the templates are in Tridion, AND the CSS is modular-enough, it could be possible to put together a GUI extension that could import CSS into that preview area, so it could look kinda like the actual site.
If it’s not static publishing (the template is a DD4T one, where the “preview” option just shows you xml) .. then you’re totally out of luck. In that case, what you’d want is Site Edit, which allows you to browse the site a bit like an end user would, and edit components “inline” in the page.
Permalink
And don’t forget that the standard way of using Tridion is to have a staging site as well as a live one. The content folks can publish their work to their own private site – check their work – and then publish exactly the same thing to the live site. This requires a bit of discipline, but it’s working well for everyone.