We are running SDL Tridion 2011 SP1. I am looking for ideas to move flat files(HTML, class, jsp, jars etc.) to Tridion CM for a consumer base(developers) with no experience in using the Tridion CME. Users will not be using the explorer for creating and editing purposes but will only publish these assets to a delivery server which will serve the content to the Internet. This is for a bunch of existing applications and newer applications will leverage community CD frameworks.

I am aware that there are easier solutions for this purpose out of SDL capabilities and the above is not even recommended with WCM, but we would like to gather some Tridion community advice before concluding. I like Tridion :).

I have tried to use WEBDAV, treating all of the above as binaries, but the allowed and reserved MIME type restriction does not allow me to upload files of all formats. Is there a way we can get around this? Is is possible to extend the Tridion WEBDAV module like DreamWeaver to allow files to be uploaded to the cm database. I am not sure if I might run into the problem described above despite a custom client.

Another option would be to build a custom application which will leverage a framework using the Tridion core service & event system which builds the page and its associated items. Load, performance and other capabilities will have be to debated. I am looking for thoughts and suggestions from the community before completing evaluation of Tridion as a solution.

  • So this would be a "Tridion as FTP" scenario? In terms of MIME types, XML be the biggest restriction (there are workarounds--see tridion.stackexchange.com/a/556/46). You should be able to allow additional MIME types, though I'm not suggesting this is necessarily a good. Commented Jun 12, 2013 at 16:42

5 Answers 5


I agree with all of the other "Don't Do Tt" answers. However, I have had clients which insisted on it.

The only solotion I have seen work well is to create a zipfile of the entire web application, and use a custom target and template code limited for use by Admins only.

This allows you to upload the complete tested application as a package, and then deploy it in one go, which limits the risks of uploading incompatible parts of the application.

I then use a custom TBB to unzip the package into a binary structure which gets deployed to the web application server. I have use such a TBB for deploying an exploaded WAR file and .NET applications.

I still don't like it, but if you must, this solution introduces fewer risks than a system that allows incremental updates.

  • 1
    If you "have to," I like this approach for the loose coupling and simplifying this down to the actual business requirement: give authorized users the ability to also release the the application at will. Commented Jun 13, 2013 at 5:11

I know this doesn't answer your question. But pure and simple: DON'T DO IT!!! Maybe you know all the reasons, but here are some good ones, just in case:

1) Content and Applications have different lifecycles

Content is continually created/refined/published - that is why we use a CMS. Applications are developed, tested and released at agreed and controlled moments. Having your application published from your CMS is so wrong - can you be sure that the publisher will publish all related artifacts at the same moment? What happens if the JSP is published before the .jar file? What happens if someone accidentally publishes (or worse un-publishes) something crucial? Application meltdown on your production system, that's what. 500 Server Error Heaven.

2) Tridion is designed to manage content and not applications

Thus the aforementioned issues with certain mime-types, although as mentioned, most binaries can be uploaded into the CMS. Just because you can, doesn't mean you should.

3) Developer Frustration

You need to train your developers to use the CMS. They will quickly become annoyed at what was once a simple xcopy or .war deployment becoming some manual update of multiple multimedia components and then moving to another publication to publish. This is before we even start talking about continuous integration - shoving everything through the CMS as a glorified FTP server will make this kind of thing even harder to accomplish.

  • Thanks for your input in this regard Will. I do agree with all of the DONTs mentioned above. The question is more directed towards the CAN vs. CANNOT capabilities of Tridion and not the SHOULD vs. SHOULDN'T. Any solution chosen by the customer will have its own share of merits and demerits and this one will have it fair share as well. As a solution provider, it is best to highlight them all and leave the decision to the business stakeholders, people with the time and money :). In a ideal world, the CAN-do solution should account for most of the risks highlighted above and below.
    – Shiva
    Commented Jun 13, 2013 at 1:52

Please see below my opinion:

If I am in a CMS Architect shoes, I would not recommend using a CMS as a deployment tool or as a repository for business logics.

Content Management System by definition is meant to manage the Content of a Website where Content could be anything visible on the page but definitely not the compiled classes, jars, dlls or business logic/algorithm.

Nice to hear that you like Tridion very much and I am also crazy about Tridion system as per my knowledge of various CMS System, Tridion is the only CMS which satisfy the basic principle of keeping your Content and its presentation apart; and if you use it as a deployment or repository tool, you are not only defying the Tridion's principle but also of a basic CMS principle as well.

Even though despite of this you want to do, then following could be the option and you may choose per your need:

  1. Creating specific multimedia types and defining all these files as Multimedia component and then you may choose to publish them either as a standalone multimedia components or though a CT/PT and Page combination
  2. As far as I know, using WebDav you will only be able to upload known multimedia types
  3. Write a Thin Client and integrate it with Core Service code to automate the process defined in option 1 above (This may suits best to your need)
  • Thanks @Pankaj. The suggestion was helpful. I will update the comment with the solution, if it is actually implemented. Thanks again for your time!
    – Shiva
    Commented Jun 13, 2013 at 1:49
  • Guar: Is there a way to publish standalone multimedia components from Tridion without association to a CT/PT and Page? If so, can you provide me some links I could refer and test?
    – Shiva
    Commented Jun 18, 2013 at 14:00
  • You may want to see the below link: yatb.mitza.net/2013/01/… Or the process in simplified language can be seen here: tridion.stackexchange.com/questions/685/… Commented Jun 18, 2013 at 14:38

Though this question might likely fall under the "can write a book about it" category, I'll attempt an answer from a business analysis and functional perspective.

Like Pankaj, I second the separation between content, design, and code. Though I'm not particular on the specific format--sometimes you might want Tridion outputing something that looks like code, but is really managed functionality in Tridion (e.g. fields in Tridion that eventually publish an XML configuration file).

Author Actions

I'd only recommend putting flat files or any other external item into a Content Management System like Tridion if authors (possibly "dev" authors) need to do anything with them.

This would include:

  • Publishing to one or more target (Target Types in Tridion)
  • Editing or possibly adding additional information to these
  • Referencing, linking, or otherwise configuring these (e.g. reference a "flat file" in page metadata)

Baked Requirement?

And even then, there are easier, more loosely coupled ways to integrate these files with a WCM. Rather than "baking" these into Tridion, consider adding them later during publish, in server-side code, or final rendering (script).

Technical Debt

I too (three?) love Tridion but consider the following technical debt with this approach.

  • Code deployment would be coupled with WCM solution. You don't need to change existing processes, especially if you have a mix of applications and only some use Tridion.
  • Versioning based on upload time (which may or may not be an issue for you)
  • Source control--you'll likely want to keep a (your existing) solution outside of Tridion.

If you still feel Tridion solves the business problem, see this excellent series of articles from BuildingBlocks on managing code, images, and css.

  • Thanks for your time Alvin. As I have highlighted above, the author would not be using tridion CME for creating nor editing the items. It is to package and publish the files. As stated in my question, these are already working applications. The time & money that needs to be invested to build them the recommended OOTB Tridion Approach would out-weight the actual cost of developing it in the first place. Moreover, there is no other authoring or integration requirement for it to be available in Tridion today, apart from publishing. The technical debts above are very useful as well. Thanks.
    – Shiva
    Commented Jun 13, 2013 at 2:07

You also can add a missing MIME type from the Tridion administration section, such as jar or class file type.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.