Results tagged “drupal”

If you use Drupal and would like to automatically generate thumbnails of web sites, you might want to take a look at the Bluga WebThumbs module. Once that module is installed on Drupal and you have given the module your Bluga WebThumb API key, you can then inject a PHP snippet like this into a node using the PHP filter or into a theme file:

<?php
print bluga_webthumb('http://contentment.org/');
?>

Now, when you view the page containing that snippet, you will see a thumbnail generated using the Bluga WebThumb service within a few seconds that shows that web site. The thumbnail is cached locally on your server.

You can further customize your thumbnail with many options. You can read the full documentation for the module at Drupal’s web site as well. New features since March of last year also include a script for updating the thumbnail in place without requiring a page reload and a nicer looking (and CSS-styled) place holder, which is an improvement over the graphic previously used.

Last week, I was approached by the owner of Konigi.com to do some Drupal work. He’s a user of the Bluga WebThumbs module I wrote in March of last year and wanted to see it work with Drupal 6. I have finished the update and have made a full release of the Drupal 5 version of the module after making a few improvements and then ported the module to Drupal 6.

Cheers.

I am now almost finished with my first week of orientation at my new job with Pittsburgh-based Grant Street Group. I’m going to be doing some software development on one of their product lines and have spent much of the week in training to use the product. I’ve also spent a lot of time reading policy, learning development practices, and digging through the code. I’m hoping that I can start digging in and actually working in the near future. I’ve gotten to meet several members of the staff as well and am very excited to be working here.

Now that I’m no longer looking for work, however, I’m hoping that I can start catching up on my back log of hobby projects that need to get done. This includes some items on the honey-do list (like cleaning the garage which never seems to happen), but I’d really like to get the second half of my latest O’Reilly article published sometime this century. I’ve had at least one person ask where the other half of it is and I really need to get the rest of the text fleshed out and off to the editor (all done, but finishing up the research).

I’m also trying to figure out what other hobby projects are going to be kept and which ones need to be canned now that I’ve switched jobs. I have some loose ends to tie up. One that is likely to be canned is my relationship with Drupal. I think I’m going to have to pass the modules off to other developers (possibly to my former employer) or drop maintenance altogether. I don’t have any need for Drupal at this time with my blog now on Movable Type, no longer working with a company using it, and I’m no longer maintaining the site for New Hope.

I’m still evaluating my relationship with the Jifty project. I really like it, but I’m not sure where it fits in my current work-life balance. I have a couple home toys I’ve written to use it, but nothing serious. I really did like the prospect of helping on the documentation side of things there more, but I’m having trouble really finding time for that. Having a son really sucks time away from being able to do much in the evenings just for kicks and giggles. (That’s not a complaint. I could very easily choose the projects over Gabriel, but who’d want to do that? Gabe is way too much fun to avoid spending time with!)

I guess I’ll see how things shake out over the next few months.

Cheers.

While working at my current job, we've used three different systems to manage our projects. First, we used Trac
, which I liked very much. As we transitioned from project management into user support after the first launch of the new web site and related products we tried to use RT
for project management, which I like very much as well, but turned out to be a poor choice for what we were doing. Finally, over the past few months we've implemented a new system during Drupal
, which has been moderately successful for us. I wanted to discuss the progression briefly and explain how to use Drupal for the task of software project management.

Initially we used Trac. Trac is basically a wiki + issue tracker + code browser + milestone manager. It does those four things extremely well together. You can create wiki pages for documentation very easily. You can easily link between wiki, issues, code revisions, files, etc. You can gather your issues together in dated milestones for releases. You can track all the activity of your developers from a central timeline. All of these were working well for us. The only major drawback is that my knowledge of Python (which Trac is written in) is limited and there are things we wanted to do with it that would have required more customization than Trac is really capable of without patching it. That wasn't a show stopper. I can learn Python and we could have lived without the customizations, but it was a drawback for us.

However, Trac is not a tool that works well for end-user support since it's email integration doesn't work very well and isn't quite as transparent as I'd like. Having used RT for end-user support and loving it for that purpose, we implemented that and transitioned to RT for project tracking as well. At that point, I setup a Drupal site to sit beside the RT site to hold documentation. As far as end-user support goes, RT is the bomb. The keys, as far as I'm concerned, is the ability to logically separate support issues into queues, being able to transparently integrate email, being able to link and merge various tasks together, being able to make private technical comments on a ticket separate from replies that go out to the person with the problem (that's a killer feature), and having lots of flexibility when it comes to building email templates and triggers that send email on comment... oh, and really, really, really flexible access control. I've not seen a system for incident tracking with end-users that even comes close (not that I've seen many such systems). I've also made quite a few customizations to the system to make it more useful for us.

As far as project management goes, the RT-Drupal combo was a failure. It caused a lot of headaches, there was confusion about what was happening, and we really didn't store much of any documentation in Drupal. We should have added RT as an end-user support mechanism and kept Trac in place without modification. Had we done that, I don't think we would have implemented the Drupal system we're using now, however. Basically, I/we decided that trying to use RT to track our software projects wasn't working for us.

I suppose we could have found a way, but we decided instead to give the Drupal Project and Project Issue module a try. This decision was made for several reasons. First, we'd made a strategic decision to use Drupal as the new base platform for our central web service, the Boomer Knowledge Network
. By reusing Drupal for project management, we could more effectively reuse our knowledge and even try a few things out on the support site that could be copied on the BKN. We weren't sure it would succeed and we might have switched back to Trac again if it hadn't.

However, our use of Drupal with the Project and Project Issue modules has worked out better for our purposes at this point than I think Trac would have. The Project module for Drupal provides little to no value on it's own for us except to break up our various software projects into chunks. The Project Issue tracker, on the other hand, has all the power we need. The only major drawback at this point is the inability to assign another user to an issue //drupal.org/node/4354">http://drupal.org/node/4354, perhaps, eventually they will even agree on a fix and apply a patch!
. Other than that, it can track pretty much anything we need it to in a way that fits our team's development style [# Our development style bears some vague resemblance to Agile, but much less formally structured].

The thing that's really helped though is Drupal's CCK module. This is a customization tool that allows you to add custom fields on nodes. The Project module has a system for building releases and such, but it's really strongly geared towards how Drupal's core, theme, and module code is released, which isn't precisely the way we release our work. Rather than using it, we built our own system by building a custom Release node and then associating custom fields to link that node to a project, setting a status (in progress or deployed), a planned delivery date [# usually within 2 weeks], and a list of references to issues that should be completed on release.

