stressfree - drupal

Customising the number of Drupal's TinyMCE buttons

admin — Wed, 20 Aug 2008 22:51:26 +0000

I have recently upgraded the site from Drupal 5 to Drupal 6. This was no simple task given the level of API changes that occurred between releases.

Note to Drupal community: If you want to be taken seriously in the 'enterprise' world you need to be backwards compatible with third-party modules. Forcing everyone to completely rebuild their modules and sites every year is not a viable option.

Anyhow I use the TinyMCE module for writing posts but do not like the default way it takes up half the textarea window with wasted grey space (see below):

To get around this problem edit the modules/tinymce/tinymce.module file and change the line that reads:

$min_btns = 5; // Minimum number of buttons per row.

To something more sensible like:

$min_btns = 30; // Minimum number of buttons per row.

This will give you an editor that is far more space efficient and better looking:

drupal

Making Drupal's TinyMCE module produce domain absolute URLs

David — Fri, 08 Jun 2007 00:01:25 +0000

By default Drupal's excellent TinyMCE module will convert domain aboslute URLs (e.g. https://www.stress-free.co.nz/sites/default/files/u63/drupal_logo.png) into plain old absolute URLs (e.g. /files/u63/drupal_logo.png). Generally this is not a problem so long as you do not want to use an external web service such as FeedBurner for your RSS feeds. Unfortunately FeedBurner does not handle plain old absolute URLs very well. This is because the domain name for your FeedBurner enabled RSS feed is feeds.feedburner.com and any absolute (or relative) links in your post try resolving to this domain name rather than the original website.

