At the end of September I was lucky enough to attend the SDL Tridion MVP retreat in Portugal for the second year in a row. Thanks SDL.

Besides the fantastic food, the sun and the great beach, we actually got some work done. We set out to build a community platform on which new Tridion PowerTools could be built for SDL Tridion 2011 and future releases. Since leaving Portugal there is now a GoogleGroup, a Skype Group (email me if you want to join with your Skype ID) and an Open Source SVN hosted in Google Code . There is also a new IRC channel, but I think that has lost its geeky momentum.

Thanks to all the members of the Tridion community who have got involved. This feels like the start of something big. Get involved...

I believe the USA is one of the biggest SDL Tridion markets, but they are running behind on SDL Tridion MVP nominations. Nuno has posted the details at:

http://nunolinhares.blogspot.com/2010/10/mvp-nomination-stats.html

I am not sure when the nominations close, but if you have not made your nominations already, now is the time to do so

Sadly the SDL Tridion MVP retreat is over and we are on our way home after 3 great days and a surprising amount (given the great food, fine port and majestic beach) of talk about the SDL Tridion Community. Thank you SDL Tridion, and especially Nuno for making it happen.

Our goal was to focus on social media based community extensions. The building block exchange (BBX) hosted on SDL Tridion World contains several extensions, most of which have been designed and built by individuals. I am guessing that these individuals had a need for some functionality on their own projects, and tried to make it generic, and have since decided to share it in the community. I salute those of you who have done this, but it got me wondering if these extensions would be built the same way had the developers had a whole group of people helping with the solution.

I ask this because I had a great experience this afternoon whilst waiting for our taxi to Lisbon airport. I had spent the morning working on an idea we had on Friday for an ‘Upload to YouTube’ extension for SDL Tridion 2011. Now I got pretty far with my concept and I was feeling pretty proud of my solution, but I thought I would share my thoughts with the other MVPs, and to my disappointment none of them said “That sounds fine, when will it be ready”,  instead a passionate design session sparked up in the lobby of our hotel. The team came up with all sorts of other approaches, and ideas for how we could make the same set of functionality work in a cleaner, purer, and  more efficient way. There was talk of the new Custom Storage Layers offered by Tridion 2011 and Custom Deployers, Custom Transport Senders, File System Watcher Services, Custom Queue Consumers and the like.

Unfortunately, given the time and lack of whiteboard in the lobby, we failed to come up with a final design. However we thought it would be an interesting experiment to see if we could initiate a project where the SDL Tridion community actually designed (and ideally built) an extension through a crowd sourcing based collaborative approach. So here I will outline a set of functional requirements for the extension, some thoughts I had when attempting to design the extension, and an outline of my initial idea (which for the record I don’t think I like anymore).

The Use Case

From inside the SDL Tridion 2011 CME, it should be possible to upload a multimedia component which contains a video file (which must not be more than 1gb or over 10 minutes long to meet the YouTube imposed guidelines) in a supported YouTube format to YouTube. Once published, it should not be possible to delete the multimedia component from the CMS without first removing it from YouTube. It should also be possible to access the uploaded URL of the video using standard Tridion APIs and methods such as templates for publishing web content, outbound email newsletters and print publications etc, so that developers can create links to the videos and embed them in their web pages. The extension should be easy to understand and implement by an average Tridion developer.

The upload process should use credentials and channel information stored at a Tridion Publication level, although kudos will be awarded to anyone who can create a design that can use a YouTube account and channel specified by the user initiating the upload.

Based on this extension, it should be possible for a member of the SDL Tridion community to easily modify the extension so that it could be used to upload images to a site like Flickr in a similar way.

Initial thoughts

