Get Enhanced Contributor Editing!

My contributors can add headings, delete rows and auto-insert image ALT text. Can yours? No? Ha!

Well, now they can too, using these replacement HTML Object Properties forms. I have rewritten the standard forms and bundled them together for you to download.

List of new functionality:

• Apply "auto-styles" (CSS class) to text, paragraphs & tables
• Convert or remove text formatting (FONT, SPAN, BOLD etc)
• Convert paragraphs from/to headings (H1 to H6, P, DIV etc)
• Convert table cells from/to table header cells (TD or TH)
• Edit or delete table rows
• Calculate image download size & time (popup alert for oversized images)
• ALT text for image auto-inserted from the image's "Title" metadata
• Set image dimensions & keep aspect ratio
• Set type of numbered list & starting number

Note that no core CS or SS code is modified.

I included a readme.txt file with instructions, disclaimers and other fancy words. Enjoy!

• Download Replacement HTML Object Properties forms (ZIP, 19kb)

How I got H1 Headings into Site Studio pages

One of the biggest frustrations of our users in the inability to insert a standard HTML heading.

"I beg your pardon" you say, "no headings?"

Yep, the Site Studio Contributor application window allows you to only write paragraphs. You can insert tables, horizontal rules, bold text and even classes*, but not headings.

To get around this deficiency, I started by modifying the HTML Object Properties Forms. Being the logical programmer that I am, I tried to create a function that allowed me to replace a <p> tag with a <h1> tag, using the standard HTML replaceChild() method. Unfortunately this throws an error.

It turns out that any attempt to insert a new node in the HTML DOM will be rejected... oddly enough it didn't mind me deleting nodes though. After a while I gave up and forgot about it.

Then the other night as I was trying to sleep I thought "instead of being a nice boy and respecting the DOM, why not just treat code as dirty text and do a simple string replace?" and vola! it works.

I simply grab the node I want to work with and replace its outerHTML with its innerHTML , wrapped in my heading tags. Like this:

g_obj.outerHTML='<h1>'+g_obj.innerHTML+'</h1>';

Now if only I'd thought of that last year...

Oh there's one final twist... you can't use outerHTML on table cells, which sucks when you need to change a TD into TH. To get around this problem you need to replace the entire table!

* When applying a class it uses a FONT tag!? Crazy.

Exporting schema values

We have been preparing our CMS installations for upgrading and basically replicating our production environment for testing purposes. One of the stumbling blocks we hit was exporting schema.

The CMS has two powerful applications for migrating schema... but which does what? Archiver is used primarily to export content while the Configuration Migration Utility (CMU) is a component that exports all sorts of configuration settings. Between the two you can fuddle your way through migration... but we hit a snag. How do we export schema?

Well, we started with CMU. It bundled up all our schema Tables and schema Views quite nicely... until we discovered they were empty of values!

It turns out CMU can't export values in a schema.

So we went back to Archiver and sure enough, it exports schema too, as tables. We found plenty of documentation about exporting table structures... but nothing about values! Anyway we dutifully added all our tables using the default Archiver settings and ran the export/import. Sure enough, all our tables were recreated... and empty!

Obviously this was extremely frustrating... but eventually we worked it out.

Archiver's default settings for exporting tables were the problem. Each time you select a table that contains timestamps, Archiver automatically selects the timestamps as criteria for deciding what values to export. This results in... no values! Make sure you deselect these criteria - they should all be empty.

Metadata Muddling

Ever since we installed our Stellent (now Oracle) CMS I have been anxious about our metadata structure. What is the best way to organise and catalogue our stuff?

The Stellent guys were very pleased with themselves about the fact that we could design any structure we wanted - but frankly we had no idea what to do, we needed some pointers, if not some "best practice" at least some common practice. In the end I believe I composed a decent metadata structure but there are holes in its functionality and, more importantly, in the way people use it.

Here's a rundown on my successes and failures:

1. Don't bother with Security Groups and Content Types. These metadata items actually appear in document URLs and changing them invalidates your links. Accounts do too but they are more useful in controlling access. Note that workflows are restricted to a single Security Group which means multiple Security Groups = duplicated workflows.

2. Don't use abstract definitions for Profiles. We use a number of profiles but our users are confused by them. For example, a user wants to put a PDF on our website. Is this "Web Content" or "Documentation" or a "Publication"? Who cares? Unfortunately I was unable to figure out a better approach and we're stuck with it.

3. Don't rely on "Release Date." Using it for news items and other time-sensitive archives is a bad idea. CheckOutAndOpen replaces the date and release dates can't be changed at all except by checking in a new revision. Make sure you have a "Creation Date" or equivalent metadata.

4. Keep a record of the Original Author. Anyone could edit the item and you won't know who really is responsible for it. Make sure you have a "Creator" or equivalent metadata.

Remember that there are only two ways to change metadata on multiple items - using Archiver or propagating folders - neither of which is simple. Make sure you get it right from the start!