I was recently attended Drupal Camp Alberta with about another 50 people. The reason for my attendence was that I had been invited to speak about the drupal services module as one of the co-maintainers of the project.

As a well-known Drupal shop, Trellon continually strives to contribute back to the Drupal community in any way it can. Sometimes, we're just too busy, other times, we're just plain ol' lazy and, more often than not, Morbus is complaining about quality or phenoptosis or whatever. By keeping track of what we give back, however, we hope to more clearly see how much we are, or aren't, helping Drupal help ourselves.

I've just released version 1.0 of the Teleport module. Teleport is "QuickSilver for Drupal", but if you don't know what QuickSilver is, that's not going to tell you much. Basically, Teleport lets you quickly jump to a page on your Drupal site by typing in part of the path or the title. It saves me a ton of time when jumping around to administration pages that are nested two or three levels deep. See an example in the screencast.

Since the beta release, I've fixed a few bugs and added the ability to search path aliases. I thought that searching paths was important enough that it had to be included in a 1.0 release.

Trellon is one of the sponsors of the third annual DrupalCamp Toronto, which will take place on May 23rd and May 24th at the Faculty of Information Studies on the University of Toronto campus (map).

Here at Trellon, clients come to us all the time to looking for solutions for making knowledge more accessible through their web sites. Given that search features are a primary tool for exposing data and that the performance of Drupal's search engine is less than optimal in certain situations, we developed a module that replaces Drupal's native search features with the Xapian search engine. And here's why we did it.

Reason

A common challenge for Drupal sites is working with documents in different formats and getting them into the search engine. Drupal does not natively index PDFs and Word documents, despite the fact they are the most commonly exchanged text formats on the Internet (outside of HTML). This presents problems for sites where content is driven by document uploads, and has lead to some sub-optimal solutions and messy UI workflow patterns in the past.

Another challenge is performance. While Drupal scales well in terms of serving pages through the use of memcache, CDNs and op code caching, search functionality is another matter entirely. The organic nature of searches often defies attempts to bring this important subsystem to scale in high traffic environments. Alternative search engines, like Google's Site Search and Yahoo's web services, often need to be leveraged in order to handle the demands that come along with high utilization.

To attempt to solve these problems, Trellon spent some time working with at alternative search engine solutions for Drupal, and one product we came across that can get the job done is Xapain. We have just released a module that replaces Drupal's native search with Xapian, and it can be downloaded from it's Drupal project page

As a well-known Drupal shop, Trellon continually strives to contribute back to the Drupal community in any way it can. Sometimes, we're just too busy, other times, we're just plain ol' lazy and, more often than not, Morbus is complaining about quality or apoptosis or whatever. By keeping track of what we give back, however, we hope to more clearly see how much we are, or aren't, helping Drupal help ourselves.

It's common practice for theme function writers to give every div a class, so that it can be targetted by CSS. For us, this is especially important in forms, since our clients often ask us to lay out forms in complicated ways.

This was a problem in Drupal 5 (and earlier). Although form elements had ids, so specific elements could be accessed from Javascript and CSS, they are all encased in wrapper divs with class "form-item". This means there's no easy way to lay out a specific form item.

Currently we are carrying out a piece of integration work between Drupal and Salesforce. Drupal is responsible for pulling the data from Salesforce and this achieved by calling the SOQL api via a webservice. The data is returned in a SOAP format. This article assumes you are using this salesforce client

http://sourceforge.net/project/showfiles.php?group_id=96634&package_id=1...

The challenge of working with high volume Drupal sites lies in the relationship between the CDN and the underlying memcache implementation. Sometimes, a vicious circle occurs where the CDN and Drupal just can't get their collective act together, and strategies for prepopulating cached content come into play.