• Videos could be large, and take a long time to upload
• It probably makes sense to have the upload process use some kind of background asynchronous process to do the uploading instead of requiring the user to wait for the video to upload
• It might make sense to use the existing publishing/distribution mechanisms offered by SDL Tridion 2011 as it can mark items as published and utilize the existing templating techniques etc.
• It would be possible to make a custom deployer extension using Java which would take the file and upload it, but I didn’t like the requirement to have an SDL Tridion Presentation Server involved. Furthermore, I haven’t had many positive experiences of Custom Deployer Extensions, and I can’t think of a way to easily send feedback of the YouTube URL to the CMS. Can anyone convince me a Custom Deployer is the right way to go? Should you run the Deployer with a Custom Deployer Module on the CMS server, and use it to upload the video and utilize the Core Service to update the CMS with YouTube URLS etc? Alternatively if the Deployer is on the CD side, is there a way that a Custom Deployer Module can send information about the successful upload URL back to the CMS so that it can be saved on a Component using the OnComponentSetPublishedToPost trigger in the Event System.
• A Custom Transport Protocol with a YouTube enabled Sender and Poller could be created, but I have not done this in about 5 years, and I think you need to do it with Java (Has this changed in Tridion 2011). Is it reasonable to expect an average Tridion CM Developer to use Java in addition to the JavaScript needed for the GUI extension and the  template language(s) required to extract the video and it’s metadata from the CMS?
• It would be really cool to add a tab to multimedia components that have been published to YouTube which shows the number of plays and other pertinent information about the usage of the video.

The Initial UrbanCherry Design

1. Create a Publishing Target called ‘YouTube’ with a local file system destination of d:\YouTube (Note that a Publication Target Type is not needed which keeps the target hidden from the CME users, and prevents users trying to publish to it by mistake. I didn’t actually know this worked until today, but according to Dominic Cronin this was carried over for backward compatibility from R4 when we didn’t have Publication Target Types).
2. Create a dynamic Component Template which publishes the video, the necessary metadata values and credentials required by YouTube.
3. Create ribbon bar and context menu items called ‘Upload to YouTube’ based on the MVP HelloWorld extension sample posted by Julian Wraith.
4. Implement isAvailabe() and isEnabled() functions to only show the buttons and menu items when a multimedia component containing suitable video mime types are selected. (It would be cool if this supported multi select also). Jeremy Grand Scrutton made some samples this week which pretty much do this, and I hope he will post these sample soon.
5. Implement the _execute() function so that when the context menu or ribbon bar button is pressed, a popup appears allowing a user to confirm they want to upload the video to YouTube.
6. After confirming, a script (either JS or ASP.NET to be decided) adds the component to the publishing queue for the YouTube Publication Target.
7. The existing Publisher Service then publishes the Dynamic Component Presentation(s) to the local file system.
8. A custom windows service running on the CMS server polls the new target location, unzips the packages and uploads the video and metadata to YouTube. Once a URL is returned by YouTube it adds the URL to the metadata of the published component (using either TOM or the new Core Service) and creates a ‘success’ receipt (like the deployer does) which it stores in the d:\YouTube folder.
9. The Poller created by the standard out-of-the-box Transport Service then collects the receipt, updates the Publishing Queue for the publication transaction (to failed or success) and sets the video component as published in the CME.

Possible concerns about the initial approach

