In the Tridion publishing model, we have publications, publication targets, and target types. End-users can publish content from a "grouping" of content called a publication (optionally publishing to any child publications at the same time), to publication targets which typically send content to websites. However, I've heard a legend-of-sorts where a Tridion customer published to files which eventually ended up on CDs (compact disc, not content delivery!) and were then driven to the destination to be physically loaded to the actual presentation servers.
The specific publication targets aren't visible during publishing. Users will see something like "Live" or "Preview" as the target type(s) to publish to.
I get nervous when I see target types other than the basic "Live" and "Preview." The specific terms don't matter so much--in other words, other words like "Production," "Staging," or "Acceptance" could be used. What jars me is when we occasionally have target types that aren't logical or based on an environment.
A blog on content management and digital experiences
Tridion End-user Issues and Fixes
Here's a list of the most frequent issues and solutions I've seen working with Tridion (R5.3), from an end-user perspective. I think we have a great overall setup; we have hundreds of publishing requests that succeed quietly every week for a system that holds a few thousand components and dozens templates.
However, I see these issues typically with newer users or with changes to the system (new template, new publication, new presentation server, etc). I know a team hasn't started working with content after a training session until I hear at least one of these. :-)
These are specific to our setup, though I suspect other Tridion-using teams have experienced similar issues. Let me know if there are any I should add to the list.
However, I see these issues typically with newer users or with changes to the system (new template, new publication, new presentation server, etc). I know a team hasn't started working with content after a training session until I hear at least one of these. :-)
- Permission Denied. Tridion opens with a default settings pop-up. Typically closing Google Toolbar or turning off the Pop-up blocker fixes this.
- Can't see publication, can't edit content, or can't publish. Permission issues involve both rights and permissions. Rights are general capabilities and end-user may have for a given publication whereas permissions involve access to specific folders, categories, or structure groups. As a metaphor consider how the "right" to go where one pleases can be framed by specific "permission" to enter certain buildings. An email to the owner, analyst, or admin for the website fixes most of these.
- Publishing Failed. Possible for a variety of reasons, possibly an issue with content or a template, but typically because of a configuration issue with the servers. Tell your server administrator. Log a support ticket with Tridion if needed.
- Fields are missing! Component opened in a folder not set with a default schema. Select a schema from the drop-down menu in the new component, or if you have the correct folder rights and permissions, update the folder to default to a specific schema.
- Content not visible in a (typically higher-level) "shared" publication such as "020 - Content." Content possibly created in the wrong publication. Check child publications for missing content. Content needs to be re-created in the shared publication--not bad for multimedia components (because of Webdav feature), harder for basic components. We've occasionally fixed this by using content porter to bulk move items. We've also resorted to "locking" down the child publications to prevent users from making components in certain folders. There's a power tool (custom page) that may help as well.
- Name conflict; can't create content with a specific name. Sometimes caused by a misunderstanding about the blueprinting feature. Tridion intentionally prevents same-named items to be created in publications that share content. This is usually seen when creating items higher in the publication.
- Published an item and nothing happened. With new content, and I've seen this with developers as well, the page or template needs to be published first.
- For "static" (non-dynamic) content on a page, the page needs to be published at least once in order to have the page automatically published when a component on it is published.
- For dynamic content, a template set to publish dynamically (and associated with the component's type or schema) must first be published at least once.
After this, re-publishing the template will also publish all previously published dynamic component presentations. - Formatting, symbol, or character issue. Typically not caused by the end-user, but by templates failing to handle certain characters, tags, intentionally ignoring formatting or the website being set to the wrong encoding. This can be addressed by the development team manager or appropriate contact.
- Double clicking a component in the selection opens the component. This is by design in 5.3, but since "fixed" in later versions (2009? and for sure in 2011). Don't double-click, click once and press OK when adding a component to a page.
These are specific to our setup, though I suspect other Tridion-using teams have experienced similar issues. Let me know if there are any I should add to the list.
Tridion Setup Considerations for End-User
Some gotchas and things to keep-in-mind when setting up Tridion for end-users. I've seen some of these issues a few times with the (internal-to-my-company) teams I've trained.
Architecture Affects End Users
Tridion blueprint design and implementation options are flexible enough to create different solutions for different websites. However consider the effect on end users. If using "index" components as well as individual dynamic component presentations, it means end users will have to understand two publishing paradigms: "Here you remove items and re-publish the list, but here you unpublish the items individually." Ummm, huh?
Additionally adding unexpected target types, changing the frequency for publishing, or showing more publications or folders they typically work with can confuse end-users. Consider using the MMC snap in setting to reduce unwanted folder visibility in addition to separating end-user groups by folder permissions.
Forecast... Content. Lots of Content!
Anticipate growth. Legacy systems or procedures may have introduced artificial bottlenecks when it comes to content creation and release. Don't be surprised to see several times the amount of content, large binaries, and requests outside the original functional requirements such as one-off templates, formatting features, and other details such as hyperlinks.
Unless you want end users to hard-code all links, the templates are not trivial because you may have to handle various scenarios such as:
Scope creep aside, be sure the system design and architecture (design, settings, file space, etc) can handle seemingly simple increases in file size and quantity. Train end-users to schedule publishing of large files or large amounts of content after hours.
Good Templates Help
To avoid rework consider investing in a good functional (feature rich) template early on. As tempting as it is to treat everything as plain text--try to make or use good templates that can handle links and at least basic formatting like emphasis and strong. (Note restricting font styled in schema filters removes centering; consider filtering the style="text-align:center" attribute on the template side or using another work around). End-users judge the CMS by how often they have issues and how much they have to "fight" hack at making it do what they want.
Increase buy-in and long-term satisfaction by making useful templates that can handle rich text formatting, missing binaries, and can do center if it's expected. I'm all for incremental increase, but why get a leading CMS if all it does is output plain text?
On Training...
Though they do so much and we put so much effort into them, I've learned to avoid discussing the details of templates with end-users beyond the fact templates make content look a certain way. Templates are simply a drop-down selection for end-users. Some end-users publish dynamic component presentations (dcp) and may not even be aware of the template that renders the content. To new users or even devs I've found people's definition of "template" is something more like "schema."
Sometimes a dev will forget there's even a template involved with publishing. "I published everything but nothing happened!" "Did you publish the template?" "What template?"
Happy designs and coding!
Architecture Affects End Users
Tridion blueprint design and implementation options are flexible enough to create different solutions for different websites. However consider the effect on end users. If using "index" components as well as individual dynamic component presentations, it means end users will have to understand two publishing paradigms: "Here you remove items and re-publish the list, but here you unpublish the items individually." Ummm, huh?
Additionally adding unexpected target types, changing the frequency for publishing, or showing more publications or folders they typically work with can confuse end-users. Consider using the MMC snap in setting to reduce unwanted folder visibility in addition to separating end-user groups by folder permissions.
Forecast... Content. Lots of Content!
Anticipate growth. Legacy systems or procedures may have introduced artificial bottlenecks when it comes to content creation and release. Don't be surprised to see several times the amount of content, large binaries, and requests outside the original functional requirements such as one-off templates, formatting features, and other details such as hyperlinks.
Unless you want end users to hard-code all links, the templates are not trivial because you may have to handle various scenarios such as:
- internal links to non-Tridion content
- external links (and any disclaimers associated with these)
- links to Tridion components
Scope creep aside, be sure the system design and architecture (design, settings, file space, etc) can handle seemingly simple increases in file size and quantity. Train end-users to schedule publishing of large files or large amounts of content after hours.
Good Templates Help
To avoid rework consider investing in a good functional (feature rich) template early on. As tempting as it is to treat everything as plain text--try to make or use good templates that can handle links and at least basic formatting like emphasis and strong. (Note restricting font styled in schema filters removes centering; consider filtering the style="text-align:center" attribute on the template side or using another work around). End-users judge the CMS by how often they have issues and how much they have to "fight" hack at making it do what they want.
Increase buy-in and long-term satisfaction by making useful templates that can handle rich text formatting, missing binaries, and can do center if it's expected. I'm all for incremental increase, but why get a leading CMS if all it does is output plain text?
On Training...
Though they do so much and we put so much effort into them, I've learned to avoid discussing the details of templates with end-users beyond the fact templates make content look a certain way. Templates are simply a drop-down selection for end-users. Some end-users publish dynamic component presentations (dcp) and may not even be aware of the template that renders the content. To new users or even devs I've found people's definition of "template" is something more like "schema."
Sometimes a dev will forget there's even a template involved with publishing. "I published everything but nothing happened!" "Did you publish the template?" "What template?"
Happy designs and coding!
Subscribe to:
Posts (Atom)