After spending over 4 months developing my first non-English website in Drupal and proving to myself that Drupal could be used effectively to create a full non-English front-end and be able to administer it using a full English language back-end, I tried with my new project, Offshore Fund Club, to take it to the next level and over 5 months later it is finally online. With this project the goal was to create a full membership website in Japanese related to offshore investing and offshore funds using Drupal to manage the boring stuff, adding in multiple roles, complex permissions and managed user accounts and complex taxonomy for organizing member only content.
Why Drupal
I have spent the past few years developing progressively larger and more complicated sites such as Offshore Library and programming them by hand from start to finish. As website development branches out into many different sub-areas of expertise, I found it more and more time consuming and tedious to handle every aspect of these projects alone. Creating and maintaining xml sitemaps by hand can be a pain and managing simple functionality like breadcrumb navigation can become tiresome as the project grows and more small changes need to be made, or committing the worst faux-pas of all by changing the navigation structure. Writing individual programs to manage these small tasks also becomes tiresome and I was stuck in the mundane details of small tasks and lost site of the big picture sometimes.
Picking up my first book on developing Drupal templates was the real inspiration that made most if not all of those agonies go away. Since then I revel in all the complexity I can dream up as I know Drupal’s foundation makes it easy and saves me hundreds of hours and makes the bosses happy. Yes I still love to program things by hand when I have time, because it’s much more satisfying when it works, but not having to spend hours on tedious programming is a real joy and cuts down on the headaches.
In my opinion the areas Drupal helps most are, managing database schemas, template management; content organization, security and content updating.
Starting Out
To begin with I knew the ultimate direction I was going to take the site so this helped me to plan the structure. The main functionality would be a members only fund information database viewable by multiple categories and sub-categories with all the usual extra stuff like blogs, forums, news archive, videos and other exclusive content all of which had to be only accessible by members with the proper permissions. Using Drupal’s roles integration made this easy. Well not really that easy, but after a dozen or so variations I had the right blend of accessibility and restrictions. The bad side effect of for example, adding a new role later on is that a lot of the permissions have to be filtered through carefully in what feels like many different locations. For example, forum permissions, taxonomy permissions, views permissions etc.
Templating is King
I think if you really want your site to be custom and not smell of Drupal too badly then you have to spend the time to develop your template/theme properly.
This may be counter-intuitive for some people but I always start with the interface when I am developing programs. I design what the interface will look like fundamentally and then start figuring out how each piece of the puzzle will slot in and interact and finally I start developing the function or tool in question.
I started in a photo editing program to draw the site on the screen, not with full detail, but just enough to get a general layout. Next I built this layout using a traditional method with a notepad style editor and writing the html and css mostly by hand, copying as much structure from old projects as I could to save time. I hate starting with a blank screen so I always copy in an old layout and start modifying it until it gets to what I wanted. I think it’s pretty boring to start from a blank screen and do all that hard work with divs to get your 3 column layout just right. I mean, how many types of generally accepted web layouts are there now anyways? Not that many. So just re-use and recycle.
Once the template was ready, I then went back and stripped out the junk, like the headers, so it could be cut out into its separate components and these could become some of the Drupal regions. It’s easy to add as many as you want in the theme’s .info file.
Then taking Drupal’s supplied page.tpl.php file I moved my template in piece by piece. If some of your pages will have a different look than the rest you can always add regions in your main template that are empty. So in some pages they appear and in others they have nothing in them and are not visible allowing your theme to be more flexible.
I knew my site was going to be non-English and using Drupal’s t() function makes adding in non translated sections easy at first and they can be replaced at any time later on without editing the template.
Content Types
Creating a new content type for my main members only content was necessary and ofcourse CCK makes this relatively simple. The biggest problem was creating a custom template for this content that was a one-size-fits-all solution for as many possible variations in the content as I could think of. For this I took the easy way out by creating a template file in my theme folder for the new content type, designing the layout and then using conditional statements in php to only display each field if it was set. The content_format() function was a big help here too as it made handling complex CCK fields such as dates very simple.
Displaying file uploads was more complicated and required custom code to extract the field data for display.
Building a Content Directory
The main members area of the site needed a searchable directory using a category based search. To do this I downloaded and highly modified the taxonomy vtn module. The module has many weaknesses out of the box and didn’t follow Drupal’s best practices very well but it was a great base to work from. It even allows you to rewrite taxonomy urls so you can have a logical structure with nicely organized urls that match your content.
Are there other ways to build a directory in Drupal? Sure! As always there are many ways but I thought this would be the quickest even though it probably wasn’t in hindsight.
Giving Visitors a Sneak Peek
As a members site I wanted to show visitors a bit of the content structure without showing them the members content. Using some of Drupal’s internal functions to check for role inclusion and then choosing to show or not show the given content allowed me to not have to hide whole sections of the site.
The unfortunate and usually nice side-effect of taking away permissions for content in Drupal using a module like acl or taxonomy access control is that the content and all links and menu items for it basically disappear to non-authenticated users. I didn’t want that in this case because I still wanted visitors to know the content existed, but when they tried to access it they would see a page describing the benefits of joining. I accomplished the same idea in views by not restricting the view itself but adding custom php code to the views header. This may not be the best way to do this but it works.
Securing Content
A big part of using Drupal is to help me be a bit more relaxed about security. A lot of people a lot smarter than me work hard to make sure Drupal is secure so that I don’t have to. It’s not perfect, but it’s a lot better than anything a developer can come up with on their own.
One weakness in Drupal’s armor is securing file downloads. Part of my membership only content is the ability to download exclusive documents attached to the members nodes. But just because the page that references them is managed by roles, permissions and logins, the files themselves are out in the open and can be downloaded easily if the user knows the exact url.
A big help here was the private upload module. Modifying this module to allow multiple secure sub-folders was just what I needed. The module uses a smart way of linking role inclusion with .htaccess to protect the attached content from non-authenticated users.
Managing Members
Surprisingly for a CMS so imbedded with user management and permission functionality Drupal makes it hard to manage a membership website. Why? Because first of all the registration process is not flexible at all. A lot of different addon modules have to come together to allow customizing the registration process, and if a payment gateway has to be integrated as well most people suggest abandoning the normal Drupal registration function altogether. The webforms module is fantastic for making custom forms and storing and sending that information to the correct people, but it is in no way linked to the registration process either. Using Drupal 6’s user profiles is tedious and not what you’d expect either. Unlike CCK you don’t get as much control over what fields you can add to a registration form and if some of that registration information is for the admin only, you’ll have a hard time hiding it later on.
Creating a good member signup and management system took a lot of experimenting and tweaking. The rules module along with user readonly, tab tamer, role expire, remember me, profile checkboxes, profile category weight, one page profile, login security, login destination, legal, auto assign role and many small modifications made it a reality.
Splitting Frontend and Backend, the Language Issue
In order to have the frontend of the site in one language and the backend in another was another challenge. Using Drupal’s built in language configuration was the most elegant solution. Making the frontend language default to Japanese, configuring the language path-prefix setting and then carefully managing the permissions so that non-administrators could not access the admin theme was the breakthrough. So when the administrator logs in they can see the administration theme in the language they choose but end users see a different theme using only the site’s default language.
Using Pathauto with a language other than English is a real challenge. Basically you must configure every detail for every node type otherwise you get some nasty looking urls. A lot of the time for blog posts that have Japanese titles I just enter the desired path manually.
Modules
Getting close to 100 addon and custom built modules. Every module interaction has to be carefully thought out at this point because there are so many areas for potential problems now. But each module has become a key part of the site and I have tried extensively to strip it down to its bare minimum for performance reasons.
Performance
Having not had much success with caching modules so far I opted to focus on end user performance enhancements most of all. These are mostly related to Yslow and compressing CSS and Javascript and trying to get all the expires headers set properly.
Monitoring
One of the main functions you need to administer a large site by yourself is proper monitoring and reporting in place. You need to know what errors are happening and how to fix them so I spent a lot of time making sure I could see all the log messages in the Drupal watchdog. This is the first place I check for issues on a daily basis.
Conclusion
Developing websites is a passion for the mundane. I love complexity and details but I also hate wasting time on them excessively. I will never stop trying to improve my projects as long as I have control over them and Drupal has opened up a whole new level of possibilities for me to realize grander ideas.