The plugin interface looks very neat for both plugins, a easy to use overview of tasks, options and functions.
I recommend trying it out.

About the plugins

Batch Publisher™ for RedDot CMS

A publication manager to publish selected pages and following pages.

Batch Publisher™ provides a convenient way for content class based page batch publishing in RedDot CMS. Download it here.
RedDot CMS is designed to componentize a Web site by way of content classes. When a specific portion of the site gets updated, either in terms of function or look and feel, the change is not reflected on the live site until the affected files are published out.

In SmartTree, RedDot CMS does provide a way for a site administrator to traverse the collection of page instances pertaining to a specific content class, albeit with a maximum of 200 pages returned.

RedDot CMS, however, does not provide a way for the site administrator to publish out those returned pages in batch fashion. Publishing those pages out means that the administrator has to select and publish those pages one by one.

The often used, no-brainer alternative is to publish out the entire site, regardless of the population of updated pages; however, when a site is large and the change is time-sensitive, whole-site publishing becomes very attractive and impractical.

That is where Batch Publisher™ comes in. It provides an easy way for administrators to see the collection of pages pertaining to a specific content class and publish them in batch fashion. All common conceivable operation are built-in: granular selection and sorting of pages within the page collection of a content class are simple clicks.

source & download: http://www.byteweaver.com/content/batch-publisher-reddot-cms

Open Lounge™ for RedDot CMS – A chat for your CMS users!
Read more »

This is another great guest post by Chad Killingsworth from the Missouri State university. Chad is another RedDot Guru who comes up with neat solutions every now and then and also integrated the TinyMCE texteditor into Open Text Websolutions Management Server RedDot CMS.

A frequent task in RedDot Open Text CMS template construction is to assign the value of a placeholder to a string so you can perform some kind of logic on it.
Most of the time we get along very well with our beloved content management system, but sometimes we wouldlike to add some kind of special characters to our standard text elements. And this works fine for 99%, no matter what we do, we can add a copyright-character, trademark, .. pretty much everything.

But one thing always breaks, and this is not even RedDot’s fault, it’s a simple ASP or VBScript flaw. Take this example:

<!IoRangePreExecute>
<%
  dim label
  label = "<%stf_Label%>"
%>
<!/IoRangePreExecute>

If the <%stf_Label%> placeholder happens to contain an un-encoded quote, you'll get a server error. But sometimes you just really NEED a quote in the value. How do you handle this?

Strange Bedfellows

Server side JavaScript (or JScript) has long been supported, but rarely used, by Internet Information Server. In this case we can use the following code to correctly capture the value.

<!IoRangePreExecute>
<script language="javascript" runat="server">
  var PlaceholderValueRegExp = /^function [_a-zA-Z][_a-zA-Z0-9]*\(\s*\)\s*\{\s*\/\/([\s\S]*)\}$/i;
  function GetPlaceholderValue(PlaceholderFunctionString) {
    var str = PlaceholderFunctionString.match(PlaceholderValueRegExp);
    if(str != null && typeof(str) == "object")
      return str[1];
    else
      return "";
    }
    if(!stf_Label<%PageID%>)
      function stf_Label<%PageID%>(){
        //<%stf_Label%>
      }
</script>

<%
  dim label
  label = GetPlaceholderValue(stf_Label<%PageID%>.toString())
%>
<!/IoRangePreExecute>

And presto – you have your variable and your quotes too.

How does this work? What’s Behind the Magic Curtain?
Read more »

“Quit while you’re ahead”, people say – so do I.

For over 5 years now I’ve been working as a RedDot expert, fiddling around with almost every nut and bolt of that system. Those were quite interesting years and a lot happened to the small software company “RedDot” based in Oldenburg, Germany. First the acquisition by Hummingbird, then the absorption of both of them by Open Text. In my opinion, this was a huge turning point, and not everything is turning to the better:

Giving up the lead

RedDot CMS was once ahead in the game, providing techniques like WYSIWYG editing, e.g. the famous red dot, which made it easy – even for untrained editors – to see, what the published page will look like. RedDot missed out important user interface trends and Open Text continued to do so. Even the smallest Open Source CMS today has features like quick interface response through AJAX and similar techniques, quick in-place editing, drag & drop support, etc. They have clean, well thought out interfaces and most important: They are fully cross-browser compliant. Up to OTMS v10, the CMS had none of this and the recent changes are more desperate efforts to catch up, rather than leading the business.