In a perfect world FeedBurner would parse incoming RSS feeds and replace absolute/relative URLs with domain aboslute URLs to ensure everything works (or maybe it can and I haven't figured out how to do this). Fixing this problem in Drupal when you are using the TinyMCE editor is a little tricky because TinyMCE tries to be helpful by replacing your domain absolute URLs. To get around this we have to tell TinyMCE to leave these URLs alone and convert any new absolute or relative URLs into their domain absolute equivalents.

To achieve this edit the modules/tinymce/tinymce.module file in your Drupal site and change the following lines (line numbers relate to 5.x-1.x-dev release of the TinyMCE module):

Line 494 change:

$host = $base_url;

to your site's domain name:

$host = "http://www.yoursite.com/";

Between lines 505-506

$init['relative_urls'] = 'false';
$init['document_base_url'] = "$host";

add the following extra parameter:

$init['relative_urls'] = 'false';
$init['remove_script_host'] = 'false';
$init['document_base_url'] = "$host";

These settings are taken from the TinyMCE FAQ on the subject. Once you have made these changes you should find TinyMCE behaves itself much better when it comes to using FeedBurner.

html
drupal

Capturing workplace knowledge with Drupal

David — Wed, 06 Jun 2007 12:03:11 +0000

Formally recording what we have learned in the workplace is a worthwhile process that is often forgotten or not undertaken because there is no time or immediate incentive to do so. Web-based technologies such as wikis and blogs have demonstrated that enabling people to quickly publish and publicise their knowledge within their peer group is potentially a very powerful means of undertaking collaborative knowledge capture. This article explores how Drupal, an open-source content management framework can be used to facilitate this process in a community centric manner.

So much to know, so little time

A workplace such as an architecture practice generates a lot of 'on the job' knowledge which at the time can seem obvious or worthless but afterwards can be invaluable. Such knowledge can range from the most appropriate window detail to use in a certain situation, to the most efficient way of modeling that window detail in the office CAD package. Usually these little morsels of knowledge are never formally recorded because it is just more work that typically is not budgeted for, or acknowledged by, management. As a consequence finding an answer to one of the aforementioned questions becomes dependent on your ability to understand the workplace's knowledge topography (i.e. who knows what). But even though it maybe common knowledge in your workplace that Bob has a collection of decent window details or Andrew 'the CAD guy' will help you out, what happens when they are not available, or even worse quit their job to work at the more fashionable architecture practice across town?

Technology to the rescue (sort of)

During the later bit of the 20th Century 'knowledge management' was a buzz-word because to a certain degree it was felt that with the onset of the 'knowledge economy' we would all soon be drowning in a big sea of knowledge (that's a lot of knowledge). Consequently many complicated and expensive systems were developed to act like sponges and absorb all this dangerous knowledge. Unfortunately whilst many of these systems did an excellent job of storing and searching the information that was put into them, the highly structured manner in which this data had to be entered made it painful for the average, overworked and under-appreciated employee to undertake. It must of come as some surprise to many employers when they realised that whilst their employees were not using their expensive workplace knowledge management systems they would gladly spend hours of their free time (and no doubt some of their employers) writing blogs and participating in wikis such as Wikipedia on the public Internet. Given the massive adoption of both technologies it comes at no surprise then that we are now trying to understand how to leverage these tools in order to capture workplace knowledge.

What are these two Web technologies and how are they different? At its simplest form a blog is a series of chronologically ordered texts casually written by a single person on a subject matter of their choosing. In contrast a wiki is generally a more formal and structured set of documents that any (authorised) person can edit how they see fit. Both are similar in that the processes of publishing and publicising new content is instant which provides immediate gratification and information for those partaking in the process. However whilst conversation in the form of comments is encouraged around both, blog comments generally spurs open ended debate, whilst comments on a wiki are usually intended as feedback for improving the underlying document.

Mixing and matching to find a combination that suits your environment

Ignoring technology for a moment a workplace's knowledge cannot be translated purely into an encyclopedic-like volume or assembled as a collection of personal thoughts. The best strategy to adopt in this environment is a 'horses for courses' approach. Some aspects of the business will be recorded and utlised most efficiently as a wiki-like document, whilst extracting nuggets of personal knowledge from employees will require a blog-like environment. However what is most important is that a healthy and incentivised environment for conversation needs to be created for all employees to participate in. The last thing a workplace needs is for the platform to become a venue for one person to blow their own horn or a tool for management to enforce how things should be done.

A diagram illustrating the relationship between blogs, wiki and groups in a workplace knowledge capture system (click to enlarge)

As is hopefully apparent from the description above both blog and wiki have their own set of benefits and drawbacks. Whilst a blog is an excellent means of recording one person's opinion or off the wall process it is not a useful venue for collaboratively putting together a set of 'best practice' documents. Likewise whilst a wiki enables a group of like-minded people to assemble a homogeneous knowledge base it stifles personal opinion in favor of group-think, or even worse allows the resident alpha-male to stamp his (or her) mark on everything that gets recorded. Currently we do not have a Web concept that encompasses the best of both worlds and because of the forces at play I doubt one will ever exist. As a consequence an effective workplace knowledge capture system should attempt to blend both blog and wiki in a manner which positively reinforces both functional requirements.

Enter Drupal, the jack of all trades

Most blog or wiki software packages available today are simply that, a blog OR wiki software package. There are very few that are both and even fewer that do them both well. Drupal is one such software package that is capable of enabling simultaneous and seamless blog and wiki-like functionality in the manner required of a workplace knowledge capture system. Drupal is a mature, open-source, PHP-based content management framework that is used worldwide on thousands of Web and intranet sites. Unlike a more traditional, one size fits all content management or wiki system, Drupal is intended to be extended and modified to suit the exact functionality required. This capability makes it ideal for use as a workplace knowledge capture system because it can be tailored to fit the intended environment and is capable of changing as the workplace evolves.

Blogging in Drupal

Drupal comes standard with a blog module built in which allows all users to have their very own blog that other people can view and comment upon. Creating interesting blog posts is greatly simplified through the use of word-processor editor modules such as TinyMCE with extensions like IMCE. These enable even the most technically challenged people to create rich, structured documents complete with embedded photographs and diagrams.

The TinyMCE rich-text editor within Drupal (click to enlarge)

Wiki-like functionality in Drupal

Drupal does not yet have wiki functionality built in by default. This being said it is possible to create a versioned document type that can be edited by all users with only a few mouse clicks. When combined with the diff module this versioned, fully editable document has the same characteristics of a wiki document without the annoying wiki syntax (which many would say is a good thing). There are wiki syntax modules in development for Drupal but in reality a rich-text HTML editor like TinyMCE is far easier to pick up and use by your average employee when compared to the often cryptic world of wiki-markup.

Taxonomies in Drupal

Having lots of content is a great, but like our mothers always warned too much of a good thing will lead to stomach aches and tooth decay. Just because something has been written down and is in a database does not mean it will be easily found. Drupal allows content to be categorised in many different ways from a highly structured taxonomy through to very fluid, user defined tags. Both types of categorisation have their benefits and drawbacks, but being able to mix and match both systems depending on the type of content enables staff to locate what they are trying to find in any number of ways. For example taxonomies can be browsed or viewed as a cloud, used to assist in search request or, with the aid of modules like 'similar entries' can forge links between disconnected content.

Identity in Drupal

Identity management is another hot topic within the I.T. world at the moment and Drupal is very powerful in this regard. By default Drupal uses an internal user database but it can be configured to pull user information from a central source such as an LDAP server. Functionality such as this enables it to be integrated seamlessly into an office environment where employees generally have existing accounts for file and print services.

Building communities around business topics with Organic Groups

On an active website what generally turns out to be the hardest part of the interaction process is deciding what is or is not interesting to you. The last thing you want to do on a busy work day is comb through all the new bits of information on the workplace knowledge base just to find out nothing touches on your specific interests. The Organic Groups module resolves this problem by allowing users to create groups within the Drupal site which can be subscribed to by associates who have similar interests. As content is posted to this group the subscribed users can be notified by email or RSS feed of the developments rather than having to manually check. A secondary but no less important aspect of the module is that it enables the group to flag what they are discussing as private so that only those subscribed and authorised can view and partake in the conversation. In a large, multi-faceted organisation a capability such as this is important because not all knowledge capturing is a public affair, especially if the information is confidential or sensitive.

There is no such thing as a free lunch, but the food is cheap

Drupal does not have a 'workplace knowledge capturing' module because each workplace is different and for such a tool to be successful it needs to be tuned to its environment. Fortunately Drupal is a fluid platform so deployment can happen very quickly with the intention being that the system will be changed to suit the workplace based on feedback and uptake by the staff. Being open source with a large user base there are very little setup cost s and support from the community or local consultants is easy to come by. If you are considering setting a knowledge capture system up then I would recommend exploring how blogs and wiki can be used in partnership with each other in your workplace and whether Drupal could be the stage where it all takes place.

Note: For a list of useful Drupal modules checkout my Diigo Drupal bookmarks for many of my favourites.

Drupal 5.0 release & video

David — Thu, 18 Jan 2007 22:18:13 +0000

Drupal 5.0, an open source content management system (CMS), was released this week. To help new and existing Drupal users (like myself) understand what is so cool Lullabot has created a very nice Drupal 5.0 new features video. The short video is worth watching even if you have never used Drupal or a CMS before as it illustrates many of the new and cool looking administration features that makes Drupal arguably one of the best CMS choices around. After watching the video it looks like I have some work ahead of me this weekend in order to upgrade this site to the new release.

drupal

Easy OpenID and Drupal

David — Wed, 10 Jan 2007 21:16:32 +0000

OpenID is an easy to setup identification system for both users and developers that is beginning to gain industry momentum. OpenID uses URL's as unique identifiers which is a flexible and memorable way of tackling what your identity is. As it is relatively simple in principle OpenID is not a solution for all identity tasks but in a loosely joined, Web-centric context it is well suited.

All you need to do to use it is sign up for a free OpenID account, or if you are really adventurous implement your own system. When you login to an OpenID-enabled website/service it takes your submitted url and password and passes it on to the OpenID service for authentication. The first time you successfully authenticate you must tell the OpenID service exactly what (if any) information the target website/service should be able to see.

Firewalling what information a third party can see about you is vitally important as it allows you (the owner of your information) to tailor what others can learn from your OpenID account. The upshot of this process is that sites you trust implicitly can learn about your physical address and personal details, whilst a site you hardly know can be left completely in the dark about who you are. This is a far more useful approach than the all or nothing (or simply nothing) strategy employed by older identity systems like LDAP. Because your identity is centered around your OpenID account maintaining your personal information becomes a lot simplier, there is only one password to remember and one set of contact details to manage. Just to help out Drupal has a handy module which allows your website/blog URL to be your OpenID handle which redirects to your chosen OpenID provider (for example myopenid.com).

Overall OpenID is a very promising technology that if it gains critical mass may significantly improve the identity space on the Web. It certainly is not going to dominate the entire space but it gives small-scale developers a great starting point for implementing an easy to use universal identity system.

StressFree website migrated to Drupal

David — Sun, 27 Aug 2006 11:41:49 +0000

Over the weekend I have migrated the StressFree website across to the Drupal content management system. The move was spurred on by the shortcomings I kept finding in Joomla, the desire to be able to tag content and the knowledge that the next upgrade to Joomla 1.5 would require almost starting from scratch.

I have tried my best to maintain all the legacy links so hopefully the old Joomla and static file links should resolve okay. Overall it went really smoothly, Drupal is a little bit more difficult to get your head around compared to Joomla but now that I've made the switch I am very glad. There has been limited loss of functionality in the switch but a tonne of new features are now available:

Firstly I can now tag content and there are tag clouds available. This should make finding content a lot easier though in the future I wouldn't mind finding a 'related tags' type module for Drupal.
Also it looks like Drupal's content search engine actually works (compared to Joomla/Mambo's effort).
On the administration side I now have an xmlrpc interface for writing content which will mean I can finally give Ecto some real use instead of always working through a web browser for publishing content.
The new comment engine looks a lot better than the Joomla version as it supports html comments and replies.
The 'printer friendly' option is far superior than Joomla's. Not only is it tidier but it also has the ability to extract hyperlinks from content and print them below the article as footnotes (which is very cool).

One piece of functionality that Joomla has over Drupal is their {mospagebreak} tag and its ability to auto-generate table of contents for long articles. It does make navigating larger documents a little less user-friendly but it is a small price to pay for the extra functionality gains.

Migration-wise it looks like content has come across okay. Some of the comments are a little messed up due to the significant formatting differences between the two systems. Over the next week I'll go through all the comments and tidy them up so there is no confusion.