Yet Another Tridion Blog

Ok, it's time to do some maintenance and performance tuning on your Tridion CMS. One of the things you should keep an eye is the size of the Publishing Queue. This can grow quite large over time depending on the amount of publishing going on daily. Tridion comes with a very handy tool -- the Purge Tool, which allows trimming the size of the Publishing Queue. I won't go into what the tool can do; there is documentation for that. The following little script is perfect to run inside a Windows batch script and schedule it to execute periodically. In its current state it deletes Publish Transactions that completed more than 1 year ago relative to today's date. @echo off set /a LastYear=%DATE:~10,4%-1 set OneYearAgo=%LastYear%/%date:~4,5% echo OneYearAgo=%OneYearAgo% echo TRIDION_HOME=%TRIDION_HOME% @echo off > "%TRIDION_HOME%bin\purge.xml" & setLocal enableDELAYedexpansion for /f "tokens=* delims= " %%a in (purgeTemplate.xml) do (

In my 9 years of consulting and implementing Tridion, I never wrote the same code twice... Kudos, Tridion -- you awesome beast! But every now and then I find myself needing the same low level handlers and I end up copy pasting them from somewhere. For example, with Event Systems I always prefer putting the configuration in a System Component in Tridion. I put it maybe in the current Publication metadata or current Folder/Structure Group meta. I always end up writing the same code to handle the reading of this Component, checking for modifications, caching it for a few minutes, then making the configuration values available inside some object model. Recently, this annoyed me enough to write an Event System base-project that takes care of this once and for all... Enter the Yet Another Event System framework. Functional requirements: Rapid development -- provide a base ready to be used in actual Event System development System Component is in free format -- provide a consistent A