I came across this top tip a few months ago to reduce the size of the Site Manager logs.

If you find that a large proportion of your log files contain more-or-less pointless messages about formatters not being found you can add an environment variable to prevent Site Manager from adding these messages to the logs.

I’m using Site Manager 7.4 Revision 0004. If you’re not sure about whether this tip works with your version of Site Manager contact T4 for advice.

Gareth (Web Architect at the University of St Andrews) passes judgment on T4 Site Manager.

This morning 11 T4 administrators and users from the universities of Abertay, Dundee and St Andrews gathered in the moot court room at the University of Dundee for what is hoped will be a regular, quarterly meeting.

The idea for a smaller, regional T4 group arose from a conversation between Ross Haggart (Dundee) and myself at the most recent T44U conference in Dublin in November. A wider group of T4 admins used to meet prior to Scottish Web Folk meetings but as these haven’t met for a while it was felt that perhaps a local group might be useful, to share ideas, lessons learned, best practices, code snippets and hacks, etc.

Over two hours this morning we talked about general issues surrounding content, editors, internet vs intranet, style guides, TerminalFour Site Manager vs Microsoft SharePoint (“install in a day, configure in a lifetime” … using a dedicated team of .NET developers) before turning our attention to the technical aspects of how we have configured Site Manager at the three institutions.

This is something that Laura from T4 mentioned in the T4SMACAD-L mailing list a couple of months ago that I’ve found useful and have enabled on our version of 6.2.0033 at the University of St Andrews.

As of Site Manager 6.2.0033 and 7.0.0010 the T4 meta tags with a type of html_anchor now have an XHTML-compliant option so that you can use the id attribute rather than the name attribute.

Environment variables

To enable the XHTML-compliant option you need to add two new variables on the Environment Variables page and then set them both to true. The new variables are:

xhtml-output

xhtml-strict-output

Example

So, for example:

<t4 type=”meta” meta=”html_anchor” />

might generate this fragment identifier:

<a name=”d.en.123”></a>

With the new XHTML-compliant options enabled it would now generate this:

<a id=”d.en.123”></a>

This is good news for those who don’t like to use the older ‘name’ attribute.

Option to choose which element would be nice

Prior to HTML 4 the only way to create a fragment identifier was to to use the name attribute on an anchor tag <a>.

As of HTML 4 practically any element can be used, with an id attribute. Being picky now, it’s just a shame there isn’t a further option to allow you to specify the element that you would like the fragment identifier to be an attribute of, e.g. an empty <div> for example.

We upgraded to 7.0.0010 in mid-2011 from 6.2.0030. Generally speaking everything has been behaving as it should but in November, the publish started to hiccup for no apparent reason.

This was very quickly traced to our not having enough database connections configured – we were told that we’ve had the same number configured almost since we installed T4 back in 2004 but that v7 needs significantly more.

We increased from 20 to 200 and all is well once again.

The top tip? Make sure T4 / your infrastructure support people check the number of database connections allocated is appropriate for your install.

Here’s a feature of Site Manager that we’d not come across until now, and which isn’t particularly intuitive which is why I’m blogging about it.

The problem

We simply needed a way for Site Manager to output the URL of the current section. We knew about the section details navigation object but couldn’t work out how to tell it to use the current section rather than specifying a specific section.

The tooltip for the Section option says:

If the section method is chosen above, then the item will display the details of the section specified by ID here. If the ID is set to ZERO, the current section will be used for generating output.

Which is fine but we couldn’t work out how to set the ID to ‘ZERO’. We emailed T4 client support who, as usual, were very helpful and pointed us to this announcement on the T4 Extranet: Output the URI of the current page.

Just in case any of you running [Site Manager] 7.0 haven’t spotted the posting on the Extranet, Facebook & Twitter, we have a database index that you should apply if possible, that may have a very positive impact on publish performance depending on your configuration.

It would be great to hear if folks have followed the advice and what impact it has made on publishing times.

