Auditing of published content is an increasing concern for organisations specially when content on the site need to be legally protected, for example: interest rates, mortgage rates etc. Auditing of site content is always a challenge when generating dynamic pages and with increasing personalisation, its even getting tougher each day. Same goes with WCS a.k.a. Fatwire implementations. So, how can we audit within WCS which could provide enough coverage for auditing content.
What comes OOTB?
WCS comes with versioning feature at asset level, controlling the number of versions to keep. So, either with each edit, a new version could be created or it could be explicit with each check-out/ check-in. Having versioning at asset level do help in tracing back the content at certain point in time. But since actual WCS page consists of number of assets, there is no easy way to know on which page the asset was associated at that point in time. And if the content is related to page through few asset associations, it almost becomes impossible.
Fatwire has always been asset based content management system. By that I mean, that content authors create content items in isolation and then attach/associate them to one another and finally to the page asset which displays whole page. What it gives is:
Reusability of content
Meets the manta of one instance of content displayed in various formats across different channels
I lately worked on a project where we hosted Fatwire as active-active across two data centres. And the most challenging part was to make CAS work across cluster members within a cluster. And one of the main reason was difference in the Internal and External URLs for failover.
This blog post is to highlight various properties related to Central Authentication Service (CAS) across CS 7.6.1 and CS 7.6.2
As continuation of Asset modelling, one of the other most common question is how many flex families to define as part of the modelling. Number of basic asset types required is straightforward but may not be the case for Flex families.
A normal flex family relationship is as shown below:
Flex Parent Definition
Flex Child Definition
So, we define a set is attributes which forms part of parent and child definitions. These form the templates to organise content through creation of parents and creating content through child assets. Straightforward till now. The flexibility comes as database model allow to add new attributes, modify existing definitions without any database level changes.
If that’s not enough, another aspect of flexibility is that you can use same attributes to define different asset types at each level i.e. parent definition, child definition, parent or child. And again you can mix and match.
Flex filters are powerful way of post processing the information of flex assets determined by supplied attribute values or otherwise. They are powerful way of achieving post processing on Flex assets ONLY. Flex filter is called when the asset is saved, provided filter is part of the asset definition. So, if flex filter is added after the content is already created, the assets need to be re-saved in order for flex filters to take effect on those assets.
Lets start with few quick Filters which are shipped with WCS:
Doc-Type: Extracts Mime type of uploaded file type and store as part of an attribute value within asset
Thumbnail Creator: which converts an uploaded image to thumbnail image
Field Copier: copies contents of system defined attribute to user defined attribute
Document Transformation filter: which converts the document uploaded of one type to another type using registered transformation engine
In my previous post around Attribute Editors, I covered what we could achieve by attribute editors. But Flex Filters could be another option to achieve some of them.
Recently, there has been a number of discussions around advantages of upgrading from 7.x to 11g and what are actual benefits of upgrade. There are number of good blog posts around what has been new to 11g Some of them are:
New Content Authoring UI (Separation of Administration UI and Content Contributor UI)
The new content authoring interface looks good with all drag and drop features, multi asset editing via tabs, searching across multiple assets. All looks great in demo’s.
But is that really the story?
Drag and drop feature is great but it is not something available out of the box after upgrade. The templates need to be updated with new insite tags. So, depending on the site structure this could be a quick change or could evolve a small project within itself
Most of the implementations I have worked on end up with number of customisations. Till 7.x as Advanced UI was the main authoring interface, most of the implementation has modified it to meet customer needs. Porting all such customisations to new Content Contributor could pose a challenge
Multi asset editing via tabs is great when the number of assets to work on is limited. But consider a scenario where number of asset change required is more than 15+ then it could become real trouble for content authors. At a time only 4 tabs are shown by default in the space and so if there are 15+ assets, it could be too much of back and forth.
Searching across multiple assets is great and could bring benefits to content authors.
Training is important aspect which needs to be considered
While designing asset model, it is important to understand the kind of flexibility required by content authors to arrange content. Is there a need of fixed hierarchy or a flexible hierarchy or a combination of two. Lets look at what I mean by fixed and flexible hierarchies:
Attribute editor defines how content is entered for the attribute when displayed on a content entry form wether to provide text area or text box or date picker or integer or money value etc. WCS, by default, defines attribute editors for each data type and used when there is no specific Attribute editor defined against the Attribute.
While carrying out asset modelling, it is good to define kind of attribute editor against each attribute. Right attribute editors could enhance the content authoring experience a great extend. Few examples to expand on the point:
An attribute store email address: We mostly will define data type as String and will leave it to default attribute editor. But if we could define a new Attribute editor which does all the validations for email address, it will benefit both content authors as well as developers. Content authors will not be allowed to enter wrong content and developers do not need to worry of extra checks in the template
An attribute which doesn’t allow special characters: Again we mostly will define data type as string or text and will leave it to default attribute editor. But if the validations are added at the time when content authors are filling in the content, it will bring double benefits.
An attribute which is unique across Asset type and is disabled for change after asset is created. Neat way of highlighting content authors what they can and can’t do
A name/ value pair required from content authors. Example: query string parameters for url. Instead of storing name and value in two separate attributes, we can have one attribute which is presented as two text boxes to enter name on one side and value in other. this could then be stored as part of same attribute, separated by “=”. Again easy for content authors to enter data and easy at coding level to get both the values in pair.
Attribute is mandatory in certain conditions but optional other wise. Again attribute editors could come to rescue
So, the point which I am trying to bring home is Asset modelling is not just how efficiently the content is getting stored but also providing the right editors for content authors to make their life easy and enjoyable with CMS usage.