Today I ran into the fact that outbound links from the standard WordPress RSS widget are not tracked by Google Analytics for WordPress. Unfortunately I have been unable to find a WordPress plugin for an RSS widget that does track the outbound links. However before embarking on a journey to create a widget with this feature myself, and finally add something to the community that gave me so much, I tried out the KB advanced RSS widget.
Fortunately this widet gives you control over the output it generates. This made it fairly easy to add the GA tracking code to the widget by replacing the code in the last text area of the widget with:
Hope this will be of use to someone.
Recently I came across a post (and a fellow Tridion blogger, keep up the good work!) which answered the question “Why won’t this publication delete?“. It describes a tool (source code included) which helps you find the pages which you need to unpublish before you can delete the publication. It mentions two prerequisites which need to be met before you can delete a publication:
- No pages in the publication are published
- There are dependencies on the publication, child publications etc.
I would like to add a third prerequisite:
- Check the publishing queue for publish transactions which belong to the publication to be deleted which have the status “in progress”. In some instances publication transactions never leave this state and they will prevent you from deleting the publication.
In addition I would like to propose another way of ‘unpublishing’ all items in a publication (pages, components, MM components etc) by running the following query on the CM database (back-up the DB first) :
In the Tridion cms content is being stored in folders. The folders are similar to folders in file systems, they contain both subfolders and components. However if you wish to publish the content of an entire folder you will have to traverse all subfolders yourself in order to select and publish the components manually. Not exactly a job for volunteers.
Fortunately there is something called the Tridion API which allows you to write a (power)tool which takes care of traversing a folder hierarchy and republishing all the content in it. This will reduce the effort of republishing an entire folder to an acceptable level and give any script kid a huge sense of accomplishment.
Alas a tool like this is not very friendly to the users of the Tridion cms. They will ask why it is impossible to publish a folder in the same manner they can publish a structure group. The answer to this question is unknown to me at this point in time. Perhaps one of the Tridion employees reading this blog can enlighten me on this subject (and approve my comments on ideas.sdltridion.com). Read more
In version R5.3 Tridion has introduced Modular/Compound Templating, which offers (more) separation between layout and business logic. It also allows the implementation of Template Building Blocks (TBBs) with C# and/or .NET assemblies.
A Template Building Block used with Modular/Compound Templating is (normally) responsible for one major task. For example: Converting XML to HTML, Publish all Binaries in the package or Activate Tracking (these are all standard Tridion TBBs).
Below I’ve listed the major ‘Pros and Cons’ of working with Tridion .NET templating. Read more
Due to the fact that I don’t have a personal blog, I’ll (ab)use the one Albert has… Thank you Albert.
A short introduction; my name is Gerbrand Smit, I’m a colleague of Albert (also a consultant at Deloitte Consulting) and have been working with Tridion for more than six years now. In those past years I’ve done a great deal of Tridion implementations and have grown really fund of projects where Tridion is involved.
My latest project was with Tridion R5.3 SP1, allowing me to ‘play’ with the new SDL Tridion .NET Templating, I’m going to share some of my views on the subject in the next post.
I created a small evaluation in order to make a substantiated choice between publishing XML or HTML from Tridion. I already assume that you made the choice between static and dynamic publishing Perhaps it will be of interest to someone:
|Separating content and presentation / Re-usability of data.
Since the web application completely determines how or which parts of the XML content is presented, the same content can easily be displayed in different ways.
|Tridion publishing Performance.
When publishing XML content, Tridion only needs to render one Component Presentation which will take less time then rendering multiple Component Presentations.
|Maintenance and extension of Component Templates.
Your templates in Tridion will be simpler and thus easier to maintain. The complexity is transferred to the web application which is much easier to main then Tridion templates (try debugging or refactoring your code in Tridion).
|Minimizing CMS development dependencies
Changes in the HTML templates will not result into changes of the CMS template code.
Rendering the XML into HTML on the presentation server will use more resources then displaying plain HTML.
|Complexity of the web application
The web application will be partially responsible for rendering the content.
Tridion has two main methods for publishing information to websites:
Both publishing strategies have already been explained in previous posts. However the fundamental differences between both strategies deserves some additional attention.
Publishing chunks of content (dynamic)
In tridion chunks of content are called component presentations. For this publishing strategy the Tridion rendering tree is traversed until step 4. The result of the rendering is a chunk of XHTML/XML/plain text/ etc. which is subsequently published to the broker DB on the presentation server.
On the presentation server the broker DB will be queried by a website based on ASP, ASP .NET or Java which will use the pre rendered content to create a fully rendered page for the visitors.
Publishing whole pages (static)
In this publishing strategy the full Tridion rendering tree is executed. The result of which can be a file of any type, but usually has one of the following extensions: ASP, JSP, HTML, CSS, XML etc. To get the required results you will need to implement both Component Templates and Page Templates.
Which one to choose?
I recommend the dynamic approach. The static model is quickly becoming obsolete in an era of monthly website updates and personalization at the top of everybody’s wish list.
A good illustration of why the static model is useless is an update we recently made to the navigation and layout of a website based on the static model (and NO it was not created by me or one of my colleagues). When you make changes to the templating in the static model in Tridion you will need to re-render all of the pages which make use of these templates. In this particular case there were over 2500 pages in the top publication which was blueprinted over 10 times and each blueprint contained an average of 500 local pages.
I needed to explain to the client on several occasions that the go-live was a ‘process’ which would take the better part of 3 days and three nights. The re-rendering of 30K pages would take approximately 60 hours. During this period the website would slowly go from the old look and feel to the new.
Feel free to share your views on this subject in the comments …
Extending your online reach by targeting local audiences in their own language without compromising global brand consistency. This is what Tridion blueprinting is all about:
- Effectively managing your global message and allow local content editors to adapt and extend that message to incorporate cultural differences and local messages. This will maximize your impact on local markets and still keep the costs manageable.
- It enables reuse of web applications, cms templating and web design, for each sub site you create. This shortens the time to market for a new website considerably. A good example is the Equens Merger where 6 websites were created in record time.
- Content can be reused over different websites and channels. There are however some limitations to reusing content in Tridion which need to be considered when creating a Tridion blueprint (todo write about limitations).
In my previous article I showed an elementary blueprint which contained only one language and one website. The picture below shows what the blueprint will look like when an additional language is added.
Tridion uses a transactional publishing architecture which enables it to publish content to different websites or channels. To publish your content to a website or channel you specify a publish transaction which includes the publishing target and a date (and some advanced options). The publish transaction will then be placed in the publishing queue where the editors cant track the progress.
The interface enables users to publish their content to one or more predefined publishing targets. A publishing target can be a specific website or any other specific channel. If the user chooses more then one target to publish to, then the system will define a different publish transaction for each of these targets.
During the publish transaction the following happens:
- The content is retrieved from the content manager data store.
- The content is rendered using the appropriate component templates and page templates.
- The rendered content is sent to the Tridion deployer on the presentation server.
- If the first three steps succeed the CMS registers that the content is published to the specified target.
If the transaction fails for any reason this will show up in the publishing queue. A nice new feature in 5.3 is that double clicking on the “failed” tag will show you the actual error message that was written to the error log.
Unfortunately 5.3 also has a “bug” fix. As you might have noticed in my Tridion blueprinting article the content is not published from the publication where it was created. Usually it is published in one of the child publications. In previous versions (5.1) it was possible to publish the content directly from the parent publication. Now we have to add the parent publication to the publication target where the child is supposed to publish to. Not very logical and it adds a transaction to the publishing queue and subsequently slows down the publishing queue.
One common problem in Tridion implementations are “slow” publishing queues. The queue becomes “slow” when the publishing process is unable to handle all the publish transactions. This will frustrate the editors as they will need to wait longer for their content to show up on the website. I have identified the following reasons for that contribute to this problem:
- Rendering full pages can easily take up to 5 seconds. Which I think is an extraordinary long time for executing a few templates (simple programs). This becomes a problem when you have a lot of editors publishing content at the same time. Or when you need to republish your entire site (I have seen one example where it took 2 multi-core publishing servers 3 days).
- Rendering the sitemap through the Tridion API takes up a lot of resources. Consider using the rendering strategy from my article about fast sitemap generation in Tridion.
- Using SiteEdit in combination with automatic publishing. A lot of implementations use the Tridion event system to auto publish content to the staging environment on a component save action. SiteEdit saves a component regardless whether there are changes to the component or not. In doing so it will trigger a publish transaction every time an editor visits a page and has SiteEdit enabled on a staging website.
The solution to speed up the publishing process is by adding dedicated publishing servers to your Tridion setup. The real solution, in my opinion, can be found in speeding up the rendering process. I think Tridion should look into this.
Most websites use some form of sitemap xml for rendering the navigation blocks. In Tridion implementations this sitemap is usually rendered from the folder structure created by the content editors. The established way of doing this is by creating a component template which calls the Tridion API repeatedly and traverses the folder tree. Unfortunately opening a lot of folders and components through the Tridion API is a time and resource consuming activity.
The method of traversing the tree will work fine if you have just one website in Tridion and not too many folders and components which need processing. Unfortunately most companies purchasing Tridion host more then one small website. Typical Tridion clients will manage the content of up to 50 websites in Tridion with thousands of components and folders per website. Most of these implementations suffer from a performance penalty in publishing content as a result of slow sitemap rendering.
In one implementation we needed to generate 13 sitemaps with a rendering time of 10-12 minutes each. With both a staging and live website (a typical tridion production setup) needing a new sitemap at least once an hour this meant the rendering of 26 sitemaps per hour. Needless to say that this would put a huge strain on rendering resources.
The solution to this problem is in NOT using the Tridion API for rendering the sitemap. In the case mentioned above I created a program which queried the filesystem of the presentation server. The program is capable of rendering the sitemap in well under 5 seconds. Which is roughly 100 times faster then the alternative. On the staging server the program runs every minute to give the content editors a near realtime experience. On the live server it is scheduled to run every 5 minutes.
The drawback of taking resources from the presentation server can be remedied by running the program on the lowest possible priority. When running in low priority the program will only use the idle time of the presentation server for rendering the sitemaps.
- Querying the Tridion broker DB. To do this you need to make sure that every component knows its parent. This option can be used for websites using a dynamic publishing strategy.
- Maintaining the sitemap via the Tridion event system (not recommended, I will go into detail on the event system some other time).