I just realized users can remove folders from a site, even when that folder contains items. (Those items are then automatically orphaned.) Is this normal? I believe this is causing many issues in our solution. Can it be prevented?
It’s normal.
Rhythmyx itself has no requirement that an item be in a folder. Many sites are designed that way, however.
The only way I can think of (right now) to prevent this is to write a relationship effect that prohibits removing a public item from a folder. This would prevent the issue you are talking about, but it would also people from dragging items from one folder to another.
Maybe somebody else will think of something more creative.
Dave
We have resolved this by only giving certain roles the authority to remove an item.
I was thinking more in terms of, “Operation cancelled, folder cannot be removed unless contained items are purged first!” Similar to how user cannot move a folder while contained items are in Public.
I agree this would be useful.
We had a problem with users confusing “remove” with “purge” on content items. Sure, folders are content items too, but hitting remove on a folder places all of the non-folder content items contained therein into community content and the folder itself is essentially purged. However, hitting remove on a non-folder content item removes the item from the folder and places it in community content. We’ve found that the whole idea of “community content” that doesn’t live in an actual folder structure seems non-intuitive to our users. I just tell them that community content without a folder path lives in the ether.
We ended up disallowing the Delete action menu on a non-folder content-item by limiting the Usage > Content Explorer - Main Display Area > Used in UI Context to Folder, Site, and Site subfolder. Alternatively changing the Visibility > Object Types > Hide on Item would probably do the trick. Your mileage may vary.
While only admins and designers really see it, I find it interesting that the name of the action menu is “Delete,” with a label of “Remove from folder,” not to be confused with the “Purge” action menu.
We’ve limited the Purge action menu to only the Web_Admin role. Therefore, with this configuration of Remove and Purge, we end up with a lot less confusion about items being “removed” and still showing up in a search. We also have a state in our workflow labeled as purge, so that non-Web_Admin users can indicate to their Web_Admin that there is a need to purge something, but the final decision is the Web_Admin’s.
Why are we going through all this trouble? We expect to have over 2000 users when we’re in full swing. With a user base that large, we’d like to limit the number of ways a user can take aim at their own foot.
So what good is “community content” that doesn’t live in a folder? I’ve only found that the concept is confusing to end-users. Does anyone use it for a practical reason?
Lastly, it’d be great if there was a pop-up, as already proposed in this thread, that clarified what “Remove from folder” means in the larger context of that folder’s contents.
Darrell,
It would be great if the world were so simple.
I can assure you that we do have a number of customers for whom the “folder” metaphor of a website is not only inconvenient, but actually impossible to maintain (because they don’t categorize content that way).
These customers tend to be in the “online publishing” business rather than in the business of constructing lots of “subsites” (which is the way I would characterize your use of Rhythmyx), and they re-use the same content items in several different locations.
Also, Rhythmyx didn’t start out with Folders. Early versions of Rhythmyx (like early versions of some other CMS systems) didn’t organize content in folders. So at some point in the past, all content was in the “Ether”, and it was published by executing queries (based on categorization fields stored in the content). It’s very difficult for these customers to change over to a folder model (and they complain loudly when we try and make them).
Dave
Ah… legacy… 
It’s not just legacy.
Let’s say I want to produce a new “magazine” site about digital photography. The editors of my site select the topics and they assign authors to write articles about various topics, including (for example) “Lenses”.
After a while, which might be a year or two, I will accumulate a rather large number of articles about Lenses. There are a number of ways I could deal with this situation: I could remove some of the older articles from my site, I could try to figure out how to subdivide the “Lenses” folder (by time, by topic, by author, etc), or I could just decide that I don’t really need folders in the first place.
In the case I’ve just described, the site doesn’t really need folders: I could just have “autoindex” Pages for the most recent articles in each section and some sort of Search mechanism for visitors to my site who are looking for a specific kind of Lens. The authors of the content don’t need folders: they only write articles on the topics assigned, and they just need to find the article again to edit it after the editor gives them comments, etc.
Sites like this don’t usually just publish flat HTML pages: there’s usually some database publishing involved, perhaps in combination with file system publishing, and there’s usually a dynamic component, which can be anything from ASP to Cold Fusion to WebLogic Portal. (The advantage of being decoupled is that we don’t particularly care).
While it’s true that some of the earliest Rhythmyx systems were built this way, we have more recent customers who use this model, and (hopefully) more are on the way. In addition to sites that look like “magazines”, many “travel” websites also work this way.
Of course, for most customers in these categories, Rhythmyx is not their first system: they come to us only after whatever they are using (which likely as not was home-grown) has reached the breaking point. They usually walk in the door already having too much content in too many categories to comfortably fit into a Site Folder based system, so we don’t try to force them into Site Folder Publishing if it doesn’t fit what they are doing.
While it’s true that we could make the “Site Folder” approach more seamless, we can’t just prohibit users for entering content that is in “no folder”. I know from first hand experience: we accidentally introduced a bug (in 6.1, I believe) that caused sites without folders to break in a strange way, and we heard lots of complaints as soon as this started happening in the field. We had to scramble to create a patch to undo the problem.
Dave