Heads in the cloud, problems on the ground

The software platform itself is in desperate need of a major overhaul. Big parts are still written in classic ASP (VBScript), if you ever had a look at the code you know it’s really messy. With Open Text, the main goal became to integrate the rest of the company’s software products. Basically, this is just fine but when you look at the roadmap for the next versions (up to 2012), they list 7 (seven!) products/technologies which are about to be stuffed into the system. With the recent acquisition of Nstein, I guess you can increase that number once more.

Besides that, if you saw some Open Text presentations lately, the buzzword machines are working overtime: Instead of talking about Social Open Enterprise 2.0 Web Cloud thingy stuff™, take care of the product foundation you want to base your visions on. Before buzz-talking about Web 3.0, learn to master Web 1.0 first!

Business etiquette

Last but not least, I’m deeply fed up with the way Open Text (at least in Germany) treats their long-term partners in a quite unpartner-like way. Period. I won’t go much into detail here, as this is a long list of annoyances and I don’t want to get personal. But don’t get me wrong, there are still some cool guys there I know from the old RedDot days, I had the opportunity to work with them on some projects and had great conversations and discussions – thank you guys!

<!IoRangeNoRedDotMode>

So it’s time for me to move on, there are still so many interesting things to explore and new projects to work on. A big “Thank you” to all of you, who read this blog, who contributed and made this blog a tremendous success. I learned a lot, and we definitely have the coolest blog crew around. It really was a great time, guys!

KTHXBAI!

Todays post is written by guest writer Alexander Seidel, RedDot/Open Text Consultant at webit! in Dresden, Germany. He is working for clients like Deutsche Post, Volkswagen and Telekom Systems. He likes fiddling around with Open Texts Management / Delivery Server systems and bringing projects to a better technical level.

You publish content to the LiveServer, Google indexes it, you delete it, but Google (or any other search engine really) still indexes the page. However when you visit the page it doesn’t exist and you just see a 404 page. What happened? You start investigating with Firefox and the Live HTTP headers add-on to see what happens when you open an URL with non-existent content.

200 OK is not OK for a 404 page

The Firefox add-on will eventually show you that the pages response header returns a HTTP status 200 OK and your, hopefully existing, page not found message. What did you expect instead? The same that Google would expect. A proper HTTP response header status 404 and your page not found message.

After looking around for a solution I set up a little hack. I created a new page (e404.html) in RedDot LiveServer Open Text Delivery Server with the following content:

<rde-dm:process mode="redirect" url="http://your_domain/error_404.html" type="http" status="404">
  <rde-dm:include content="http://your_domain/error_404.html"/>
</rde-dm:process>

The process Dynament can set the HTTP status. Its intended for use with 3xx for moved pages, so it has an URL parameter for the HTTP location header. I changed the status to 404 and I used the error page URL for the URL parameter because it is an obligatory value which needs to be filled in.

The process Dynament allows child elements. That’s the place where I included the real page not found message.

Finally I’ve set the e404.html page as the content not found event in the RedDot LiveServer project configuration (make sure you don’t select the redirect checkbox!). And voila, I’ve got a working 404 error and my page not found message.

One last bit remains. The hack above will still return the following as part of the response header information:
Location: http://your_domain/error_404.html
which is useful for 301 or any other moved page but not a valid information for 404 errors.

Apache mod_headers to clean it up

Using a simple mod_headers modification within Apache can remove the invalid line above from the header data.
Since we don’t know the name of the removed file we have to use a regular expression and instead of using ‘Header unset location’ we can used ‘Header edit’ to fix this.

Just add the following line to your Apache configuration file.

Header onsuccess edit Location ^.*http://your_domain/error_404.html.*$ ""

This will rewrite or furthermore delete your location header to an empty location header. And apparently Apache seems to throw away the empty header returning a proper 404 page with correct header status.

Check your 404 page again using Firefox as described above and you will now have a real 404 error page with your page not found message and correct response headers.

How do you solve this in your LiveServer installation?
How would you do it when using IIS and Helicon as described here?

... render tag code ...

<%!! Context:CurrentPage.Headline !!%>

<reddot:cms>
  <output type="object" object="Context:CurrentPage.Headline" />
