CMS Blog
Why should we deploy from Teamsite editions?
I've seen many Teamsite implementations that deploy from the Staging area. This is not optimal and let me explain today why I think so.
Teamsite has excellent version management capabilities that will give you an historic archive over your website, if you chose to use it by creating editions before you actual deploy them. By passing this feature will leave you with a teamsite implementation that misses out on one of the most powerfull features. Apart from this rather theoratical reason there are also some more pratical reasons:
1. you will loose the option to rollback your website to a previous edition
2. the staging area is not garantueed to be stable during the lifespan of the deployment, which can give unexpected results
3. you will not be able to compare editions to know what has changed in between two deploys
4. you will not comply anymore with tracebility requirements (like f.i. the Sarbanes-Oxley laws)
A simple Interwoven Teamsite wish list
I've written before about major teamsite design goodies & badies. Today let's have a look at some major day-to-day annoyances of teamsite. A simple "Interwoven Teamsite Wish list". Because these items are not so much tied to the design these should be easier to fix for Interwoven. ;-)
1. I think some major entry-field types are missing in Teamsite Templating (oeps sorry, "Formspublisher" we should say). Most important is a proper date-time field type with date-picker. I know there is a workaround in which you download a calendar-cgi which you call in a callout. But that sucks because it's features are very limited (date formats, time, ...) and once downloaded it's YOU who must maintain the code. And that is not why you bought an expensive cms, did you?
Another field type missing is a read-only field. Again the workarounds here are not good enough. Using the read-only field type leaves you with a field that is too large, using form-api is too complex and sensitive for such a simple wish. And also, you want to be able to create read-only dropdowns & checkboxes.
Last field type worth mentioning is the hidden-type that would take a default value.
2. The 'custom menu items' should be made sensitive to branch or workarea the user is in.
3. The current file-browser that you can use in Teamsite Templating should be extended. First of all it should be enabled for cross branch browsing, fully configurable of course. Second, one should be able to call the import-function from within this browser. So, in case a user is browsing an image file and find it missing, (s)he call upload it with 1 click.
4. Some sort of link manager should be included within the Teamsite gui. It should be able to list all broken link on a page and/or website. But also it should warn you when you (re)move file that is referenced. (In an ideal world it would then update the references but maybe that is too much to ask for)
5. Teamsite services should use log rotation. This would prevent this ever growing log files under <iw-home>/local/logs/iwui. Unfortunately, one can not rotate the logs via a script when Teamsite is running.
6. Email tasks in the workflow engine is cumbersome. You can use the email-script that are supplied by Interwoven as part of the installation, but they are poorly written, error-prone and once you use them it is, again, you who must maintain them. The better solution would be, for Interwoven, to add a attribute to a user/group-task 'email-task-owners-on-activation' that would trigger the workflow engine to send a email to the task-owner(s) when the task becomes active. This email should be send by a process that is completely maintained be Interwoven (and thus when it fails you can call iwov-support). Clearly some extra custom-configuration is required for this, like smtp-details and a user-to-email-mapping.
Let's hope some Interwoven employee reads this and add these useful enhancements to their product. It would really help us all. :-)
Better Google ranking with WEC Discussion Forum
I found out that my cms-blog was not very high up in the google-rankings. Even if you would search for the exact blog-item title you could still only find me on the 4th page or so. We can do better then this.
So to improve my ranking I wanted to change two things to the default install of the Typo3 WEC Discussion Forum. I wanted the blog title to show in the page title, I want to have the item title in the url and, while we are at it, I want the home-link to link to '/' instead of something like '/Home.2.0.html'.
Here we go:
1. Add the blogitem title to the page title
Add this code to the page template of your page that contains the wec plugin. NOTE: do not add this to the root-page of your website!:
config.noPageTitle = 2
page.headerData.20 = TEXT
page.headerData.20.value = Your site title
page.headerData.20.wrap = <title>|
page.headerData.30 = TEXT
page.headerData.30.value = Your Blog title
page.headerData.30.noTrimWrap=| - ||
page.headerData.40 = TEXT
page.headerData.40.value = Overview
page.headerData.40.noTrimWrap=| - ||
page.headerData.50 = TEXT
page.headerData.50.value = </title>
[globalVar = HTTP_GET_VARS|tx_wecdiscussion|single>0]
page.headerData.40 = CONTENT
page.headerData.40{
table=tx_wecdiscussion_post
# wrap the whole element
wrap=|
# the SQL-Query
select{
max=1
selectFields=subject
pidInList = 21
andWhere.data = global:HTTP_GET_VARS|tx_wecdiscussion|single
andWhere.wrap = uid='|'
}
renderObj=COA
renderObj{
5=TEXT
5{
noTrimWrap=| - ||
field=subject
}
}
}
What this does, in short, is, if the url contains the 'single' get-variable, if queries the wec-table for the item title and add this to the page-title. Simple enough, isn't?
The inspiration for this trick came from Infohit
2. Give our blog a pretty url (in the single item view)
First install and enable the realurl extension, if you haven't done so already. The manual describes this well enough.
Then you need to add this code to your existing realurl configuration (in localconfig.conf):
'postVarSets' => array(
'_DEFAULT' => array (
'view' => array(
array(
'GETvar' => 'tx_wecdiscussion[single]',
'lookUpTable' => array(
'table' => 'tx_wecdiscussion_post',
'id_field' => 'uid',
'alias_field' => 'subject',
'addWhereClause' => ' AND NOT deleted',
'useUniqueCache' => 1,
'useUniqueCache_conf' => array(
'strtolower' => 1,
'spaceCharacter' => '-',
),
),
),
),
'archive' => array(
array(
'GETvar' => 'tx_wecdiscussion[show_date]',
),
array(
'GETvar' => 'tx_wecdiscussion[archive]',
'valueMap' => array(null => '1'),
),
),
),
),
This code above will give you a url like '/cms-blog/view/top-6-of-badly-designed-teamsite-features/', just what the doctor ordered.
3. Make your home links link to '/'
This is not so easy with realurl, unfortunately. You'll need some php code. :-(
First you need to add this class to an existing (or create new) php-library file, normally located under /fileadmin:
class user_tweakMenu {
function replace( $I, $conf ) {
$I[ 'parts' ][ 'ATag_begin' ] = preg_replace(
'{' . $conf['searchFor'] . '}',
$conf['replaceWith'] ? $conf['replaceWith'] : "",
$I[ 'parts' ][ 'ATag_begin' ] );
return $I;
}
}
Then, in your template (at the site root level) you'll need to add this code (customise it to your situation and needs):
includeLibs.include1 = fileadmin/my_include.inc
temp.menu.1{
IProcFunc = user_tweakMenu->replace
IProcFunc.searchFor = /home/"
IProcFunc.replaceWith = /"
}
This trick is well described by Hannes Schmidt
About
Cms blog is a personal view on current web-cms technologies, written by Ronald Verheul, founder of Contentdokter, an independent consultancy specialised in designing and building web content management systems.
