We are running SDL Tridion 2013 SP1 with a .Net presentation side and SQL Server 2008 database (both CM & CD).

We have a requirement where the Content Authors would like to have an option of automatically posting new contents to their Social Media channels (Facebook, Twitter, LinkedIn etc.). There are a few options that come to mind, but not sure which approach would be better. Just thinking out loud here.

  1. Develop some kind of GUI extension that provides an option to post components/pages to Social Media.
    • We need to make sure that the content has been published
    • Take care of blueprinting (language specific localized versions)
  2. Create a deployer extension and add metadata fields (Boolean) to contents to indicate if an item should be posted to Social Media or not

Please chime in with your suggestions or ideas on how to approach this requirement.

2 Answers 2


You could create a new staging or live publication target for which you register an event in the event system. When a page is published to this target, you could post from there.

But I think a GUI extension is more appropriate. I would not do this on the deployer as this functionality should not be spread across multiple services. The Content Manger should handle this. Or some other process, but never the Content Delivery (that's my opinion).

  • Not sure I quite agree on that one, the benefit of adding it as a Deployer or Storage Extension, is that it actually follows the Publishing behavior, so you can be sure that when something is published to Live, you will have it on the social channel(s) too (provided that the Deployer or Storage Extension is enabled only in your Live target, and I would opt for a Storage Extension since you are actually storing it in a different location, being a social media channel). When implementing it as a UI extension, you will somehow also need to indicate if it was published to a social channel. May 20, 2014 at 16:12
  • 1
    There's some merit to that, but then all items published to live are socially shared, which you do not necessarily want. Also a lot of our clients don't allow outgoing connections from their CD servers or block social sites. A UI extension should indeed add some indicator to Tridion. May 20, 2014 at 16:33
  • 1
    It could be a dedicated Publication target and deployer for the social Channel, Content editor is able select in the publish window where to publish (Staging, Live, Social Media). By using a storage extension, Tridion will keep track off the published content to the social channels. May 20, 2014 at 19:16

Regarding your two approaches:

  1. GUI Extension could be useful as an approach in the context of where the content is created, but I agree with Bart that this is somewhat removed from publishing.

  2. A deployer extension seems like a good spot for "also deploy to these channels."

But for these requirements, I'd first confirm:

  • Developer skills and availability (Social Media APIs, Tridion APIs, etc.)
  • How will the list of Social Media Networks might change
  • Business case

What automatic social media posting possibly saves authors is the need to either:

  • Go to each social media site to paste the same content and/or link to the content OR
  • Click on some sharing button for each new page or component presentation

Posting to "Social Media" adds a p:n requirement to your channels where p is your Publishable Publications and N is the (current) number of social media channels.

As additional, practical approaches consider:

  • A way to bring an social media aggregator "closer" to the author. This could be something like Bart Koopman's View in Staging/Live extension, especially if your published pages already have sharing buttons (e.g. "AddThis"). Authors just need to get to the page and will press possibly the same number of clicks (one for each social media network).

  • A way to consolidate to fewer formats (e.g. RSS or any social media network that auto posts to another) to publish to multiple social media channels. I haven't used them but possibly something like TwitterFeed.com or FeedPoster.com.

I'm not sure which aggregators are the most popular, but any chance to reduce the number of APIs is probably a good idea especially since they can change or the business may request new ones. For example, Twitter has version 1.0 and 1.1 of its API and Facebook lists its API roadmap.

If still using metadata and authors need control for where to post, I would avoid Boolean (T/F or Y/N) fields and opt for maybe a Category called "Share" with values for the current social media platforms. That way you can add, remove, and change fields through new keywords without schema changes.

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.