</reddot:cms>

<%!! Navigation:OutputArea(breadcrumb) !!%>

If you are starting to build projects and find this useful you should also have a look into the great RedDot CMS tutorial by Adrian Mateljan called “The One True Container – RedDot CMS Tutorial – Part I” which you can find here.

Have you ever tried to deliver anything else than HTML files with your LiveServer? Well, in case you have one of the fancy Open Text Delivery Servers and you have set up the webserver properly (as described here) they should run fast and stable.

For what would I use this trick? RSS feeds!

Now you have for example a RSS Feed to publish but the page doesn’t work in Internet Explorer. Or maybe the XML doesn’t show up properly in Firefox? Eventually you have to find out that the MIME Type is wrong. The reason is that the default MIME type in RedDot LiveServer is set to “text/html”.

Now all you have to do is change it. Lucky there are some RedDot consultants here to help you with this!

How do you tell Delivery Server what MIME type you want?

Whenever you want LiveServer to return something as XML file you have to add a DynaMent to your RedDot CMS content class.
For the correct rendering of your content add this DynaMent at the top ! of your content class:

<rde-dm:attribute mode="write" attribute="request:rdeResponseMimetype" op="set" value="text/xml"/><?xml version="1.0" encoding="utf-8"?>

Tell the DeliveryServer that your MIME type is “text/xml” you will get a proper XML file delivered to all browsers requesting this document.
What other tricks and tweaks do you have for the Open Text DeliveryServer / RedDot LiveServer?

Using a name convention for RedDot CMS elements saves time

So the named examples above become:
“TopLeft” » “con_header” – describing a header,
“Home” » “anc_home” – a link pointing to the homepage,
“GreenSeparator” » “bg_separator” – a separator background.

Now there is no need to open up each element and check the attributes to see what they do. The prefixed name unveils the element type. I have used naming conventions since several years now and it saves me a lot of time.

Name convention list

Using the following list with CMS element naming conventions to enable CMS users to quickly determine element types:

• Anchor: anc_name
• Anchor, graphic: ancimg_name
• Area: area_name
• Attribute: att_type
• Background: bg_attribute
• Browse: brw_next and brw_back
• Container: con_name
• Database content: db_name
• Frame: frame_name
• Image: img_name
• Hit List: hitlist_name
• Headline: hdl_name
• Info: info_name
• List: list_name
• Media: med_name
• Option list: opt_name
• Standard field: stf_name
• Text: txt_name
• Sitemap: sitemap
• Transfer: trn_name

Using a Web Solutions Content Management Server (CMS) element naming convention to enable CMS sitebuilder to quickly determine an element type without checking its properties is a common best practice. By using a common set of element names you will save time and avoid templating mistakes when working within a collaborative team of RedDot developers where everyone speaks the same “templating language”.

Do you use conventions?

I read an article yesterday from J.Boye and you should read it too, here.

Killing a product might make commercial sense for the vendor,
but customers are left to pay for the consequences
- J.Boye

Is it too late to wake up from the buyout fatigue?

RedDot CMS is alive and Open Text confirmed that they will continue their RedDot product line for the next couple of years. Still, there is not much buzz about OpenText’s leading enterprise CMS for the mid market these days. And the discussions about the buyout fatigue last year seem to be more than justified.
After the 2005 acquisition of RedDot Solutions by Hummingbird it was expected that things needed to settle in and development would take some time to gain traction. Another buyout 3 years later gave RedDot consultants and customers the impression to have stopped any momentum for innovation for almost 4 years.

RedDot CMS is still a leader in the ECM market

The CMS remains one of the leading ECM solutions on the market.
New modules and innovations were only available through Open Text partners and motivated RedDot CMS freelancers. Those were for a long time the only ones able to extend the core product functionality while the vendor appeared to be too busy planning new marketing strategies.
Until the release of version 10 not many new features were introduced by Open Text.

History repeats itself – Obtree to be replaced by RedDot CMS to be re.. – hold on – again?

Obtree is another acquisition victim of Open Text and was meant to be replaced by RedDot. Rumor has it that RedDot CMS will be replaced or merged with Vignette.
Now imagine a customers IT manager or marketing director having to explain why they had to move on from Obtree to RedDot CMS and now have to face something completely new again.. Cruel much? Yes. Indeed.
Even in a far future merging those two product lines is not feasible or will end in a disaster as Jon Marks pointed out last year.