We then reconfigured the states that they are defined for issues so that we have a "fixed / ready to deploy" state and a "deployed / completed" state to match with our releases. Those working on a given release can change the state of all the issues to "ready to deploy" as soon as they get everything on that issue complete. Once all of them go light green, I "schedule downtime" [# I.e., I do it late at night when our members are asleep] and perform a code push and do all the configuration necessary to finish the production release [# Usually, this is a 5 minute process, but sometimes as long as 2 or 3 hours]. Then I can mark that issue as resolved.

We also have some documentation in the system, but we're not doing as well here as we probably could. I'm also starting to build some tools using more custom node types with custom CCK fields to handle idea gathering. I'd like team members to be able to visit a site and share that link in a way similar to Digg or Delicious within the office and I'm already a good ways along on that. We're building a review system so that other staff outside the team will be able to comment on screenshots and comps so we can develop a feedback system.

I've also figured out a way to get the timeline back, which was a feature I really liked in Trac. Using the Drupal news aggregator, I can pull the feeds for code commits, issue creation, releases, and even comments [# via the Drupal Comment RSS module]. Unfortunately, I haven't found a way to pull issue followups in a way similar to Comment RSS so those are missing still, but I may just build a Followups RSS module if I have to.

Anyway, I'm pleased with how the project modules are working in Drupal for us. It's a little more flexible than Trac is (IMO) and since I'm very familiar with PHP [# I'm unfortunately familiar with PHP, which is a language I just don't like for both idealistic and emotional reasons.] and with Drupal [# On the other hand, even though Drupal is written in PHP, much of its design both internally and aesthetically is quite nice.], the code customizations are a piece of cake.

Well, that was a lovely ramble. That's what I get for writing so late after working all day....

Cheers.

I've been going through the list of tables on my Drupal site in prep to convert an existing single-site to a multi-site with a shared database. However, I haven't found any reference that illuminates the general purpose of the tables. I've tried to put together at least a preliminary list here. I share it in hopes that someone else might find it useful, but it is not normative or complete.

access

User. This is the table used by the "Access Rules" section for banning usernames, IPs, etc.

accesslog

Statistics. This stores the accesslog if Drupal is collecting statistics.

aggregator_category

Aggregator. Store the categories feeds may belong to.

aggregator_category_feed

Aggregator. Links feeds to categories.

aggregator_category_item

Aggregator. Links feed items to categories.

aggregator_feed

Aggregator. Store the feeds that the Aggregator module pulls from.

aggregator_item

Aggregator. Store the items that the Aggregator module has pulled for the various configured feeds.

authmap

User. This stores a map to the authentication module used to authentication each user in the database.

blocks

Block. This stores information about blocks provided by every module installed, including custom blocks.

blocks_role

Block. Stores the roles permitted to view blocks in the system.

boxes

Block. Administrator created blocks.

cache

System. The general cache of data, used by many modules.

cache_filter

System. I have no idea what this table is used for.

cache_menu

System. I have no idea what this table is used for.

cache_page

System. I have no idea what this table is used for.

cache_views

Views. Used to cache information related to views.

client

Drupal. Used to record Drupal client sites. I believe this is the list of sites that others have logged in from if you use the Drupal module.

client_system

Drupal. I'm not exactly certain what this table is for.

comments

Comment. Stores all comments made on your Drupal site.

contact

Contact. Stores the emails sent via a contact form.

files

Upload. Stores information about files uploaded via the file upload module (and used by some other modules too).

file_revisions

Upload. Associated file revisions with node revisions allowing different node revisions to have different versions of a file associated with them.

filters

Filter. Stores information about the body content filters used in your install.

filter_formats

Filter. Associates filter formats and settings with a body content filter.

flood

Watchdog. Used to detect floods from requests coming from a set.

forum

Forum. Used to link forum posts with the forum topic.

history

Node. Used to track which nodes are read/unread.

locales_meta

Locale. Something to do with language translation.

locales_source

Locale. Something to do with language translation.

locales_target

Locale. Something to do with language translation.

menu

Menu. Storage of menu module customizations.

node

Node. The main table for storing general node information, including the title, node number, dates, workflow state, but it does not store most of the actual content.

node_access

Node. Storage of per-node access permissions.

node_comment_statistics

Comment. Notes certain statistics related to the number of comments and how recently comments have been made on a node.

node_counter

Statistics. Records the view count for each node.

node_revisions

Node. Stores information about node revisions, including the main content of the node.

node_type

Node. Stores information about the custom node types.

permission

User. Stores the permissions that have been assigned to each role.

poll

Poll. Extra information associated with poll nodes.

poll_choices

Poll. Associates the available choices with a poll node.

poll_votes

Poll. Votes by visitors on a poll node.

profile_fields

Profile. Definitions of available profile fields.

profile_values

Profile. Profile field values associated with a particular user.

role

User. Assigns role IDs and names to all the roles in the system.

search_dataset

Search. Something to do with search.

search_index

Search. The search index.

search_total

Search. The number of times a given word appears on the site.

sequences

System. The current counter for each of the sequence IDs.

sessions

User. User session tracking data stored in the database.

system

System. Information about installed modules.

term_access

Taxonomy Access Control. Access control per category.

term_access_defaults

Taxonomy Access Control. Access control per vocabulary.

term_data

Taxonomy. Definition of taxonomy terms.

term_hierarchy

Taxonomy. List of parent terms for each taxonomy term.

term_node

Taxonomy. Table linking taxonomy terms to nodes.

term_relation

Taxonomy. Relationships between taxonomy terms.

term_synonym

Taxonomy. Alternative names for a taxonomy term.

tinymce_role

TinyMCE WYSIWYG Editor. Roles assigned to use TinyMCE profiles.

tinymce_settings

TinyMCE WYSIWYG Editor. Definition of TinyMCE profiles.

url_alias

Path. Path aliases recorded to nodes.

users

User. User records.

users_roles

User. Link table between users and roles.

variable

System. Administrative settings and other site-wide variables.

view_argument

Views. Definition of arguments to a view.

view_exposed_filter

Views. Definition of exposed filters in a view.

view_filter

Views. Definition of filters in a view.

view_sort

Views. Definition of sorting in a view.

view_tablefield

Views. Something to do with the views plugin.

view_view

Views. Basic information about a view.

vocabulary

Taxonomy. Definition of taxonomy vocabularies.

vocabulary_node_types

Taxonomy. Associates vocabularies with node types.

watchdog

Watchdog. Records watchdog log entries.

Drupal
is by far my favorite CMS, despite the PHP (or poohp as I tend to pronounce it). One of the places Drupal is strong is organization, as long as you want to organize everything in a web. It does provide hierarchies and has breadcrumbs, but these are where Drupal begins to show weakness. In this articles, I'm going to explore how Drupal organizes itself and how you can take advantage of that organization out of the box, or with some module help, or by custom hacking. It's a summary of the research I've been doing on the topic.

Organization

Organization of content in Drupal, as shipped, primarily operates in these ways:

• Follow that term. You click on a post in a list and see a list of categories (formally "terms" in Drupalese) associated with the post. You click on one of those and you can see all the other posts on the site that are like that one.
• Order from the menu. You can assign a page to one or more menus, which are just hierarchical lists of links. If a menu item on the screen matches what you're looking for, clicking on it will take you to the node, term page, a list, or whatever the link points to.
• By the book. Pages can be arranged in ordered hierarchies, like books. If you look at a page in one of these organizations, you can click on the sub-pages or go to the previous page or the next page or up to the next level from any page here.
• Follow that forum. Forums are really glorified category terms.

That's it. Those are all the organization options you have built-in.

Caveat Emptor

However, there are some inherent gotchas that newbies aren't always aware of. The first is that the breadcrumb is pretty weak in Drupal without some help. This usually reveals itself in a scenario like this (this is approximately how I ran into it). A newby downloads and installs Drupal, logs in as administrator, and goes to create his first vocabulary (a custom system of categories). He creates a hierarchy and adds a bunch of terms. He finishes and adds a test node that has one of the category terms set that has two or three parents. Let's say, "Food > Fruit > Citrus > Orange". However, rather than seeing a breadcrumb on the node view that reads "Home > Food > Fruit > Citrus > Orange", he just sees "Home". If he's like me, he's confused but just assumes he did something wrong. He tries clicking on the "Orange" term to see the breadcrumb there. The breadcrumb turns out to be exactly as expected, "Home > Food > Fruit > Citrus". That means if someone gets that term and clicks on the test node, the breadcrumb that should, intuitively, expand one level deeper completely evaporates.

The problem is that this is a misunderstanding of the purpose of the taxonomy system. The taxonomy system does not provide any structure for the nodes. It provides some structure for itself, but the nodes themselves still belong at the top. It's a completely flat structure. Structure is provided to nodes in Drupal core in one of two ways: the Book module and the Menu module. Which way is appropriate for your site will depend on your needs. Also, neither of these may be satisfactory, but we'll get to that in a bit.

Book Solution

The first mechanism provided by Drupal is the book module. This module allows any node to have a parent. To use the book module, you must first enable the module, configure the permissions, and then create a Book page. The first Book page will be at the "Top Level" meaning it starts a new "book". You can then create additional nodes that are in the tree. The top must always be a Book page node type, but the rest can be any node type you like, but you have to go through the extra step of configuring the node via the Outline tab after your create it. Update April 21 @ 7:28pm: I just realized this is an error. I forgot about the Outline tab. You can make any page the root of a book via the Outline tab. (Book pages automatically have the "Parent" option configured on their create form.)

If you look a the breadcrumbs of Book pages, they operate exactly as expected. Each breadcrumb is created by traversing the list of parents until it gets to the top level and then adds "Home" in front of everything. The book module can also provide a hierarchical list of pages that looks like a typical Drupal menu as well via the Book block that comes with the Book module.

This is, by far, the most common sense method for hierarchically organizing your site's content. However, if you need special content other than the book pages you have an extra step to make it work. If you need to organize non-node content (special forms or something) the Book module may not be any help at all. Also, a single node can't belong to multiple books. A node may only have 0 or 1 parents in a simple hierarchy.

Menu Solution

An even more flexible solution is through the Menu module. The Menu module allows you to create Menus, which are hierarchical lists of links (it allows you to manipulate the built-in menu items as well, but that's another topic). These links may be to nodes, terms, or anything else on the local site that has a URL. They may also be absolute links to get to locations on other web sites. Each menu item has exactly one parent, but since you're only creating links, you could have a single node or other item linked in as many different menus as you need.

Furthermore, creating a hierarchical menu also tweaks the breadcrumb. If you have a node that would otherwise appear at the top level (i.e., it doesn't belong to a book), the first menu it is listed in will be used to create a breadcrumb for that node. Therefore, if you had a taxonomy structure with a matching menu, you could fix the problem of having your node appear without a breadcrumb.

Unfortunately, this too comes at a certain cost. You must maintain the menu structure manually. You have to add each node as it goes. If you have a taxonomy structure to mimic, you have to do double duty on your data entry and then make sure your menus point to each new node you create.

Setting up the menu while creating a node is pretty easy for an administrator. Anyone with permission to administer the menus can setup the menu for a new node via the "Menu settings" box on the create page. However, if you want authors to be able to do this without being able to tweak the entire menu structure, you're out of luck. You either grant someone the right to manipulate everything or nothing, which isn't acceptable in many situations with more than a few authors.

You can address this issue by looking into the Menu Subtree Permissions
module. This allows you to grant edit access on parts of menus to certain roles.

Add-ons

There are many, many add-on solutions for handling this. I'm going to give my favorite choices and then list the others I've found. This is not a complete list, but it does highlight the modules I've examined a bit in my search for a solution.

Taxonomy Menu

A solution that uses the combined power of taxonomy and menu is available in the Taxonomy Menu
module. This module creates a menu item for each taxonomy term in the system. This automatically gives you both downward navigation through menu items and upward navigation through breadcrumbs. This isn't quite as good as the navigation provided by the book module, but with intelligent use of the sticky flag or manual items, you can come relatively close.

Add on Custom Breadcrumb

Another way of handling the breadcrumb is via the Custom Breadcrumb
module. This module allows you to associate a breadcrumb with a node based upon it's node type. For example, if you have event nodes that always needed to appear in "Home > News > Calendar > Events," then you can use the Custom Breadcrumb module to do this. If you need a more variable structure than this, then Custom Breadcrumb still doesn't do it.

Others

Here are some other add-on modules that you may wish to consider:

• Taxonomy Bradcrumb
  . This module provides half the abilities of the Taxonomy Menu in tweaking the breadcrumb. It does not, however, provide any way to navigate down to the items in the tree, just the parents on the way back up.
• Category
  . For the daring, there's also the Category
  module which provides a complete replacement system for the core Taxonomy module, Book module, and provides a special menu module for creating menu items automatically on the creation of nodes. However, this is a big module with lots of options and I've back off from using it because it's almost too powerful to figure out how to use it most effectively. I've had some trouble getting it to work really well.
• Pathauto
  . This module doesn't actually help you organize your site, but it can makes your URLs match your breadcrumb organization structure. I highly recommend this module to make your URLs pretty. However, be aware that the URL aliases can quickly clutter the URL Alias page if you have a lot of pages.

• Theme Hacks

  If you do a search on the Drupal site for "breadcrumb" you will come across several hacks to the theme. All of which are customizations that make use of drupal_set_breadcrumb()
. You pass that function an array of links and it will give that array of links to the page template. This is the ultimate solution if no other will work for you.

  However, again, this still only gives you the upward navigation. It doesn't provide any kind of downward navigational structure.

  Conclusion

  Drupal does provide ways for organizing your content, but some of the out-of-the-box methods may not be ideally suited for your situation. Drupal comes out of the box with excellent support for web-like and river-of-news style organization. Hierarchies are quite possible and can be managed, but the structures provided for such assume a relatively light amount of hierarchical information. However, by using a few modules and the taxonomy structure, you can create very flexible and functional hierarchies to suit any site structure.

We made a major decision this week that I'm, personally, very happy about. The Boomer
web site is moving completely to Drupal
. Currently, our site uses a CMS called Magnolia
, which is an excellent product, but the needs of our web site are drifting out of sync with the features provided. Magnolia provides good content management, workflow, and document management, but our site is growing in the direction of community building rather than publications. We're already using parts of Drupal for part of the Boomer Extranet service for our top-tier clients
. We've got another offering coming soon that will make Drupal an excellent fit for us and it just doesn't make sense to maintain two platforms anymore.

Since we're still developing business plans and this product is not officially announced, that's about all I can say for now about the community part of the web site. However, I would like to discuss some of the issues I'm going to be dealing with in moving away from Magnolia to Drupal. Most of this involves handling the publication aspects we do deal with in Magnolia that need special consideration when moving to Drupal.

For example, we have a reference library of articles related to topics specific to the accounting profession. We provide these articles to our premium site members, but provide only stubs to the articles to the public. Therefore, I need a way to store these articles, categorize them, and associate downloadable documents with them. I also need a way to secure access so that only the teaser and tags are available for marketing purposes while the rest are avaialble only to the premium subscribers.

Since this is a big issue to cope with and one that Drupal doesn't directly deal with (though I considered a possible solution in an earlier post
), I've created a Drupal Group
to deal with the topic of document management
. I hope to find others interested in the topic to create better solutions in Drupal for this problem. Anyway, if you're interested, please join
the discussion.

Cheers.

The last update I had for the church web site
was in August
. I'm now proud to announce that the new design that Jay Risner put together for us is now online. I want to use this blog to briefly talk about the design, but mostly to map out where I hope to take the site next.

Design and Administration

The design mostly speaks for itself, though there's one hidden piece which is kind of handy. One of the difficult things about Drupal from a design standpoint is the fact that the CMS backend isn't in a backend. That is, with many other CMSes out there, such as WordPress, Joomla, and Magnolia you work in a separate interface to do the work of creating new stories and articles. The web designer doesn't have to cope with these at all because no casual visitor will ever see them. With Drupal, however, the admin interface is integrated with the front-end of the web site. Drupal merely adds another set of administrative menus and screens into the front-end. Thus, you have a long set of menus that your design has to cope with.

In the case of the new New Hope Church design, you can't just let this menu go into the sidebar because the sidebar was designed to be simple. The solute we came up with was to create an extra sidebar that sits in the brown background to the left side. I got the idea for this from the Trac
web site which places a menu on the left side of the main column and ads on the right. Since Jay's original design was so well-structured, it was really just a matter of creating an extra float to sit off to the left to work it in.

Looking Ahead

Looking ahead to what I would like to do with the site next I see a number of different sub-projects that need to be handled. The most obvious is a few incremental improvements to the new design. I cobbled together the current front-page and I don't really care for it. I need to get all the pieces of the front-page looking and fitting together better. I would like to move the login to a bar just under the banner. I would like to get all the columns laid out and pretty. I would like the directions to include a map. I would like the Flash banner to look better when Flash isn't available. Etc.

Speaking of maps, I would like to incorporate more maps into the site. There are a number of nifty things we can do with maps if we just take the time to implement them. For example, our church considers the central gathering to be only a small part of what we do. We could make that much more obvious if we added a map of the LIFE groups and other smaller meetings that take place throughout the week. Being in a college town, we send out quite a few members and it would be nifty to see a map of where our "alumni" have gone.

I would like to make it a community organization tool. I would like to see members come to the web site to find out when and where things are happening. It would be nifty if there was a way for groups to record recent happenings for their members to read about. It could even include things like a current list of prayer requests and other information. This would allow alumni and those who missed something to keep up with their groups similar to the way I keep up with friends I don't hear from often via Facebook
. It could help facilitate discussions such as helping to arrange who's going to bring meals to a family or who's bringing which dish to a supper meeting. This could help avoid the mess of email lists each group maintains themselves.

A frequent request is for a member directory to be placed online. This could be done if access to the directory was regulated appropriately. It would be great to be able to have this information online for people to change as soon as the move or to let former members keep their information available for anyone who wishes to stay in touch.

And finally, back to the mundane, the site is really disorganized right now. I need to establish some order for the site if any of this is to work in a way that will be useful. Since I'm hoping to allow the structure to be somewhat organic, the structure must be somewhat fluid so that it can grow and flex to fit differing needs. On the other hand, certain pieces of information need to be highly structured (such as information about leadership, beliefs, and other fact sheets) and I need to provide for this as well.

Anyway, there's a lot to do on the site. I just hope that I have time (or help!) to get it done with a baby due any day now.

Cheers.

I blog on a wide range of topics. Because of this, my blog one day might focus on Bible study and the next on a trip I took and the next on some site improvement I'm making on one of the web sites I maintain or help maintain. I'm guessing that some visiting my site probably get whiplash and probably have a hard time knowing what to pay attention to.

Solution: Crossite module. I've written a module I've dubbed "Crossite" which uses the multi-site features of Drupal to share nodes between them.

This solution provides a kind of ultra-cheap aggregation of information on the various sub-sites. All the sites share the users, nodes, taxonomy information, but have their own themes, settings, and cache. The main feature provided by this plugin does two things. First, a node is categorized as "belonging" to a given site based upon the taxonomy terms it has been filed under. If a node has no matching taxonomy terms, it is treated as if it belongs to the default site.

The second half of this functionality is a redirect that is performed when viewing nodes that belong to a different site. If you click on a link that leads to a node page for a site that belongs to another and does not belong to this site, you will be redirect to the node's page on that other site. A node might belong to multiple sites or all sites simultaneously if it has the correct terms attached to it. In fact, one term might even link a node to multiple sites.

A secondary feature is that it adds a new property to node objects, named "sites". This returns an array of sites to which the node belongs. This can then be used to determine how to theme pages or do other custom tid-bits.

I'd like to make a "Crossite_view" module to distribute with the parent module to further facilitate this by allowing sites to have specialized list views. The configuration of the system is a kludge and needs to be incorporated into the UI to make installation easier/possible. Right now, you have to modify the "settings.php" file for all the sites. Anyway, I'm waiting for my CVS account on Drupal.org before publishing the module.

In application, I've expanded my web site now to include two domains I've owned for awhile but had been hoping to use for other purposes. I don't think those other things are going to happen just now, but I wanted to use them in the meantime.

This site, Andrew.Sterling.Hanenkamp.com will focus on the "life" stories about things happening with me and my family, my general opinions, etc. I will also use this site as the primary aggregation site for all the other articles. The main list will feature those articles as other headlines between the "Life" articles. I will probably provide a master feed of all my web contributions as well. I'd like to have something like the Newsvine seed where I can pull in articles, comments, and other bits I post on other sites as well---such as links to my Boomer Bulletin articles.

I will feature technical stories about computing, Perl, Java, programming, web, software, Apple, Linux, etc. on Contentment. That site formerly hosted my CMS efforts, which are now defunct. I had, briefly, also planned on using it as a place to discuss church site development or provide project management tools to teams building church web sites. However, one is already being handled by the Churches group on Drupal Groups. The other proved to be too ambitious for me to do in the time I could spare between everything else I do when not at work.

My Bible studies will be featured on Open Scripture. This site reflects my desire to know my Bible and "Open Scripture" describes a kind of mini-motto that describes my take on the Christian life. I purchased this domain in the hopes of helping create some kind of Bible study/collaboration tools. Again this has proven to be too ambitious and probably premature. In the meantime, I will use it to share my personal Bible study.

My web site continues to evolve, bit by bit. It's kind of a fun little project to dink with every few weeks and is enough to keep me entertained at home.

Cheers.

I previously published an article here about using Drupal and RT together to create a knowledge base system. I've continued to improve the system and wanted to give an update on how it's working.

Of the pieces I mentioned in my previous article, I have implemented Organic Groups in the system. I have not (yet) implemented any of the other ideas I had at the time. In addition, I have used the Front-Page module, added use of the Content Construction Kit (CCK), and started adding some tweaks to RT.

Organic Groups

I have added Organic Groups to the site to operate the same kind of functionality as is provided by a SharePoint sub-site or a Trac project. Each Organic Group is a smaller segment of the whole knowledge base dedicated to a specific project or knowledge area. Organic Groups allows each user of the site to be a member of just the groups that are of use to him. It keeps membership lists for each group and also provides (some) notification regarding new content (it would be nice if content updates could be included as well, but does not at this time). Content may also be associated with no group or can be associated with a group while also being public as well.

All in all, this has been very helpful to segmenting the site.

Front-Page

I've used the front page module to setup a simple comment that goes to all anonymous users. The knowledge base is available from the Internet, but is only intended for internal use at this time. However, it is possible that someone might stumble upon it (most reading this could probably guess it's location in less than three tries and probably a majority only in one...). I wanted a special page facing out for anonymous visitors so that it would tell them to bugger off (though, in much nicer terms than that). It would also help our staff find the pages they are looking for more easily.

The front page module allows me to setup a front-page that's special to any anonymous visitor as well as having a page that's special to those who have already logged in. After you login to the site, the new front-page is a basic table of contents and list of policy documents that affect all of the group sites.

Content Construction Kit

The CCK is the future of all content on Drupal sites, as far as I can tell. Soon, the "story" and "page" and "blog" content types will just be custom content types created by the CCK. This is a good move. Custom content types has been a weakness of Drupal for sometime and flexinode wasn't quite there—in fact, it was one of those demo-turned-indispensible modules that every programmer dreads creating or maintaining.

In this case, I've used a combination of the CCK, the Category module, and the Event module to create a special content type, the "sub-project". These are a combination of "component" and "milestone," which seems to fit our web development project. Some of the features on the site can be grouped into convenient sets that all can be accomplished together. Each of these tasks are related and often feed each other, but aren't really the same task, thus are handled in separate tickets. This has been very helpful.

Each sub-project has a title, a description, and a due date (the need for the event module). These are plottable on a calendar via the event module. These are also "categories" via the Category module, i.e., nodes that act like taxonomy terms. This allows knowledge base content to be classified into these special categories. This is very cool. I have also pulled these into RT, which I will cover in the next section.

In addition to the above, I plan on creating some other custom content types for various bits. For example, I would like to build a "computer" content type to describe individual machines on our network and a "software package" content type to describe computers. These can then be used in the IT group to associated particular articles with particular computers and software packages. Thus, the CCK content types begin to take up the role provided by custom lists in SharePoint. These can also figure into the RT modifications I'm about to describe.

Auto-Complete in RT

I need to formalize this a bit better, but I have added customizations to the custom field rendering component in RT so that I can make custom fields autocomplete in the same way as they do in Drupal. I have added a "Sub-project" custom field to the Web Development queue. Then, I tweaked the component so that those custom field editors pull the available values from the available milestones in Drupal. This is the first real communication I've added from one system to the other and, so far, to work it requires you to be fully logged in to both systems (no single sign-on yet).

I'm still pretty happy about this and it certainly beats the pants of Microsoft SharePoint. I hope to have further updates as well. Currently, I'm thinking of more CCK types (as mentioned), pulling tickets into Drupal from RT so that categories list the tickets that belong to them (possibly using RT's RSS features and the Aggregator module or Aggregator2 module or some other variant), and getting single sign-on working so that we don't have to login twice anymore.

I'm also still considering some of the things I mentioned previously, though they aren't quite as high on my radar right now.

Cheers.

Well, I've been casting about for a topic to blog about on this day off and I've finally got one that I can get traction with, I think. If you're reading this, then I must have published it. :)

I've been doing a lot of work building Drupal sites of late and I've decided that I really like Drupal for a number of reasons, but I really despise it for others. This is a common theme on my blog: I like things, but there are a lot of things I don't like about the things I like. Well, I'm going to list of my top five Loves and Hates for Drupal 4.7.

Hates

So that I may end on a postive note, I'm going to cover the hates first.

1. The documentation is out of date. This can be said for a large number of development projects, particularly those that are run by a community without the influence of much corporate backing. Drupal isn't used widely by corporations as much as it is used widely by non-profits, special interests, and other associations. That's not bad, it just means that there aren't a lot of QA folks demanding proper documentation.

   I do want to make some clarifications:
   

   
   
   • This issue doesn't extend to the API documentation, which is quite possibly the best documented API of any system I've ever used.
   
   
   • This is partially a symptom of the fact that there is so much documentation and that development progresses so quickly. It's easy for a document to become outdated quickly and not enough eyes to go back and fix it quickly
   
   

   Finally, I'd like to suggest that Drupal might be able to help with this problem if they allowed more freedom with editting the documentation content. I believe this is part of the reason the Drupal community would like to see an integrated wiki module. It could certainly help.

2. it is hard to determine what capabilities are available and which modules work well. Without a PhD in Drupalology, it's hard to know what functionality is available through modules. Furthermore, since there's no evaluation system for modules, it's hard to know which implementations work well. People should be able to state whether they like it or they hate it. It isn't easy to know which module is a hack and which module is a mature product. It isn't easy to tell who is contributing to or leading the development of which projects. It's hard to tell how active an individual project is.
   • Each project must have a single sentence description that is shorter than the teaser provided on the main projects pages. This would help folks find them.
   • Project owners should be able to annotate their project with notes showing the development state: pre-alpha, alpha, beta, released, and mature.
   • There should be a list of all active project participants with a clear delineation of who is in charge of a project and a better indication of orphaned projects.
   • There should be a clear show of updates to the project. When was the last commit? When was the last release posted (shown on the project page, but not part of the summary list)? Frequency statistics would help.
3. Drupal suffers from non-developerism. This has gotten better, but one reason why I usually hesitate to use PHP is because the language is so easy to use. Drupal has done a wonderful job of extending PHP into a very easy to use and easy to understand framework.

   This is fine, but making a programming framework easy to understand has a price: those who aren't programmers will start to patch it and work on it. These folks may be ignorant of the full ramifications a particular action might have. This doesn't make them bad people, it just means their expertise lies somewhere else. It's no worse than me relying on a mechanic to fix my truck while attempting to do some simple things myself. I could cost myself a lot of money if I started messing around with the wrong pieces. I probably wouldn't know I was breaking things while I did it.

   In the case of programming, the cost is the potential for code that is difficult to extend, vulnerable to security issues, and inefficient. A non-programmer may not realize that using nested loops might be a worse idea than serial loops in a particular case. A non-programmer may not realize that using a certain function makes it possible for a malicious user to inject code into the system. A non-programmer may never have heard advanced data-structures to help him choose a better solution through a problem.

   In the case of Drupal modules, I've found several look gorgeous inside when you crack them open. Others look like someone implemented the functionality by copying bits and pieces from elsewhere and then just made it work by brute force. Others look utterly horrible. This is the case with any OSS projects, but I've found the range in quality in PHP projects to be a bit wider than say Perl or Java projects. They're simply not as accessible.

   This is why the previous point is important. It should be easy to determine whether members of the community like or dislike something and why they have those opinions.

4. Taxonomy is underused. Taxonomy is, in my opinion, the coolest feature of Drupal. Using taxonomy, you can carefully control the tags associated with any document in the system. You can set up free tagging (a.k.a. folksonomy) where any keyword or collection of keywords can be associated with a document. You can set up specific hierarchies so that a document must be placed into the tree at some point. You can create relationships between different branches of the tree. You can create synonyms. You can mix an match these in just about any way you can think of.

   And yet, taxonomy hasn't been used to facilitate a number of extensions that could have. The best example of extending the taxonomy is the built in forum system. Determining which post a forum topic belongs to is a matter of checking which taxonomy term it belongs to under the forum vocabulary. Forums can be arranged into hierarchies themselves, which are also controlled by the taxonomy. This is very flexible.

   However, many other modules have chosen not to use the taxonomy. The clearest example of this is the Organic Groups module. This, in my mind, is a clear and obvious case for using taxonomy. Each group is a term in a taxonomy vocabulary. If a site wants nested groups, they can do so by making the vocabulary hierarchical. If they want related groups, they add those relationships in the taxonomy. If they want groups that have multiple parents, they can do that. If they want a plan flat system, they can do that. Other examples include the Book module, the Workflow module, the Voting API, and the CCK.

   The taxonomy system is beautiful and it should be used more. I can only think of two reasons why it isn't:

   1. The taxonomy system isn't easy to comprehend and requires some planning to take advantage of properly. Since it isn't easy, that could be an obstacle, though it shouldn't be.
   2. The taxonomy system is pretty weak. As it comes, it doesn't have anything but the ability to create structure and attach documents into that structure. Which leads me to my next and final hate...
5. The taxonomy system is underdeveloped. This system should have been massively enhanced long ago. There is an excellent improvement to the taxonomy system in the Category module. This enhancement replaces the Taxonomy and Book modules with a new system that elevates every vocabulary and every term to first class citizens: nodes. The Category module allows for much greater flexibility and allows you to treat any term as a node, which has the added benefit that it can now be assigned full-text values.

   In addition, I think there should be an enhancement to the Taxonomy (or Category) to allow for values to be associated with a term. This would allow for an even more flexible way of implementing the features of CCK or the Voting API. In fact, with a combo like this, you wouldn't really need much of anything other than Taxonomy, Node, and Forum. This is probably a little radical, but I really like the idea.

Loves

Okay, now that I've exposed why I don't like it, let's consider why I still use it anyway.

1. It's under active development. This is the most important selling point for any piece of software I use. If there hasn't been a change to the code within the last year, I will look for something else. If there hasn't been a change within the last month, I start to worry. Open source projects should continue to update on a very regular basis.

   Drupal is one of those projects that if you forget about it and come back in a year, you have to take some extra time reading about it to catch up. It's not just that those two or three key things you really wanted got put in since you last looked, but that a dozen new features were added and a couple of them are really cool and you hadn't realized how cool until you realize how they work. That's what Drupal has been like for me over the last year.

   I don't necessarily agree with some of the direction they've chosen, but when do I ever agree with all the decisions other developers make? I, of course, know better than they, but I must be patient since not everyone can be as brilliant as me. :P

2. It's got an active community. There are very few posts to the online forums that go unanswered unless the question is completely out in left field or already answered if they'd use the subject line to search instead of creating a new post (of course, I see a lot of those answered with somebody saying "Already answered, look at these links"). Sometimes the answers demonstrate a completely lack of knowledge, but there is an enthusiastic community.

   In the case of Drupal (by my perception, someone else's might be different), there's not a lot of criticism when someone writes a dumb answer to a question or asks a dumb question. In a way this encourages stupid questions and answers, but it also means that the community is willing to help newbs. This is refreshing, since many OSS communities eat their young (another one I participate, in particular, summarily executes the newbies on a regular basis).

3. Easy to understand/extend/install. You can know just enough to purchase a hosting service and then drop the files into place and you're practically running. If you use CivicSpace, the deployment doesn't even require messing around with any SQL scripts, if I recall correctly.

   After installation, turning modules on and off is very easy. Adding new modules might be a bit of a chore, but once you get the files unpacked and FTP'd to the correct place, that's generally pretty easy too. Configuring modules is also very easy once you find where the options are held (harder than modifying the actual configuration).

   To extend Drupal, you just design a new module or tweak an existing one. This is generally very easy as well. This has the caveats I mentioned above as being a little too easy. However, overall, it's really a cinch to do most things.

4. There are lots of documentation and examples. I mentioned that the documentation is a bit out of date in a lot more places than it should. On the other hand, there's just so much documentation. There are examples showing how to do many common tasks. There's documentation covering several theme customizations, starting custom modules, tweaking various things, etc.
5. The system is extremely flexible. Want to do something with Drupal? There's probably a configuration option, a module, or a module setting that does that. If it's something unusual, you can probably arrange it by combining two or three add-on modules in various ways. If it's way out there, you could surely do it with a little bit of custom development because the module system is fantastically easy to put to use.

All in all, I like Drupal. It's not my favorite CMS system ever, but it's my favorite that is under active development. Now, if only it were written in Perl....

Cheers.

One place where Drupal is week is document management. However, after doing a little digging, I've decided that Drupal is actually not so bad as it might seem at first.

What is a document management system (DMS)? Basically, it's a repository that allows you to upload and organize documents. It should include the ability to store document revisions so that older revisions can be reviewed and restored. It needs a workflow system so that various authors and individuals can collaborate. It needs an orderly way of organizing and fetching documents. It needs a permissions system for managing who has access to the documents. It needs to be able to store metadata about documents (log entries, categories, authors, bibliography, price structures, or anything else that might be useful as a sticky note on the document).

Drupal does several of these out of the box. There's a module for everything else. However, there are still a number of minor shortfalls that keep it from being very robust as a DMS. All of these could be addressed pretty easily. Anyway, this is my summary of what needs to happen to make Drupal act as a capable DMS.

So, as is, this is how I would set it up:

1. Install Drupal.
2. Install the Pathauto module.
3. Install the Category module and turn on the menu and pathauto extensions.
4. Install the CCK module.
5. Turn on the built-in upload module.
6. Create a new CCK content type named "document". Include any metadata fields you need.
7. Configure the "document" content type allow file uploads and make sure that "Create a revision" is the default action. You probably want to uncheck "Promted to front page"
8. Create a new container (i.e., the category module's replacement for vocabulary) named "documents". This should be hierarchical with single parents (at least to start). Select the "document" content type to require a setting in this hierarchy.
9. Configure the Pathauto module so that document nodes are located at "Workflow plugin. I have not yet taken the opportunity to evaluate that module, so I don't know how it works or how well. Personally, I'd like to see a system like Relationship module---again, I have not evaluated this module and I'm not certain how well it works.

   There are a few weaknesses here.

   1. No Browser. There isn't a nice document browser. The category menu will work, but it's a bit of a kludge. It would be nice to have a configurable view that could show the hierarchy, show some metadata, etc. Preferably something with a nice AJAX interface.
   2. File Storage. This "DMS" will store document revisions just fine, but all of the documents will be stored in a single directory. This is probably fine until you start storying a few thousand entries. Unless your file system scales well in such a case (very few do), your storage is going to start slowing down. This isn't acceptable since a DMS should be able to store as many documents as you have disk space for without blinking.
   3. No search. What's a DMS without a decent search of the documents themselves? A likely solution to this would be to integrate a 3rd party search tool, like Nutch. There is, actually, a Nutch module for Drupal, so this might be another easy fix.
   4. No file typing. The system only vaguely understands different file types. It would be helpful if it really understood the difference between PDF and Word and OpenOffice documents and could perform specialized operations on each. Even just being able to identify them on a rudimentary level would be a start.
   
   

   Anyway, this is a pretty interesting problem. I find it very interesting that the various Drupal modules cooperate well enough together that this kind of enhancement is practically available as long as you glue everything together just so. I'm intrigued by the possibility of finding and using additional modules or improving or adding a new module to help fix the deficiencies I've noted here. I have a couple projects where it would be nice.

   Cheers.

   Update April 4, 2007: Please see visit the document management
   group on Drupal Groups to discuss this further.

Phew! This is getting nuts. I am more busy on web development at home than I am at work. Frankly, with this flurry of stuff going on at home, I'm starting to get a bit bored with work. Well, I do want to talk about something I did at work yesterday because it was pretty cool. I've put together a knowledge base and issue tracking system using Drupal and RT. It was pretty easy and I think others might benefit from at least some aspect of the solution.

We've been using Trac to keep track of our knowledge base, issues, milestones, and source browser surrounding the web development project. For the internal IT stuff, we've been using Microsoft SharePoint. Both have had limited success. Trac worked perfect until we needed a way for web site visitors to send in support requests via email. Trac's support for this is total crud. It's still being worked upon, but after having used RT in CIS, I'm pretty hard to please when it comes to support tracker email integration. Sharepoint has worked about as well as it ever does: good enough, but it's a bit tiresome to use. If we were using the beta of the new version, it would probably be fine, but that's not trivial upgrade to perform without causing massive alterations to lots of other services we run.

Okay, so I've started to put together something that could potentially replace both of these with flying colors. It's still a work in progress, but I think I've already got something better after only a couple days of working on the problem.

First, I installed RT 3.4. After installing it and getting Sendmail configured on our hosted server, I got RT configured. I leave learning how to do this as punishment for the reader.

Then, I went in and installed Drupal 4.7 and started configuring it. First thing to do is to install all the modules. I've installed the following:

• Category. This is one of my new favorites. It is a drop in replacement for the Taxonomy module that makes every vocabulary and every term into a node. You can even use arbitrary content types as vocabularies and terms and can have vocabularies within vocabularies. It's very nice. Oh, and you can set the default item depth of a category so that it automatically aggregates children to a certain depth. Also very nice.
• Interwiki. This is kind of the best available for the functionality I'm looking for, but it needs a bit of work to get it right. Basically, you can register prefixes with it that will then be translated into URLs using a wiki-like syntax. For example, it comes configured with the prefix "w" automatically linking to Wikipedia articles. Thus, you can insert Nichols Hall and it would link off to Nichols Hall at Wikipedia. You can add other prefixes to other sites or use no prefix, i.e., foo or //drupal.org/project/pathauto">Pathauto. This ought to be a standard Drupal module. It generates paths for a node according to settings you set. I use it heavily on this site now and it's what allows us to have nice wiki-like articles on the new knowledge base.
• TinyMCE. This is a must have if you have non-technical or semi-technical staff helping you write articles. We have a content editor, Doug who understands but doesn't really converse in HTML on a regular basis. There's no need to make him when TinyMCE exists and is so easy to install and use.

That's it. I installed all of those and then went through the tedious process of setting up access controls, updating settings, etc. Now, I can create a page on the site titled "You are a foo foo" and then create another article and link to it by adding the text [:You are a foo foo
. I can use TinyMCE to format the text without worrying about learning the Wiki-syntax-flavor-of-the-month and so I won't be too afraid to show someone completely non-technical how to enter knowledge base information later on.

I added new custom interwiki prefixes for getting at RT and Trac tickets and the old Trac knowledge base articles as well for the transition period. Now, I can link to our old standards document via BoomerStandards
or to a ticket in the old system via 435
or to a ticket in the new system via 219
. I added a number of other shortcuts as well and this is really the only wiki-syntax anyone needs to know about and this is a pretty easy one to remember.

The knowledge base is now in place. Let's go back to RT. To RT, I've now added a callback to the system for the ShowMessageStanza ticket element in the RT system. That is, I created a file named "Callbacks/boomer/Ticket/Elements/ShowMessageStanza/Default" in the local hacks directory for RT. You may wish to see CustomizingWithCallbacks for more information on creating customizations using the RT callback system. Anyway, the contents of this callback is as follows:

<%perl>
$$content =~ s{(?<!&)\#(\d+)}
{<a href="${RT::WebURL}Ticket/Display.html?id=$1">#$1</a>}gx;

my %config = (

        tracwiki => 'http://trac.example.com/trac/foo/wiki/$1',

        trac => 'http://trac.example.com/trac/foo/ticket/$1',

        rt => $RT::WebURL.'Ticket/Display.html?id=$1',

        http => 'http:$1',

        https => 'https:$1',

        '' => 'http://supportkb.example.com/$1',

);

$$content =~

        s{

                (!|\\)?         # stop now if there's a ! in front

                (

                \\

\|]*):    # match a prefix like abc:, remember the prefix

                (([^\

]+))? # match a pretty name like "Blah Blah is cool."

                \]              # match closing ]

                )

        }{

                my ($escape, $match, $prefix, $link, $title)

                        = ($1, $2, $3, $4, $5);

                if (defined $escape) {

                        qq($match);

                }

                elsif (defined $config{$prefix}) {

                        my $url = $config{$prefix};

                        my $term1 = $link;

                        $term1 =~ s/\ /_/gx;

                        my $term2 = $link;

                        $term2 =~ s/\ /\+/gx;

                        my $term3 = $link;

                        $term3 =~ s/\ /%20/gx;

                        my $term4 = $link;

                        $term4 =~ s/\ /-/gx;

                        $url =~ s/\$1/$term1/gx;

                        $url =~ s/\$2/$term2/gx;

                        $url =~ s/\$3/$term3/gx;

                        $url =~ s/\$4/$term4/gx;

                        $title = defined $title     ? $title

                               : $link =~ /^                      "$prefix:$link";


                        qq(<a href="$url">$title</a>);

                }

                else {

                        qq($match);

                }

        }gex;



</%perl>

<%args>

$content

</%args>

If you're unfamiliar with Perl and Mason, you may have a migraine by now. You might have one anyway, unless you're a JAPH like me.

Anyway, this replicates part of the functionality of interwiki within RT messages by converting the [rt:123
sequences into links. This also features the ability to create links between tickets using a #123 syntax as well, which I'd like to add to the knowledge base eventually as well because I find the Trac-style linking of #123 (tickets), @123 and r123 (revisions), and [123] (changesets) to be very easy to remember and very handy.

That gets me much of the way to an integrated Drupal/RT knoweldge base/issue tracker system. I still need more though, but I haven't gotten there yet. Stuff I'd like to add in:

• Organic Groups. This would allow us to have a subsite for each knowledge base: one for internal IT, one for web development. Later, we could add one for sales information, one for content style guides, or whatever.
• Fix/replace interwiki. The interwiki module is nice, but isn't quite nice enough. It would be nice to have additional formats available. With very little effort, I should be able to create a custom filter to either extend this functionality or outright replace it just for our needs.
• Single Sign-on. I have some experience with this lately. If I can get it so that I only sign in once to Drupal and or RT and then I'm in both, that would be great. If I could implement it using an independent LDAP server, all the better.
• Configuring RT. Configuring the interwiki-ish filter for RT is done in code. This isn't ideal. With whatever solution I work on for Drupal, it would be nice if the RT filter could load it's configuration from the same place, or at least get it from a config file and not in the code itself.

Will I get all this done? Probably not, but I'll get some of it done and if I think it's interesting, I'll try to share it with you.

Cheers.

One of the features I'm looking into the improved New Hope Church web site is Organic Groups. Organic Groups is a module for Drupal that allows for the creation of sub-communities in a social networking site. Every social network is made up of a larger collection of individuals that all have a collective goal or interest they are pursuing. However, each individual has their own unique abilities (er, maybe that should be Unique Ability¿, oh wait, this is my blog, not work ;), interests, and agenda. Generally, the individuals will sort themselves into a clique within the larger community that allows them to serve and be served in a way that fits. Organic Groups is the Drupal-way of facilitating this.

How would this be useful to New Hope Church? After installing the module, I would grant each person with the Ministry Leader or Staff Member role the ability to create groups. This includes everyone who runs a LIFE group in our church. Each leader could then create a group for the group or groups they lead. Then, each member of that group can subscribe to the group and gain access to the group discussion. Each group could have a forum for discussions, a calendar of events, documents such as current lesson notes, blogs, prayer requests, audio messages, image galleries, mailing lists, etc. Anything the main site can have, we can allow each group to have within itself. Group data could be made public for anyone to read or private just for subscribed group members and subscription can require approval by the group leader. That's a lot of flexibility.

Okay, sounds great. However, there are a few caveats. This will require work to setup and probably some amount of maintenance. Currently, I'm only one guy with some help from a couple others. However, if this became popular, I'm betting I will have at least one or two other folks interested in helping out. Another caveat is that not everyone will want to participate in the online part of the site. Some may not want to visit the site and some groups, accountability groups, for example, might need a level of privacy that prevents this from being useful to them. That's fine. They don't have to use it if they don't want to, but that doesn't need to limit the others.

The last issue is that I'm basing all of this on my reading of the Organic Group documentation. I've found that implementation, invariably, differs from documentation. Therefore, I suggest that it may not be quite as flexible or cool as I've described, but the general idea is definitely in place and the majority of it does work as I expect (I have demoed parts of the functionality).

Anyway, that's my vision for how to increase LIFE group communications online. This idea was never as fully formed as this, but it has been the general vision from the beginning to facilitate communication and community through the web site from the beginning of this project in 2003. I think we're very close to making this a reality now. I'm excited.

Cheers.

Okay, so I'm announcing here the first mini-launch of the New Hope Church web site. The site is now running on a later version of Drupal and should have most of the old features intact, with a very few additions. I need to get the login information to Eric so he can start on the theming now so we can have the full launch.

I'm most excited right now about the new features that are coming rather than the few I've added. I'm going to talk about both and the features we already had as a reminder.

Existing Features

The New Hope Church web site has featured these capabilities to date:

Blogging

Any staff member or ministry leader in the system has had the ability to create a blog within the site. However, a very limited set of members have been given the appropriate permissions and of those, they generally have blogs elsewhere or not at all.

Comments

Any authenticated visitor to the site may add comments to most of the stories, audio messages, and events on the site. Again, however, this has never been used. It has never been advertised and I don't know if anyone has noticed the comment links since the current site design works to hide them.

Contact Forms

Each staff member has a contact form on the site. This was the only available way of contacting staff members during the previous iteration because I never implemented a better way. The main problem is that the contact forms require registration to work.

Events

This was one of the most heavily used features. The only serious issue with this was that recurring events weren't possible, so we couldn't add events like the Fusion youth meetings or Sunday gatherings unless we wanted to add each and every occurrence. I don't think anyone on staff has that much time to spare.

Messages

This is the single most used feature of the site. We upload audio to the site and then visitors can read notes about the sermon, download the audio, and listen to Podcasts.

Map

There is a map on the site showing the location of the old church office, Flint Hills Christian School where we meet for on Sunday, and the location of our land. Unforunately, an IE bug I documented a while back keeps that from working properly for anyone using IE.

Notifications

Staff, ministry leaders, and administrators (i.e., me) can setup email notifications when the site changes. I originally use this to watch for when Tony uploads the audio and to check back to make sure things were working. However, I confess that I've been simply deleting the notifications lately.

Pages

Various informational pages have been placed on the site. So far, this isn't much used, but I think that we'll see the amount of information on the site increase over time.

Biographies

Each staff member has a bio on the site associated with their user page. Any member of the site may also have a biography. More information could be added to the member profiles in the future, but I have no direction on what kind of information folks would like to see.

Search

The Drupal search abilities were a little pathetic in 4.5 and 4.6, but it looks like things are quite a bit better now in 4.7.

Announcements

In addition to events, some announcements don't have a specific date associated with them. These are heavily used in the current system and this should continue.

Categorization

Currently, categorization is only used to differentiate between which announcements and events belong to which ministries. With this update I've replaced the original categorization system with a different system that I think will serve us better.

Throttling

The site does have some throttling capabilities. That is, when it starts to see heavy loads, the site will start disabling some features of the site to keep it from being too overloaded. I've not configured this very well yet, so it probably needs to be looked at some more.

TinyMCE

No one visiting the site needs to know HTML. All pages can be editted using an editor with a Word-like interface.

Upload

Staff and ministry leaders can upload files to the site to associate them with stories, pages, events, etc. Unfortunately, our hosting service limits uploads to under 10MB, so this doesn't always serve us very well.

URL Filter

All documents on the site will automatically convert unlinked URLs and email addresses into links. This is also meant to simplify how the site is used for the non-tech-savvy.

Okay, that's what we already had. Now, on to what has been added.

New Features

Here's the list of new features that I've added with this update of the software running the web site.

Categories

I've switched the system from the "taxonomy" plugin to the "categories" plugin. One of the main reasons Drupal is popular is it's "taxonomy" system which provides a very rich language for describing metadata. Metadata, in this case, is basically just extra keywords associated with any particular page on the site.

For example, an announcement might have a taxonomy term associated with it named "Announcement" in the "Section" vocabulary. It might also have a term of "LIFE Groups" associated with it in the "Ministry" vocabulary. Each term is a particular keyword and each vocabulary is just a set of related keywords. The taxonomy system is very nice, but it has a shortcoming in that you can't describe the terms themselves very well. For example, what are "LIFE Groups"? What is a "Ministry"? These might be legitimate questions we'd like to answer and the taxonomy provides only a very rudimentary solution to this problem. I used some weak solutions in the previous version of Drupal to address this problem, but they didn't really work very well.

With the latest version of Drupal there's a new module called, "Categories" that promotes each vocabulary to a first-class citizen called a container and each term to a first-class citizen called a category. Each of these have the same full power as a regular web page and can contain a full description of what they are. This is a cool enough feature, that I will probably start using it on this web site soon. Kudos to Greenash for pioneering this.

Repeating Events

This resolves the old problem of not being able to have recurring events on the calendar. We can now create an event for Sunday morning worship and then make it a recurring event that repeats to a certain date. Handy.

Feedback

In addition to the Contact forms already in place. I've now added three new feedback forms that do not require creating an account to use. This will surely mean a little more spam for those of us on the receiving end, but that's not easy to avoid. There's now a form that is kind of an online "white card" like we pass out in church, a form for prayer requests, and a form for site problems.

Google Analytics

The chuch site has started collecting more statistics about visitors to help us improve the content of the site. I used Google Analytics because it's free, though, we've had some worries about it's accuracy at work. I'm hoping it will be better than nothing.

Just in case, I have also added a couple other stats modules to Drupal as well, to use Drupal's built-in statistic gathering capabilities to track things directly from the site too.

Google Sitemap

The site will start generating a Google sitemap, which should help improve how our search results show up in the most popular search engine.

Menu

This is a de facto improvement that comes just with upgrading 4.7, but we can now create much nicer menus in the system than we could before.

Automatic Path names

No more "node/123" links! I've added this in to automatically create easier to read and link paths within the system. Anytime someone joins our site, they're user profile will be at "user/user_name" rather than "user/123". Similarly, whenever an event is created, it will be at "calendar/2006/08/13/some_event_name". There are still a few irritations to work out of the names being generated, but I'm much happier with the way this is working already. By the way, the old links still work too, so they won't be broken either.

That's what's already new. Now on to the stuff that I think's going to be freakin' cool.

Upcoming Features

Here's my wishlist:

Google Map Improvements/Location/Geocoding

I've already started playing with this a bit. One thing a lot of folks have asked for is an online directory. I've been thinking about how to do this and I think I can provide an online directory for members that will not compromise anyone's privacy.

In addition to providing a directory, I will be able to provide a map showing the map location of all our members on a single map. So, you'll be able to see how close you live to fellow New Hope members. This will probably include a more public way of publishing LIFE group and event locations as well.

Forums

I would like to add forums to the site. Drupal 4.7 now includes the ability to create a pretty decent forums system directly in site. I think we could have various forums for things, particularly site suggestions and problems. This will be combined with my next item...

Organic Groups

This is a feature added by the CivicSpace crowd to allow members of a Drupal site to create groups on an ad hoc basis. With some controls on the system, we could allow staff members and ministry leaders to create mini-sites in the system with their own stories, events, audio messages, forums, etc. I see this as being a really exciting feature for the web site with the potential to revolutionize the communications abilities of thte staff and other leaders.

Okay, that's not the full list of what I want to do, but that's plenty long enough. It will probably take some weeks before any of the latter bits are implemented and I'm still looking for and waiting to hear bug reports on this latest update.

Cheers.

I'm going to make this quick because Terri needs a counter-weight in bed (we have a waterbed) and I've already wasted much time responding to Slithy on Brent's blog on the history of sexual promiscuity in western society.

I've started the module update and have gotten most of the replacement modules installed that can be installed. However, I've had to get a replacement for the taxonomy_assoc module (as I thought I probably would), since that module has been discontinuied in favor of the Category module.

The Category module is a drop-in replacement for Taxonomy that replaces vocabularies with "containers" and terms with "categories". The difference is that both of these are now nodes. Not only this, but any content type can be treated as a container or category, effectively giving you a node for every term. Unfortunately, it's not quite as flexible in some ways as it doesn't seem to have a "folksonomy". Though, I haven't yet looked at it far enough. If it does have tagging or it can be added, I will probably migrate this site to it as well.

This module also replaces the Book module, but I haven't really looked into that since we don't use the Book module for anything at New Hope yet, though I think we might after talking to Dan and Tony a couple weeks ago.

Other than that, I've also added, but haven't tested the eventrepeat module. I've updated the various other modules that are available that I mentioned previously. I also need to see if Tony wants me to do anything to add image galleries, forums, and some other pieces. Finally, I think things are now to the point that Eric can start working on the design whenever he feels like it.

Cheers.

As I said earlier this week, I want to write about how I implemented single sign-on for the new Boomer.com web site. I didn't come up with the design on my own, but the implementation is from scratch and unique--i.e., proprietary. In the future, I hope to replace the system with something else but since certain aspects of our system's integration or currently in limbo and the lack of prefab Magnolia-to-Drupal implementations, a quick and dirty implementation was certainly in order. I like the results, as much as I can for a quickie, which is why I share it here.

Design

As I just mentioned, I did not invent this design myself. I merely implemented the pattern described for Cosign, a project at the University of Michigan. If my deadline hadn't been looming so close, I might have considered implementing a Drupal plugin for Cosign. As it were, though, I created a fresh implementation that has no other relationship to Cosign than the fact that I have approximately the same structure of HTTP requests and responses that it has (and probably several other implementations).

For the following use-case, I will call the web site that holds authoritative information the Auth-Site and the other site requring authentication information against the Auth-Site, the Sub-Site.

Basically, the use-case works like this:

1. The Client attempts to connect to a protected document on the Sub-Site.
2. The Sub-Site server returns a Sub-Site session cookie to the Client and redirects the Client to the Login-Checker of the Auth-Site.
3. The Login-Checker of the Auth-Site determines if the Client has logged in already to the Auth-Site. Assuming that the Client has not, the Login-Checker returns an Auth-Site session cookie to the Client and redirects the Client to the Login-Form.
4. The Client then fills out the Login-Form and returns it to the Auth-Site, which validates the login using the Login-Form-Checker. Assuming success, the Login-Form-Checker notes that the original Auth-Site session cookie came from the Sub-Site. It then performs a redirect to the original protected document on the Sub-Site that includes in the URL a Login-Token.
5. The Client then returns to request the original protected document from the Sub-Site, but with the Login-Token this time. The Sub-Site then performs an out-of-band (direct connection from Sub-Site to Auth-Site) to see if the Login-Token is valid. Assuming the Login-Token is valid, the Auth-Site returns the Client profile to the Sub-Site and the Sub-Site returns the protected document.

That probably sounds pretty complicated, but it basically amounts to the Sub-Site deferring login to the Auth-Site and asking the Auth-Site for a Login-Token to validate the user by. The major hiccup is the risk of session hijacking if an attacker happens to guess the token.

If that's still confusing, the Cosign site has a lovely sequence diagram of the interaction.

Implementation

So the actual implementation required two additional Java servlets to run with the Magnolia server (in addition to the login servlet already in place). One I called the CheckForLoginServlet. This servlet checks to see if the visiting user has already logged in. If the user has, the user is redirected from whence she came with the login token to verify her authenticity. If the user is new, the user is then redirected to the login form, which is notified of which URL the user needs to be returned to afterward.

The second servlet is the ValidateAuthTokenServlet. This servlet handles the out-of-band, server-to-server communication, which verfies the user and sends an XMLized version of the user's profile from Magnolia auth-site to the Drupal sub-site. The token itself is a UUID, which should be sufficiently difficult to guess, but might still be vulnerable to snooping attacks, since the communications aren't currently encrypted. Really, though, this is no worse than any other plain text login, which has the same vulnerabilities. We plan to move the authenticated parts of the site to SSL in the next few months to make the system stronger.

Another interesting piece to the puzzle is that I made the LoginToken objects semi-autonomous in that they erase the persistent data they store with the user objects when the session they belong to is invalidated. A user can login multiple times from differnet locations and each location will have a unique session token. When the user's session times out, the token is also invalidated.

On the Drupal side of things, I had to add a couple little hacks to get things to work just so. First, since the Drupal site is entirely contained within the Extranet, all documents are protected documents. No one should see anything on the site without logging in first. Thus, I overrode hook_init to perform a redirect to the CheckForLoginServlet unless the request came with a login token, came from a browser with an already validated session, or was coming for the cron script---which I didn't want to authenticate to execute.

If the request comes with a login token, the Drupal server performs the out-of-band check against ValidateAuthTokenServlet to see if that login token matches any current user session. If it doesn't, the user is kicked out to the CheckForLoginServlet to login again. If it does match, the user is, effectively, logged in by a special subroutine which loads their profile information from the XML passed back by the ValidateAuthTokenServlet. This also updates all the roles the user is in to make sure his permissions are correct and then drops them into the page.

All-in-all, the visitors should be relatively oblivious to the system. The only hiccup at this point that I need to take care of is to make sure that anytime the query string of a request to Drupal or to Magnolia contains a login token, that the client be immediately redirected again to remove the token from the location bar. Those tokens shouldn't accidentally end up in linked URLs if the user copies-and-pastes, or someone may find themselves logged in as the other user---i.e., bad stuff.

In the long-term, however, I will probably implement something like Cosign or CAS or SXIP, depending on how things shake out over the next few months. If we choose the right standard, we should be able to provide better integration with clients or third party apps to improve our SaaS opportunities in the future.

I've started the software update for the New Hope web site. I've got the main Drupal system updated, but I haven't started on the modules. I'm doing the updates to a copy of the site so the current site can still run in the meantime (so don't bother looking for changes as they won't show up until we're done).

The trickiest bit is going to be that some of the modules we use on the current site are used because Drupal was lacking certain features that it no longer lacks. The other tricky bit will be the modules that are being discontinued in favor of better solutions--i.e., I'll have to do some conversions.

Here's the list of modules that need to be updated:

• event. I also plan to install eventrepeat as part of this process so that we can start showing recurring events, like Sunday mornings and youth meetings.
• flexinode. I'm going to replace this module with the content construction kit if I can. If it will be too painful, I may leave this for an update in a month or two.
• form_mail. I don't know what to do with this. I don't know what is available for this functionality.
• forms. Ditto.
• notify. This will either be an upgrade or I'll use a better notification module (not that there are many good choices for this functionality, according to my recent research).
• sermon_customizations. I hacked in some functionality to make Podcasts and some other bits to work correctly. Most of this can probably be ripped back out.
• taxonomy_assoc. This module associates nodes with vocabularies and terms. This is used in some important places, so I'll have to see what to do about this one (or just update, if possible).
• taxonomy_context. I can't honestly remember what this does at the moment, but I think this is a ditto of the last comment.
• theme_editor. I'll have to find out from Eric if this is still needed. I may just turn it off.
• tiny_mce. This is important. This makes it possible for our staff to post to the site without knowing any HTML or special document formats. I'll probably need to discuss with other stakeholders what features to include in the future too. There has been some disagreement about which functionality should be available to authors.
• urlfilter. This is used to turn http://... strings into links when someone doesn't link a URL. This is probably a trivial update.

The last bit that I'll need to update is making sure the script I've written to allow Tony to upload recorded audio also gets a face lift. It'll surely need a few changes. I wrote this script to get around upload restrictions set on PHP code on our host and to help standardize the MP3 tags in the audio for the Podcasts.

That pretty well summarizes my plans for the next launch. Eric is going to be responsible for importing the design that Jay Risner has put together for New Hope. I hope we can get the first release knocked out by the first week of September. I'd like it to be before the students return, but that may not be realistic given the data conversion I'll have to perform and some of the remaining design questions Eric has. We'll get it done.

Cheers.

My web site was never so popular as it were when it were Drupal. Now I'm back to the glory days. Well, maybe. I lost a lot of prestige in the months that I quite maintaining my blog very well while I was attempting to build up Contentment. It also hurts that the paths I had have changed and broke and are incorrect. However, I now have better paths due to my friend, pathauto.

I've now finished importing all the content from my previous WordPress and Drupal sites. I did the blog posts by hand because many of them needed editting and I took it as an opportunity to remember the olden days. There's still more work to be done if I'm really going to get the archives correct since some links have changed and some of the text encoding is screwed up in a few places still, but it may just stand as is.

I've been thinking of bringing in my Blosxom posts as well and even thought of going back to the stuff I built in Everything and back in the static HTML days of yore, but if that happens it probably won't be this month. ;) I'm tired of imports, but I may end up doing it.

One of the coolest new custom features I built this time around was the Categories block to the side there. The most exciting aspect of that is how I order the categories so that both quantity and how recently the tag was used. I built a corresponding Popular Tags page describing how the process works containing a complete list and shows individual scores. It's not perfect, but it's relatively nice.

I still need to tweak the design more. Comments look terrible and I'm not very fond the sidebars. They should match the curviness of the banner. I also need to tweak margins because there's not enough whitespace. However, I wanted to launch as soon as possible because it's a drag having a sucky blog...at least for me.

Cheers.

Ooblech. I'm tired. I better get this posted and then get some sleep.

I'm excited to announce the two new site launches: this web site and a new Boomer.com. The latter has involved 6 months of my blood, sweat, and late hours. The former took me all of today to revamp and re-re-re-re-re-release. I'm also working on launching about three other web sites in the near future.

Home Site

As I stated previously, I'm going to start toning down the development I do at home. Well, at least that was the plan. It didn't really work as I thought. I've probably spent almost as much time in front of a screen at home as at work over the last few months. The reason is related to some work I've been doing with Perl and Java---which, incidentally, might be published on Perl.com in the next few months.

I've been toying with the idea of using a Java-based database engine called Jackrabbit with a Perl web front-end called Catalyst. While that was a fun project to work on, the results weren't quite as nice as I wanted. Rather than continue tweaking it into what I want (which would probably only take another month or two of effort), I'm going to take what I've learned and move on to using Drupal again instead.

Why back to Drupal? Well, I was using WordPress, which is a pretty decent blog app. However, it's just not as easy to hack as Drupal is and I know that if I have a blog, I'll still want to tweak it, but that's not so easy with WordPress. Furthermore, I'm webmaster for the extranet site at work, which is Drupal, and our church web site, which is Drupal. I figure I can maximize my ability to maintain all these Drupals. Drupal is an excellent general purpose CMS even if it's a little bit of overkill for a blog.

I'm also starting to contribute to a number of different web sites and I'd like to have one central location to collate all those contributions and I hope to make this the place. With some enhancements, I think either the built-in or one of the other aggregation modules available for Drupal will come in handy for this. I also have a kiddo on the way and plan to share photos here. That is to say, this isn't going to be just a blog for long.

Finally, as I mentioned I did learn something from the Perl/Jackrabbit integration and I plan to use some of that to improve the user interface of Magnolia (see below) and/or Drupal. I'll probably write a blog on what I learned in the next few days so that these thoughts aren't quite so nebulous.

Boomer.com

Boomer.com is another interesting beast. I'm still trying to decide how I feel about what we've done. It looks pretty good. Though, the look will never look as good as either Eric or I want it to. Being so close to the project, I know all of its blemishes. Like home remodeling projects, when you fix something, there are inevitibly a few mistakes that bug you, but when you look at project by someone else, you never even notice them. It's the same way here: I will always know what isn't quite as nice as it could be even though almost no one else will notice.

As for the technology, we've actually built a hybrid of Magnolia and Drupal. That's mostly interesting because Magnolia is written in Java and requires a Java-based application server, while Drupal is PHP based and requires CGI or an Apache module to run. There are some tools to help PHP and Java communicate server-to-server, but we haven't used any of them, mostly because we couldn't get them to work correctly within our timeline.

However, I'm pretty happy with how well the integration works. The most interesting project related to this so far has been the implementation of single sign-on, which required some interesting redirect tricks. It works pretty well and I'm confident that our customers will be completely oblivious to the nuts and bolts of the process. I'll probably blog on the single sign-on process in another blog coming up, so look for it! ;)

Just because we launched, though, doesn't mean we're finished. There's a long list of new features to add. Since I'm not sure how much of that list is safe to tell, I'm going to just say that we hope to sell more stuff and hope to add more multimedia and hope to put up some additional web-based applications to facilitate our consulting; that ought to vague enough. :P

Other Sites

I'm also working on a few other projects. A couple of them I don't really want to talk about except to say that I'm working on them. ;) However, our church web site is one of the biggies I'm currently working on. This is another Drupal site. First, the web site is currently running an old version of Drupal (either 4.5 or 4.6, I don't remember which and 4.7 is current). Second, the church has been redesigning the look of our logo, letterhead, signage, and web site. The web design has been chosen and Eric and I will be putting that together as soon as we can.

Anyway, I'm excited about that and the fact that the church will be starting a monthly newsletter to help drive new traffic to the site. I hope this will improve communication for our members, which has been a historical problem of our church (as it is with so many).

That's what I'm working on. As I said, I'm tired and now it's time to sign off.

Cheers.

Ooblech. I'm tired. I better get this posted and then get some sleep.

I'm excited to announce the two new site launches: this web site and a new Boomer.com. The latter has involved 6 months of my blood, sweat, and late hours. The former took me all of today to revamp and re-re-re-re-re-release. I'm also working on launching about three other web sites in the near future.

Home Site

As I stated previously, I'm going to start toning down the development I do at home. Well, at least that was the plan. It didn't really work as I thought. I've probably spent almost as much time in front of a screen at home as at work over the last few months. The reason is related to some work I've been doing with Perl and Java---which, incidentally, might be published on Perl.com in the next few months.

I've been toying with the idea of using a Java-based database engine called Jackrabbit with a Perl web front-end called Catalyst. While that was a fun project to work on, the results weren't quite as nice as I wanted. Rather than continue tweaking it into what I want (which would probably only take another month or two of effort), I'm going to take what I've learned and move on to using Drupal again instead.

Why back to Drupal? Well, I was using WordPress, which is a pretty decent blog app. However, it's just not as easy to hack as Drupal is and I know that if I have a blog, I'll still want to tweak it, but that's not so easy with WordPress. Furthermore, I'm webmaster for the extranet site at work, which is Drupal, and our church web site, which is Drupal. I figure I can maximize my ability to maintain all these Drupals. Drupal is an excellent general purpose CMS even if it's a little bit of overkill for a blog.

I'm also starting to contribute to a number of different web sites and I'd like to have one central location to collate all those contributions and I hope to make this the place. With some enhancements, I think either the built-in or one of the other aggregation modules available for Drupal will come in handy for this. I also have a kiddo on the way and plan to share photos here. That is to say, this isn't going to be just a blog for long.

Finally, as I mentioned I did learn something from the Perl/Jackrabbit integration and I plan to use some of that to improve the user interface of Magnolia (see below) and/or Drupal. I'll probably write a blog on what I learned in the next few days so that these thoughts aren't quite so nebulous.

Boomer.com

Boomer.com is another interesting beast. I'm still trying to decide how I feel about what we've done. It looks pretty good. Though, the look will never look as good as either Eric or I want it to. Being so close to the project, I know all of its blemishes. Like home remodeling projects, when you fix something, there are inevitibly a few mistakes that bug you, but when you look at project by someone else, you never even notice them. It's the same way here: I will always know what isn't quite as nice as it could be even though almost no one else will notice.

As for the technology, we've actually built a hybrid of Magnolia and Drupal. That's mostly interesting because Magnolia is written in Java and requires a Java-based application server, while Drupal is PHP based and requires CGI or an Apache module to run. There are some tools to help PHP and Java communicate server-to-server, but we haven't used any of them, mostly because we couldn't get them to work correctly within our timeline.

However, I'm pretty happy with how well the integration works. The most interesting project related to this so far has been the implementation of single sign-on, which required some interesting redirect tricks. It works pretty well and I'm confident that our customers will be completely oblivious to the nuts and bolts of the process. I'll probably blog on the single sign-on process in another blog coming up, so look for it! ;)

Just because we launched, though, doesn't mean we're finished. There's a long list of new features to add. Since I'm not sure how much of that list is safe to tell, I'm going to just say that we hope to sell more stuff and hope to add more multimedia and hope to put up some additional web-based applications to facilitate our consulting; that ought to vague enough. :P

Other Sites

I'm also working on a few other projects. A couple of them I don't really want to talk about except to say that I'm working on them. ;) However, our church web site is one of the biggies I'm currently working on. This is another Drupal site. First, the web site is currently running an old version of Drupal (either 4.5 or 4.6, I don't remember which and 4.7 is current). Second, the church has been redesigning the look of our logo, letterhead, signage, and web site. The web design has been chosen and Eric and I will be putting that together as soon as we can.

Anyway, I'm excited about that and the fact that the church will be starting a monthly newsletter to help drive new traffic to the site. I hope this will improve communication for our members, which has been a historical problem of our church (as it is with so many).

That's what I'm working on. As I said, I'm tired and now it's time to sign off.

Cheers.