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.
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
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:
- 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.
- 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.
- In Tridion-speak, when you localize something, that means that you are “breaking an inheritance”. Think of how, in CSS, you set a
<body>, but now you want to have a different font for your
<h1>. When you put that new
font-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.
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:
- 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.
- 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.
- 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…
Or it could be kept out of Tridion, and follow a completely different flow to get to the site.
Or they could be a raw/ complete file.
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.”
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
<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
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.