Last week I was working on embedding an MP3 file onto the University website so I thought I’d write about it here in case it helps someone else. We’re using Site Manager 6.2.0032.

WordPress Audio Player

As the embedded player we’re using the standalone version of the excellent WordPress Audio Player which uses a combination of JavaScript and <whisper>Flash</whisper>… which means no iPhone/iPad support and a flood of hatemail from HTML5 aficionados.

Audio Player is released under the Open Source MIT license, which gives you the opportunity to use it and modify it for your own use.

which drops into the WordPress Audio Player code the appropriate file path, name, description and file size.

Obviously the download paragraph is optional if you don’t want end-users to be able to download the MP3 file directly.

Also, if you want to include more than one player on the same page you will need to change the first paragraph ID (<p id="mp3">) so that each player has a unique ID, e.g.

<p id="audioPlayer_1">...</p><p id="audioPlayer_2">...</p>

We use PHP code to generate a random alphanumeric ID but you could create a template for using with the MP3 files if you wanted to go down that route.

JavaScript

The final step is to ensure that the supporting JavaScript file is linked to on the page, and that the audio-player.js and player.swf files are in the Site Manager media library (and linked to from an ‘includes’ file to ensure that it publishes out… if you’re not using a version of Site Manager that will manage that within the Media Library itself).

We use a related content navigation object to look for a sub-section called rel_jquery which then drops whatever it finds in that section just above the closing </body> tag. So that’s where the audio-player.js file goes, linked to from the Media Library using a template we have for… well, linking to media library items.

Why we did it this way

The only minor faff about doing it this way is remembering to include the rel_jquery section and accompanying JavaScript file otherwise it’s been a really useful way of including links to MP3 files with an accompanying embedded media player.

That way the users just needs to upload an MP3 file into the Media Library and link to it within a piece of content without needing to use a particular template.

A couple of weeks ago someone pointed out that we had a very subtle problem with publishing updated content to the live Web server which has led to us reorganising how we manage publishing, and has actually duplicated work in some cases.

Publishing workflow

Our publishing workflow is as follows:

Publishing workflow

Publish locally
At 30 minutes past each hour Site Manager publishes the university Web site to a local directory, let’s call it the staging server.

Transfer changed files
On the hour rsync (we were using Transfer Manager until a problem prevented us from using it) copies over the changed files from the staging server to the live server.

The problem

The problem is, however, that we have no control over which files are copied first. So we would repeatedly receive helpdesk calls from users complaining that images on the homepage were missing, downloadable documents were not present, or RSS feed links led to a 404 page instead of the full news story.

It turned out that the issue was to do with the order that files were copied over from the staging server to live: some web pages were being copied over—sometimes minutes—before any related or supporting files.

The solution

Our solution was therefore to schedule two rsync synchronisations. About 10 minutes before the whole site synchronisation takes place we run a first sync on just the content of the media library (images, documents, videos, etc.).

Then 10 minutes later we run the full sync on the whole site which means that it doesn’t matter so much on the order of the files being copied over: the supporting media library items are already on the server.

Conclusion

I don’t like that workaround terribly much, to be honest, as it means that the contents of the media library is being copied over twice but it’s worked so far and the number of calls that we’ve received about missing content has dropped completely (so far).

We’ve recently been reviewing how we publish our website channels with Site Manager. Until now we’ve been employing a mixture of publishing some channels directly to the web server, while publishing others to a staging server first and then synchronizing on the hour with Transfer Manager.

We then hit a problem about two weeks ago which has now encouraged us to publish everything to a staging server and synchronize with the public web server using rsync.

I thought it would be interesting to see what setup other people were using, how well used is Transfer Manager against rsync, what other options are there?

This blog was set up primarily for support and collaboration between those members of Scottish Web Folk (those involved in web development and management from all the higher education institutions in Scotland) who use the TERMINALFOUR Site Manager enterprise content management system.