Multiple concurrent file instances

I’m still puzzled about the way in which Rhythmyx allows more than one (publishable) content item with the same file/page name to exist in a folder. This is surely bound to cause confusion?

I’m currently dealing with a remote editor who, in learning the system, has got a bit confused and created up to half a dozen copies of the same page. As a result, of course, there is no easy way to be sure which will “win” when a publishing run is done - it will just be the last version to be published.

Clearly, if some of the content items are Archived or otherwise in non-publishable workflow states, there is no issue. Equally, the concept of promotable versions, which we do not use, would require there to be multiple content items with the same page name - but not multiple publishable ones.

If the next version emphasises WYSIWYG over Content Explorer, which I understand and hope that it will do, I would expect conflicting items of this type to be less obvious to spot and therefore more of a problem.

Is there anything fundamental to stop Rx throwing an error when an attempt is made to transition one item into a publishable state and its file name conflicts with that of another item in the same folder? We did have a custom feature like this in a previous version, but not now, and it seems like something that should be standard anyway.

David,

The output file name is defined by the Publishing Location Scheme. What does your Publishing Location Scheme define as the output file name?

The most typical practice I’m aware of is using the Content ID as part of the file name, such as “Page555.htm”. This should ensure uniqueness. If your location scheme uses this practice, then you should not have a problem, as each Copy has a unique Content ID. That’s essentially what a Copy is: a clone of the Content Item with a unique Content ID, hence a unique existence in the system.

RLJII

We allow editors to name pages, so the page name is a field completed by them. Our page names are usually semi-meaningful. This is, for example, a good thing from an SEO perspective.

David,

Rhythmyx provides two options to deal with your situation.

The first is to write a new Relationship Effect extension that disallows the addition of Content Items to a Folder if the Folder already contains a Content Item with the same value in the field you are using to specify the file name. This option requires Java coding, but will result in a cleaner system.

The other option is to add a Cloning Rule to the Copy Relationship that modifies the value of the field you are using when the Copy is created. The Copy Relationship already has a Cloning Rule for the sys_title field (makes the value of this field “Copy n of System Title”). Use that rule as a model for your new rule. This option is simpler to implement, but you will have extra Copies floating around in your Folders and possibly some extra HTML files published out as well.

For more information about the last option, in Implementing the Rhythmyx Relationship Engine, see “Overriding Content Item Fields in Clones”, p. 59.

RLJII

Thanks - we’ll look at that. However, I am still of the view that Rx should do this by default, as I cannot see a reason for having two publishable files with the same name in the same folder.

Regards