Yet Another Tridion Blog

In case you have written any SDL Tridion Content Delivery Deployer extensions, you have noticed there is no easy way in intercepting the unpublish/undeploy of a binary. This blog post shows how to intercept such an action and execute your custom code on it. The reason why it is hard to intercept a binary undeploy is because in fact the binary remove does not happen at Deployer level; rather, it takes place in the storage level. So the extension point to be used in not a Deployer extension, but a storage FileSystem or JPA extension. File System The following code implements a storage extension that intercepts the removal of a binary from the File System Content Data Storage (fka the File system broker): package com . tridion . storage . toolkit ; @Component ( "FSBinaryDAOExtension" ) @Scope ( "prototype" ) public class FSBinaryDAOExtension extends FSBinaryContentDAO implements BinaryContentDAO { @Override public void remove ( int publ

This post describes the installation and usage of the Maven Release Plugin. The plugin uses behind the scene a GIT repository configured in the SCM (Source Code Management) section of the POM (Project Object Model). In your project's main pom.xml , add the following plugin inside you build / pluginManagement / plugins node. <plugin> <groupId> org.apache.maven.plugins </groupId> <artifactId> maven-release-plugin </artifactId> <version> 2.5.3 </version> <configuration> <goals> deploy </goals> <autoVersionSubmodules> true </autoVersionSubmodules> </configuration> <dependencies> <dependency> <groupId> org.apache.maven.scm </groupId> <artifactId> maven-scm-api </artifactId> <version> 1.8.1 </version> </dependency> <dependency>

I ran into an issue recently when my EH Caches that I wanted to create and configure using the ehcache.xml was already created. In this situation an exception is thrown by the EHCache cache manager and execution halts. Alternatively, when it's not possible to use a configuration file ehcache.xml to define the caches, one must resort to creating them programmatically. This is the object of this post. The code below first checks whether there is a configured cache with the given name, and if not, it proceeds to create one programmatically. CacheFactory () { CacheManager cacheManager = CacheManager . create (); if (! cacheManager . cacheExists ("myCache" )) { cacheManager . addCache ( new Cache ( new CacheConfiguration ("myCache" , maxEntriesLocalHeap ) . memoryStoreEvictionPolicy ( MemoryStoreEvictionPolicy . LRU ) . eternal ( false ) . timeToLiveSeconds ( timeToLiveSeconds ) .

I have used IIS's URL Rewrite module in several of my .net projects. It is a very neat module that gives a lot of URL rewrite/redirect functionality out-of-the-box. Namely, the module can do: URL rewrite -- rewrite the URL path before request processing starts (similar to a server transfer); URL redirect -- redirects the client browser to a modified URL by sending back redirect HTTP status codes; Rewrite outgoing URLs in the response body; My requirements have so far involved using URL rewrite together with the outgoing URLs rewrite in the response. For example, I had recently the following use case -- my client has legacy .aspx pages under location /devices . There are new DD4T .html pages in the system, but because of some routing restrictions they had to be placed under a temporary location /device (notice the difference from /devices). The .html pages should, however, be exposed to the internet as if they belonged to folder /devices . Example: /device/page.html  sh

In my current DD4T .net implementation, I encountered the requirement of having Rich Text Format fields resolved in a custom way. Namely, I had to check whether the type of a RTF Component link is of a wrapper around the actual Component to link to, and if so, resolve the link to the wrapped Component. An elegant way of doing to is to extend the default DD4T.ContentModel.Factories.LinkFactory and create a new method ResolveRTFLink(string componentUri) : public interface IMyLinkFactory : ILinkFactory { string ResolveRTFLink ( string componentUri); } The implementing class would extend DD4T LinkFactory and implement IMyLinkFactory : public class MyLinkFactory : LinkFactory, IMyLinkFactory { [Inject] public virtual IComponentFactory ComponentFactory { get ; set ; } [Inject] public virtual IModelFactory ModelFactory { get ; set ; } At the same time the class must provide an implementation for  ResolveRTFLink  method: public string Resolv