RedDot can’t be replaced with anything within Open Text’s portfolio. And it doesn’t have to!

The Marketing 2.0 people at OpenText just seem to be looking at the Executive Summary and the theoretical revenue in Sales for Vignette as an option to replace / crossgrade from RedDot CMS. This is not feasible, not just technically. It is also guaranteed that customers and partners will be jaded and/or run away. How is that for revenue? Exactly. Bad.

Can Vignette maybe replace RedDot CMS?
Read more »

Is it easy to integrate .NET into your RedDot CMS project? Yes it is, if you know how and obey some simple rules. This article gives you a best practice on how to include any .NET functionality for your published website within your RedDot CMS templates.

If you can avoid using inline code within your RedDot Content Classes then do it

Inline code within a content class can’t be versioned as it could be with a version control system when developing standard .NET solutions outside of any CMS. You can’t develop or test properly using inline code within the CMS. Whenever you have to change the .NET part of your project you would need a RedDot Consultant or some of their knowledge and hence your project doubles up on resources. Don’t integrate inline code within your CMS.

Let the CMS handle content – Don’t care about the rest

There is a clear understanding of what your CMS should handle for you – your content – and what it should not take care of – styling and dynamic functionality may it be Javascript, .NET or any other scripting technology. The CMS is your data storage and management layer, the web server is your presentation and visualization layer and hence it is the point where dynamic functionality, styling and user interaction takes place. By keeping those parts separate you ensure to have a stable, scalable and furthermore easily maintain- and upgradeable Content Management Solution. Read more on this topic here

Example – How to integrate .Net properly using User Controls

Instead of just adding a page directive followed by your inline code you should use user controls. Given that your code will be used on your website and not within the Open Text CMS ASP.NET User Controls are the best way to embedded dynamic functionality within your project.
There are basically two points where .NET is included in your template. The first one needs to be in every template which uses User Controls unless you integrate it using a container. The second one works as placeholder for the .NET functionality:

Referencing .ascx files and placing User Controls within templates
Read more »

This article covers the key factors for successful CSS and HTML integration into your RedDot CMS Open Text Content Management Server project. This best practice article outlines the major points to pay attention to when implementing your HTML into the CMS.

What you should do when you integrate HTML and CSS into your content class templates

1. If you can avoid it, do not create templates for your CSS or Javascript files. A detailed post can be found here.
2. Don’t target HTML elements directly within the CSS. Always use classes. Specifically with anchor, image and span tags. If you target HTML elements directly this might affect the red dots which will be placed inside the templates because they are anchors, images and spans.
3. Always target the ‘first’ item in a collection of items (lists, repeating blocks, …) by using a CSS class. Within the RedDot CMS you can identify the first item in a list using ASP and PreExecute script blocks but not always can you identify the last item. Especially when the amount of items is varying and you cannot utilize Render Tags.
4. Ensure dynamic HTML is accessible when switched off. Using Javascript code within the CMS editing view can be problematic because it can hide editable content. Ensure that when using dynamic scripts the content is also visible when Javascript is deactivated. For example when you are using jQuery with tabs and your CMS editor changes content, the page reloads when the element is being saved and the user has to open the tab again. It’s better to deactivate the tabs when the page is ‘open’ and in SmartEdit editing mode.
5. Files such as background images, styles heets, javascript and others need to be referenced relative (../mystyle.css) rather than root or absolute referencing (/cms/projectfolder/folder-not-working-on-live-site/mystyle.css). RedDot CMS has its own folder and sub folder structure and during editing it can’t use absolute referenced style or JS files and will mix those up.

Summary

RedDot CMS is a fairly easy to use system when it comes down to templating. I am not saying it’s straight forward or a technological top notch solution. It also is not meant to be an IDE. The good thing to say about the CMS is that the elements are modularized to each single HTML object and can be used in an infinite number of ways. Pay attention to the best practice rules above and think about where your files and references will be used. When using the guidance above the HTML of your project will run smoothly on any platform and publishing target.

What is your RedDot CMS Consultant integration experience?
How do you use HTML and CSS within the RedDot CMS?
Have you ever had any trouble or even an “CMS integration epiphany”?
Read more RedDot CMS best practice articles here.