404 pages are the best way to lower search engine rankings and scare visitors away from your site. In many cases the content is still available on the site only the location changed. Tridion eliminates the number of broken links within your website if your content editors make correct use of component linking. Component linking makes it very easy (and tempting) to change the location of content within a website.
Unfortunately inbound links and search engine content is not managed out of the box by Tridion which results in the dreaded 404 pages being served to visitors and crawlers. The solution is simple: Redirect (301) the crawlers and visitors to the new location of the content yourself. To do this you need to:
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
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).
Blueprinting is the name Tridion uses for creating a hierarchy of publications. Every publication in the hierarchy contains a specific website building block (XML schemas,content, templates, layout, applications). Each child publication inherits the building blocks of its parent(s). The publications lowest in the hierarchy are the publications where content, layout and applications come together and form a website. The building blocks inherited from a parent publication are read-only unless you “localize” (i.e create a local copy) them.
Choosing the right blueprint for your organization is critical to the success of a Tridion implementation. If you fail to get the blueprint right then future changes to it will prove to be very hard and the usability of the system very low. Even the initial implementation of a simple, one language and one channel, website will be a daunting undertaking and will remain a challenge during the entire product life cycle. Read more
The goal of an alias is to create a link to some article on your web page that is short and descriptive enough for your audience to remember. Application could be for a TV commercial or printed media. In these cases you want to keep the URL short and simple.
For example the url http://website.domain.com/products/2008/1235469/default.aspx is impossible to remember. Therefore you want to be able to create a link like www.domain.com/alias. I have seen a number of interesting and very complicated solutions to this problem. However the easiest way to implement it is the following: Read more