• Not really nice to have to build a custom service for each extension which uses such an approach.
• The windows service duplicates a lot of things that the Deployer already does (Like unpacking the Publication Transaction, and creating the success or failure receipts.
• The Multimedia Schema needs a field to store the YouTube URL in, which means modifying the content model in order to use the extension.
• If there are other Dynamic Component Templates linked to the Schema that the video is based on, multiple Dynamic Component Presentations will be published to the target for no reason.
• If there are multiple publishing servers, the custom windows service would most likely need to be installed on each publisher.
• Some people may consider this a hack, and that makes me a bit sad… so I want to make it better.

The first community designed community extension

I invite you all to share your ideas on what might be missing from the use case. Share your ideas in the community on how you would tackle this project. Pick holes in my design, and tell me what is wrong with it and how you would improve it. Discuss it with your colleagues, and get their ideas, and get them to share them on their own or company blogs. Hopefully we can come up with a really cool design approach, and maybe then we can start building the first real community built community extension for the SDL Tridion Community.

If you are anything like the 7 MVPs who were at the retreat this week, you might just have some fun doing it and learn something in the process. I am also pretty sure, that anyone getting involved with such a public challenge is likely to improve their chances of gaining a SDL Tridion MVP nomination for 2011 (Send an email with your nominations to sdl.tridion.mvp@sdl.com  before the end of October to make your nomination, stating why that person is a valuable member of the SDL Tridion community, more info is at http://www.sdltridionworld.com/community/mvp_award/index.aspx).

It has been an interesting 3 days. On Thursday the SDL Tridion MVPs for 2010 set off to a small forte just outside Lisbon in Portugal for a 3 day meeting of the minds so to speak. The general theme of the retreat has been how build a strong community around SDL Tridion and their products. In doing so, we have been working on lots of examples that we plan to share in the community on how we can extend the new user interface of SDL Tridion 2011.

So the SDL Tridion MVP Fondue Kit has started to take legs, it is not complete yet, but I have to say I am now addicted to this type of Tridion related work. Below is a sneak peak of the new UI (from the SDL Tridion CTP) and the extensions we have built.

More to follow later, including a cheat sheet/quick start guide on how to add buttons, context menus and tabs to SDL Tridion 2011.

Tony Byrne at CMS Watch recently wrote a short piece on using WordPress as a CMS, which got me thinking about the my experience in the world of enterprise class CMS systems. I must admit, I have always been a bit of a snob when it comes to open source CMS systems. I guess I swallowed the Tridion pill so long ago that other platforms don’t often come into play.

So in an effort to broaden my knowledge in the area, I have recently set out to revamp the UrbanCherry website and its blog. The site is hosted with GoDaddy, and currently uses the BlogEngine.NET blogging application, and custom built ASP.NET application for the pages. Unfortunately we get a lot of spam comments in the blog, and maintaining the site is not a top priority, and at this point I don’t really want to invest to heavily in graphic design.

Tony’s piece prompted me to take a look at WordPress and I will be launching a new  site/blog this weekend based on the tool. At first glance I am pretty impressed, installation took 5 minutes (in part due to the hosting options at GoDaddy), and the number of customizable themes  out there is truly amazing. I have not used PHP since about 1999, but it was still pretty easy to get things running.

Now it is clearly not a CMS in the same caliber as SDL Tridion 2009, but I think there are a lot of things SDL could learn from such an offering. I for one will be investigating a concept of swappable themes for SDL Tridion websites at a current customer of mine in the coming months. With solutions like WordPress and Drupal Gardens popping up all the time, and the number of developers with skills in this area, perhaps they will give SDL a run for their money. I would certainly encourage SDL to release a free/light version of the product to get developers and marketers to swallow the Tridion pill like I did, adopt Tridion for their small sites and blogs, flood the market with Tridion advocates, and use that as a way to boost their penetration in the enterprise market.

So drop back next week, and update your RSS reader to the new WordPress based URL when you have a chance.

So after writing my first blog to discuss the need for an SDL Tridion 2009 Development Environment, The SDL Web Content Management Solutions Division seem to have come up with an answer. Today they announced their ten Most Valuable Professionals in the community for 2010.

I was very flattered to be the only external (i.e. who is not an employee of SDL) US based recipient of the SDL Tridion MVP Award for 2010. As an MVP I am told that we will receive, amongst other benefits such as invitations to participate in various SDL events, a personal research license for SDL Tridion’s products.

So a huge thanks to the selection panel for considering me for this award, and congratulations to the other nine MVPs for 2010. I promise to create and share all I can in the coming months here in this blog and through the official channels provided by SDL like the forum and the BBX.

For all those who wrote and commented in support of the blog about development environments, I can only encourage you to be active in the community, blog and share, and make sure that you get nominated before December 31^st 2010, and perhaps you can be the MVP for 2011.

The SDL Tridion CMS uses a special kind of object called a Multimedia Component to store binary files managed by a CMS use. Typical uses for these MM Components are images, office documents, pdfs etc. In older additions of SDL Tridion, these were rendered/published by VBScript or XSLT templates using a method called PublishBinary().

The PublishBinary() method did two things. Firstly it extracted the binary file from the CMS, and  prepared it for deployment to the presentation server (essentially took the blob from the DB, and created a file from it, and placed it in the Publish Transaction zip file). Secondly, it returned the location that the file would be placed in once it was published. This value could then be used by your template to create HTML links to your binary files.

This approach worked well, except that all of the binaries were placed in one directory on the web server, which might have led to unique naming issues. To get around this problem, the PublishBinary() method would add a unique suffix (based on the MM Components URI) to the file name of the published file.

E.g. A multimedia component containing a file named "stuff.png", with a URI of "tcm:35-794" would get published to the location "/images/stuff_tcm35-794.png"

The above example highlights two concerns that users of early versions of SDL Tridion had about how it handled binary files. All of the binary files from a specific CMS Publication are stored in a single configurable location (i.e. /images or /files, but it could not deploy binaries to multiple locations), and the filenames of the files were not very user friendly.

SDL Tridion R5.3 introduced a solution to the problem by introducing a new AddBinary() method along with the Modular Templating Framework. This promised to solve all of our problems by introducing a number of additional parameters, the most significant of which was the ability to add the binary to a specific structure group.

E.g. With R5.3, it is possible to add the binary to a special PNG Structure Group and publish the file to the location "/files/png/stuff.png"

This seemed to meet all of the user requirements I had heard over the last several years, but it has introduced a new problem, which many people have run into in the last couple of years. If you have two multimedia components both named "stuff.png" stored in different CMS folders, but you need to use them both in the same Component Presentation (or even in different CPs if you use the default templates) , you will receive the following error when the Broker tries to deploy the files to your web server:

"A processing error occurred processing a transport package. Attempting to deploy a binary [Binary id=tcm:35-795-16 variantId= sg= path=/Images/stuff.png] to a location where a different binary is already stored Existing binary: tcd:pub[35]/binarymeta[794]"

This is kind of expected, as clearly there is a unique naming conflict in this situation. However this situation seems to occur more often than one might think (even using the Default Template Building Blocks that come with the product). Try it for yourself; create two multimedia components based on the same file (i.e. with the same filename). Then create a component which links to them both in an RTF field, and try publishing it using a simple Compound Template as follows:

Notice that the Sample Dreamweaver Component Design places two copies of "stuff.png" into the package. The Default Finish Actions (which contains the Publish Binaries In Package template) is then responsible for actually publishing the items in the package, and then the Link Resolver template then modifies the Output item, and update all the URLs of the files in the HTML.

I set out to find out exactly what the Publish Binaries In Package template was doing, so I downloaded the sample code from the SDL Tridion Forum at: https://forum.tridion.com/topic.asp?TOPIC_ID=4653. In the PublishBinariesInPackage class, there is a method called ConstructFileName(), which makes use of a number of properties that do not show up when you inspect the package of the with the Template Builder. These are all documented as Public Fields of the Item class in the Templating Implementation Manual (TOM.NET). 

The key properties here are the Item.ItemPropertyFileName, Item.ItemPropertyFileNamePrefix, Item.ItemPropertyFileNameSuffix and Item.ItemPropertyFileNameExtension. As far as I can tell, the Dreamweaver mediator only utilizes the Item.ItemPropertyFileName property (I am not aware of the source code for the mediator being publicly available, so I can’t be sure of this).

Having spoken with several of the Customer Support and R&D team members, it seems that this is by design, and there is an assumption that developers will ensure the uniqueness of the filenames. This is fine if you write all your own code to publish binaries, but if you want to take advantage of the pre-built building blocks it doesn’t always work.

To get around this problem, I created a small C# TBB (but could be in an assembly) which can be added to the Default Finish Actions (or directly to a Compound Template) to add a suffix the filenames to all of the binaries in the package (i.e. The file stuff.png becomes stuff35-794.png when it is published by the  Publish Binaries In Package template).

The result is that we no longer see the "Attempting to deploy a binary to a location where a different binary is already stored" error message popping up in the publishing queue.

Please let me know if you have other/better ways to solve the problem. Until then, I will be including this C# fragment in my Default Finish Actions compound template building block for the foreseeable future.

As a consultant in the CMS industry for nearly 10 years, I work on and install software on my customers’ infrastructure in Development, Test, Acceptance or Production (DTAP) environments. However, as an integrator/developer, I (like most developers) like to do my software development in an environment that I have complete control of. Having to ask an administrator if I can reboot a machine, install Visual Studio (or other desktop products) on their managed servers, or to call a DBA to backup/restore a database just slows down the development cycle.

Developing for the SDL Tridion CMS

In my time working at SDL Tridion, most consultants had at least one VMware image which contained  a Windows OS, SQL Server, Visual Studio, DreamWeaver, XMLSpy and of course the SDL Tridion Product Suite. Essentially, they had a slimmed down version of a customer development environment running on their laptop. This is great when working on the weekend, or on a train or a plane. Of course, a license had to be purchased for all non-Tridion software for each VMware image, but as an SDL employee, you received an internal license for all SDL Tridion software which you could use at any customer. This was a great situation, as we all had common code-sets that we could port between customers, who in turn benefit from the knowledge pool within the SDL Tridion Professional Services group.

I also spent some time working at an SDL Tridion Partner in the Netherlands, where we worked with much the same VMware approach. The only difference was that we used a partner license key for the Tridion products. I would happily build solutions on my VM image, and then when I had done my testing, I would port the code to the customer’s development environment, where we would integrate it with the existing code base before moving it through the various test and acceptance environments before eventually deploying the code to the production servers. Effectively this meant there were five standalone environments:

• Unit-Development (installed in a VM on each developer's laptop)
• Development (installed at the customer, and used to integrate code)
• Test (installed at the customer, used to create a new deployment)
• Acceptance (installed at the customer, used to test a new deployment process)
• Production (installed at the customer, used for editing and publishing customer content)

This is commonly called the DTAP street by Tridion people (or OTAP in their Amsterdam office), with the first step clearly missing. Should we be talking about a UDTAP street? The point is really moot, because customers buy licenses for their environments, and don’t care that SDL Tridion consultants have extra environments which speed up their implementations and save them money in the long run.

So far two thumbs up, but...

Today I am an independent contractor, and spend a lot of my time advising SDL Tridion customers and partners how to set up a Tridion development team and how best to structure their software development and release cycles. So I started out trying to explain the way that I have always done it, and the methodology behind the process, and that’s where I ran into a number of hurdles.

Hurdle #1: Customers don’t often buy licenses for four environments (let alone five). I will cover more on the DTAP theory in another blog, but until then, let’s just say that most customers think that Dev/Test/Prod is enough (perhaps it is a way to meet budget requirements), and consider their staging environment to be a QA (or Acceptance) environment.

This presents a major challenge in ensuring quality releases, and when I explain why four complete environments are important, most customers with a structured policy on code deployment go back to their sales rep and get licenses for the fourth environment.

Hurdle #2: Having explained the five-environment model to several SDL Tridion partners with off-site or off-shore teams, they particularly like the approach, as most of their developers are located a long way from their customers, and even with current bandwidth availability, the restrictions on available VPN connections to many customer environments makes working directly on the customer’s own development environment an impracticality (especially when there are multiple developers on the same project).

Unfortunately, the elusive fifth environment is only readily available to SDL Tridion Professional Services’ own consultants. Having read the small print of the partner license for SDL Tridion, it seems that it contains wording which says something like “may not be used for development on customer projects”. Essentially, the license is for internal research, demos and training, and cannot be used as the Unit-Development environment that I had hoped for.

Hurdle #3: As an independent contractor there is no obvious way to get an SDL Tridion license for research purposes (let alone to use as a standalone development environment). I have access to several partner licenses (as I work for several partners), but I have to maintain these in very separate VMs, and only use them when researching work for that specific partner (which raises an interesting question, if I do some research, and then someone uses my sample code in production, did it just become development work and technically a license violation?). This makes work very slow and tedious, especially when working on several projects in one day.

As a person who doesn't like hurdling very much, I have been looking for ways to level the playing field, and make it easier for independent consultants (and partners) to enter the SDL Tridion consulting space (which so desperately needs more qualified talent).  Microsoft has a number of programs designed for just this. There is DreamSpark for students and BizSpark for small new businesses. My company, UrbanCherry, is a BizSpark member, and it gives us a full MSDN license to all of their software for development purposes for three years. Combined with a decent laptop, VMWare Workstation ($190), Dreamweaver ($200), and XMLSpy ($500), we have everything we need to create a standalone SDL Tridion development environment, except SDL Tridion 2009 (which is probably more money than a consultant could make in a year).

SDL Tridion Developer Edition

So why not make an SDL Tridion 2009 Developer Edition? I know it has been discussed over and over again, but for some reason it doesn’t exist. Potentially this could be an extra revenue stream for SDL. This got me thinking about what would make the developer edition different from the full blown product. How could SDL Tridion prevent customers from using the developer edition in their production environments, and what would its value be to a developer, to a partner and to SDL?

What would be acceptable "SDL Tridion - Developer Edition" be?

In my mind, the developer edition would need to be the full SDL Tridion product suite with the following limitations being acceptable:

• Only 1 User (with administrator rights), ideally 2 or 3 so workflow and security could be tested
• Only support local file system publishing
• Content Manager (CM) and Content Delivery(CD) only accessible on http://localhost/
• Only support 2 CPUs on the CD and CM environments
• No customer support access included (possible per incident fees), most tickets would be supported under a paying customer account
• All licenses valid for a single server name (ideally separate for CM and CD so that Unix based machines could be tested on the CD side)

What would it be worth?