The problems with 'overpublishing'

One thing that has always bugged me about RedDot is that publication report as long as your arm. The first thought that runs through my mind is always "what the hell did I just publish?" On closer inspection, it usually turns out I've published one or two pages and ten images.

Now, that might not sound like a big deal, but when the image is "logo.gif", it's included (indirectly) on every page, and it gets published out with every single page, that's a bit more of a problem. RedDot's default mode is 'publish everything out', not the far more obvious 'publish out only the things that have changed'.

Why is this a bad idea?

1. Every write to a disk shortens that disk's life. It may be imperceptible, but it's happening. Probably not a big deal compared to all the other stuff that's writing to your disk, but certainly a flaw when it's absolutely unnecessary.
2. It considerably lengthens the time to publish, especially when you take documents, sound, or video files into account.
3. Your web server's sending out useful 'Expires' headers that tell the client not to request another copy of your logo because it never changes, right? Not any more.

Now, to workaround for RedDot's bug.

One option is to write-protect your long-term images, documents, etc. RedDot will still try to write to them on a publish, it'll just fail. This should fix problems 1 and 3, but you'll still experience lengthy (possibly lengthier) publication times.

RedDot offers an option to never publish images (even if they have changed) which is one possible solution, but you'll need to educate all your content authors / editors to rename image files when they update them. This may or may not be possible.

Failing that, you could actually remove image management from RedDot altogether. Let's face it, the media browser is pretty terrible, so managing the files directly on the web server (maybe using a better alternative front-end) could give several benefits. Of course, all your image references in markup will then need to be absolute (unless you're running RedDot on your web server ...) which could cause further problems.

I'll be investigating that last option - more soon.

Long time, no post

So, it's been over two weeks since my last post; the post-a-day aim has failed spectacularly. I've been on holiday for a while, so don't worry, the cause is certainly not lack of material. Over the next few days, I'll see if I can catch up a bit, and I'll also throw a slightly new format into the mix.

Rather than posting on individual 'gripes' and 'goodies', I'd like to just run a commentary on what I'm doing with RedDot, what goes well, and what fails. I'm hoping this will make for more balanced information, whilst still highlighting my grievances with the product. For example, if a problem is such only because of a poor implementation, I'll rightly absolve RedDot.

It's become obvious to me, recently, that poor organization is probably more culpuble than RedDot itself when it comes to many of the issues I've faced. I hope you enjoy reading what I have to say.

Gripe #7: empty field values

Not a lot to say about this one, it's just so obviously wrong. An empty value isn't really an empty value, not according to RedDot. An empty value is treated in the same way as not specifying a value i.e. the default value overrides it.

This is just so incredibly annoying, and I cannot fathom quite how it can't be fixed. Surely it's a no-brainer? The workaround always involves doing stupid things like putting in an HTML comment for the value. Crazy.

Gripe #6: target containers

Target containers seem like a great idea. In fact, they sound like an absolute necessity, until you actually encounter them in use and, in RedDot's case, forced misuse.

A target container is much the same as any content inclusion mechanism; the training manual describes them, intriguingly, as a combination of server-side includes and iframes. The one drawback RedDot has over (possibly all) other inclusion mechanisms is that it only allows one inclusion. Well, one inclusion per link to be fair and correct.

This only really dawns when:

• You start thinking about the nature of linking and whether links should only be able to lead to full pages, changes in one part of the page, or changes in several parts of the page. Each is vastly superior than its predecessor.
• You end up with an 'unbalanced' template: one whose open/close tag pairs do not match up.

The latter seems inevitable in any reasonably structured site that uses the one-hit target container, and causes untold problems involving trying to fit a 'good' template into a 'bad' hole.

I'm sure there's plenty more to be said about the dreaded target container; this is only the beginning.

Goody #1: regular expressions

Yup, even I think that RedDot gets it right from time-to-time, and just when you think this CMS might have abandoned or ignored every standard you're familiar with, you come across user-defined fields and realise it's done the right thing. A user-defined field can be restricted - to the extent allowable - by a regular expression, allowing for flexible, user-defined types. Well done, RedDot.

Gripe #5: date formats

A minor gripe about standards, this one. 'Standard field' placeholders with a date type use 'Microsoft conventions' for formatting. Not being familiar with Microsoft programming, I had to hunt quite a bit for these 'conventions' ... In every other web application I've used where date formatting is specified - the most obvious examples being apache and php - the standard strftime formatting is used. Why reinvent the wheel here?

Gripe #4: publishing the unknown

Performing an action can be dangerous if you don't actually know what the results of that action will be. This applies to website publishing, much as it does in real life.

When you publish a page in RedDot, you are given three options:

• Publish just that page
• Publish that page and 'related' pages
• Publish that page and 'following' pages

To understand what will happen, you need at least two types of knowledge:

• An exact understanding of what the concepts 'related' and 'following' mean
• An understanding of exactly which pages are contained within the relevant set

The first is tricky, partly because the two concepts are not embedded within the general structure and use of the CMS. There are many levels of indirection involved, and neither concept - in particular, 'following' - really has a direct equivalent in a standard HTML structure.

The second involves either a deep knowledge and familiarity with these concepts, or a great deal of manual inspection. Or trial and error.

Furthermore, the concept of a 'page' needs to be borne in mind, particularly when a 'page' is, in fact, a component that might belong on many pages. Even publishing 'just a page' may result in publishing hundreds of actual pages, if that page is, for example, a footer. That's a vitally useful operation to have at your disposal, but it's confused by the notion of 'related' pages.

Add in publication packages, and project variants, and there results a huge number of factors in determining exactly what will happen when a page is published, an operation which is one of the most basic, and fundamental there can be.