TammysRecipes.com: Our 3 Year Drupal Adventure

TammysRecipes.com: Our 3 Year Drupal Adventure

We recently re-launched my wife's "Recipe Blog" http://www.TammysRecipes.com and I thought it would be a great opportunity to reflect on our experience with Drupal as well as detailing some of our miss-steps. Hopefully our feedback can be useful to the community, especially those on the fence in regards to using Drupal (jump in!) as well as those just beginning a Drupal website (learn from out mistakes!).

In a sea of voices mine is but a single voice and should be taken with a grain of salt due my limited skill-set, not to mention the fact we have had our fair share of hurdles over the years. These concerns aside my hope for this entry is to reflect on our opinions and experiences from our vantage point and that these comments may be useful to new (and potentially new) Drupal users as well as Drupal developers gauging how Drupal is used by some and what they like/dislike about the product. While I have done some freelance web design and know a little PHP and MySQL I am not a high dollar professional and it is not what I do for a living. I am certain some of my "highlights" are groan worthy and some of my mistakes sophomoric (to be kind!) I hope the feedback is helpful to people looking into Drupal and can benefit from the mistakes of others as well as give yet another perspective on the benefits, and hurdles, of using Drupal.

Why we chose Drupal

Without boring you with a lot of details a short summary of our technical experience prior to this site may give some insight into why we chose Drupal. Before TammysRecipes.com I had done a couple handful of XHTML/CSS "brochure" sites for small businesses and non-profits, I had setup some PHPBB forums, played with some editable text area scripts, tested PHP Nuke and Mambo, had my own WordPress blog, etc but nothing overly fancy or complicated. At this point I had only dabbled in MySQL and PHP and had never deployed a large website using these technologies. A common theme I found when setting up websites was that people wanted to have a clean custom design as well as control over their content and site--but they didn't know any HTML and learning to use an entry level WYSIWYG editor was a met with resistance. The hurdle of maintain hundreds of pages was also quite daunting via the traditional route.

Thus I began my voyage for a resolution to these issues. I had tested some text area editing tools (SnippetMaster worked great for static sites) but these were quite limited. I had an aversion to PHP Nuke as I thought Nuke sites lacked elegance and had a lot of security issues. While I was learning PHP and MySQL I stumbled upon Mambo (before it branched to Joomla!). I immediately setup a Mambo test site for myself and had my wife try it out for her personal files (mainly pictures she was using for her LiveJournal). My wife liked it better than FTP or MS FrontPage but I found documentation (at the time) to be substantially lacking and the theming didn't quite jive with me. Getting basic questions answered was difficult and the version we tested, while feature rich, felt very “one size fits alls.” It was overkill for most things and seemed very oriented toward social sites.

I did take something positive from my Mambo experience: there was an active community of developers much more proficient and skilled than I was in solving “Web 2.0” problems. It made a lot of sense to explore these CMS frameworks for Churches or small non-profits that needed a solution that was ready to tackle the demands of a "Social Web" and allowed the site owner to make content changes (add, delete, and modify pages) without contracting additional work from a designer/developer. With the help of tools like OpensourceCMS I stumbled upon Drupal.

Drupal didn't have a snazzy design back then and the Drupal selling points were different depending on who you asked but a couple things appealed to me immediately. Theming was elegant--not much different than using "PHP includes" for calling content from one page in another. "Blocks" was a very, very simple approach to move content around a page and worked extremely well. The emphasis on the separation of content from style appeared to be very well done and allowed designers complete control over their site appearance. This meshed well with SEO (a Drupal strong point) which was accented by "Taxonomy." This was a "killer feature" back in 2005 when I was testing Drupal; the ability to organize and filter content based on tags allowed all sorts of flexibility that could be used on a small scale (tags that populated a menu bar) to extremely complex organization of data on content-laden websites.

The Drupal core was quite elegant in my observation. While it required more time to setup a new website than something like Blogger or Blogspot the benefit was you really could tailor the features deployed as well as the user access you wished to grant. Creating special user roles for the viewing and modifying of content is something easily taken for granted by Drupal users but it definately stood out in 2005.The ability to setup a simple brochure site or a complex community portal was the icing on the cake, so to speak. Being able to add a basic "Control Panel" for users and a WYSIWYG editor (like TinyMCE) with the ability to upload basic files (images, pdfs, etc) addressed some of my core needs. The Drupal community was also quite active; the core appeared to be under active development and maintenance, IRC was active and typically helpful, many forum posts received answers within hours (although there were a few occasions where getting an answer was difficult), and module development seemed to be at a breakneck pace.

The major weakness I saw in Drupal is that the forum module was spartan (to be kind) and getting basic features like private messaging and private forums had all sorts of issues (not to mention dependencies on non-core modules). Sometimes it doesn't make sense to recreate the wheel, and when user interfaces on social sites where you have hundreds, even thousands, of "entry level" users who want to be able to basic tasks quickly you don't want to confuse them. Drupal's forum module was counter-intuitive in this regards, lacked dozens of "standard" features that basic boards offered, had poor moderation tools, and sadly there was a strong undercurrent that appeared quite hostile to those who voiced these concerns. For someone looking for a more "mainstream" solution the Drupal forum was a mixed bag. Tight integration was a plus, but the lack of features for users and moderators and familiar interface were negatives. Using a specialized board for forums was an option, but there was the issue of user registration; unfortunately the bridges to SMF, PHPBB, and vB posed an array of challenges and risks and none seemed to pan out.

While the forum situation was a reality check (nothing is perfect!) I was still quite excited about using Drupal. The more I tested it out the more I liked the direction and decisions Drupal was going. Two community modules really got me excited: Views and Flexinode. The ability to create your own content types (Flexinode) that presented users with basic forms was perfect for some of the projects I wanted to work on. The ability to filter and present information on pages or blocks (Views) opened up all sorts of options for organizing and presenting data.

Overall Drupal appeared to be a great solution that was compact and accessible (the strength of applications like WordPress) without sacrificing the versatility needed to scale with the demands of a growing community driven website (something WordPress could not achieve at the time). Reflecting on the above points it has become clear to me that the more things change over time the more they stay the same. Drupal has continued its commitment to many of the core principles mentioned above and has continued to grow and improve in these areas. While there are a number of excellent competing products on the market (Mambo, WordPress, etc) Drupal was, and has continued to be, an amazing platform that I recommend.

TammysRecipes.com and Drupal 4.7

My wife had been using LiveJournal for a couple years and had decided she wanted to have her "own" website. Seeing a friend shut down for weeks by Blogger didn't sit well worth her (Blogger: "Woops, our mistake!") and the lack of flexiblity and scalability on her journal was cramping her creative juices. She liked what I was doing with recent websites I had made (mainly Church sites) and thought her Mambo site was pretty spiffy and would be perfect for her new website.

I had a better idea: Drupal.

We sat down and laid out a site plan for a website with three core goals: Tammy's encouraging blog posts (her friends loved these on LiveJournal), a Recipe archive of her favorite tried and true recipes (people were constantly asking her for recipes) that had pictures as well as user feedback on the recipe, and to create an interactive experience where visitors could be encouraged as well as encourage other homemakers.

The technological needs were as follow:

- Accessible Technology. My wife doesn't know HTML, CSS, PHP, etc. She needed a CMS that had built in WYSIWYG editor (like Word) to mark up content and upload pictures. The CMS tools to add, edit, and remove pages and to modify menus (even better: do it for you) had to be simple to use. => The Drupal core with some small additions, like TinyMCE, met this goal perfectly.

- Excellent Blogging Tools. My wife needed a blogging tool that had all the 'must have' features: easy content posting, user comments and moderation, WYSIWYG text editing, RSS, spam filters (Captcha), tools to allow unregistered visitors to comment but giving registered users more access/abilities, etc. => Drupal core (with a WYSIWYG editor freely available) is an absolute champ here.

- Versatile and the ability to Grow. The CMS had to be flexible enough to deal with a variety of content types/pages, have the ability to filter and display content in a variety of ways, simple enough to customize the look (without looking like a stock PHP-Nuke template!), and have the framework to grow as the site does. => This fit Drupal to a "t". The core module is light but extremely flexible (user roles, blocks, modules and community contributions, Taxonomy, Views, CCK/Flexinode, etc). Extras like "polls" are icing on the cake.

- Recipe pages and visitor reviews. A core component to the site was to be Tammy's recipes (as well as guest chefs) that had pictures (real pictures of what we eat--not some frilly cookbook pictures) as well as visitor reviews. We needed a way to sort and filter the content and would need it to be semi-self managing as Tammy had hundreds upon hundreds of recipes to share. => After testing the recipe module (poorly supported at the time) and looking at various options we settled on Flexinode for the Recipe pages and Userreview (and VotingAPI) for the user reviews. These choices were problematic as we will detail below... On the positive side Flexinode with Taxonomy tags allowed for great filtering of content--the recipe archive sorted automatically and makes for great browsing with views. The reviews, with a score compilation, show up in teasers with the review texts and scores showing up at the bottom of recipe pages. This worked GREAT until Drupal 5...

- Community tools. We needed social tools to allow user profiles, robust contact forms, commenting and comment management. We also wanted to have a forum and possible (down the road) user cooking blogs. => Drupal met all these needs less the forums. The forum module was not up to the task for our needs so we decided to put this feature (as much as we wanted it) on the back burner.

- Cost. We were willing to pay some for all of this, but didn't have a large budget (getting an adequate digital camera was already a large expense on our small budget). => Drupal is open source. I hate to call it free, but it is clearly an amazing bang-for-buck proposition.

- Future Looking. Some of our goals down the road were to have advertising (we eventually settled on Adsense and BlogAds with some direct advertising) as well as hoping to distribute Ebooks (which haven't materialized yet). => Drupal had the framework to meet these needs. There was the AdSense Injector (no longer supported... boo hoo!) and the ability to add not only HTML but PHP to blocks pretty much meant any Javascript or coded widget could be inserted with minimal effort. The ecommerce tools were slim back then, but they existed and showed a vibrant community.

Drupal fit like a glove (less the forums). The more I used Drupal the more comfortable I became with the CMS and was constantly in awe of the intuitive decisions the developers made. For someone who had a little PHP under his belt and work in HTML and CSS (but was by no means an artist) I was constantly impressed with how great the tools were. The more I dug into Drupal the more my imagination ran with the potential applications. Instead of being constrained Drupal constant provided tools to manage content in logical ways that non-developers could deploy. Drupal was very empowering, allowing us to build a website far beyond our own technical abilities.

Reflecting on what Drupal has allowed my wife to do is quite exciting. It is an amazing social tool that allows degrees of expression on the internet formerly limited to developers. My wife, with essentially no programming knowledge, has been able to deploy thousands of pages of media rich content (images, videos, podcasts) that is extremely interactive as well as organizes these with minimal effort. Due to the ease of use to create this content, and the great SEO optimization of Drupal, hundreds of thousands of people visit her little site every month. The ability Drupal has to connect people with common interests is amazing. Drupal's ability to allow non-techies to wade into the world of digital information (the former domain of geeks) is equally amazing. I cannot say enough nice things about Drupal. I wish I had more time to maintain the Flash-Tutorial Drupal site I made a couple years back.

Issues over the years (learn from our mistakes!)

Glowing feedback aside the three years of use has presented a number of hurdles for us technophiles. Some of these issues are general (MySQL) and others Drupal specific. I hope others don't run into these issues and can be viewed as words of caution. For those in these situations helpfully they give some helpful hints to resolving their quagmire.

MySQL 4.0 to 4.1 Migration. In the Spring of 2007 we had a server migration to an identical* server configuration. Nearly identical* as there was one caveat: the old server ran MYSQL 4.0, the new server MySQL 4.1. An incrimental upgrade shouldn't pose issues, should it? Indeed this was a huge issue as the base charset changed from latin1 to utf8. This resulted in a bit of garbled text. As I searched the Drupal forums I discovered this was an issue a lot of people were facing but there didn't appear to be any input at the time what was the cause and the proper course to remedy the issue. After a bit of help from the Drupal community (as well as some fine documentation from PHPBB users facing the same issue) the commands to export and import the database correctly were laid out. We lost about 6 weeks of content in the process (ouch!) but the database was fixed and we were able to participate in the contribution to the Drupal documentation in regards to this issue.

phpMyAdmin Backups. A small note to phpMyAdmin users: sometimes larger DBs don't get fully backed up—it is a surreal feeling to load a recent backup only to find it truncated! The commandline is much safer. I about had a heart attack when going through the above process and finding I had a very, very broken backup because it was an incomplete. After some searching the web I discovered this is a known issue with large DBs on phpMyAdmin. Thankfully I had access to the old server to make clean backups--but this could have been a disaster.

Flexinode. As detailed above a core element to our website are the Recipes. The approach we took was every recipe was a "real" recipe we or our friends used, they each had to have a picture, and we wanted reviews. We could have used "Story" or the "Page" content types but we wanted a consistant look with a straight forward "form" to enter the data and, more importantly, we wanted the content fields to be accessible by views. Creating custom teasers and sorting by the various fields was a huge plus that Flexinode addressed. CCK was in its most elementary stages of development back then and lacked a number of features (e.g. robust picture support) so we went with Flexinode.

Huge. Mistake. Unbeknownst to us Flexinode was on the way out--and never would make it to Drupal 5. So when Drupal 6 came about and 4.7 support dropped we were at a crossroads: over 500 pages of content core to the site could not be migrated as Flexinode had hit a dead end. I couldn't get the Flexinode-to-CCK converter working and keeping the associations between the userreviews and recipe nodes was an additional issue). We eventually paid for a developer to migrate our data for us. This was an expensive solution, especially for a small recipe blog.

Lesson learned: Use non-core modules at your own risk!!! If a core component of your site is going to revolve around non-core component prepare to (a) update the module yourself, (b) pay to have the module upgraded, (c) ditch that component of your website, or (d) risk staying on an unsupported and (eventually) insecure version of Drupal.

Userreviews. Same song, different tune. Userreview didn't make the jump to Drupal 5 either. This is a great little module that allows users to add reviews (including a rating, subject, and detailed comment) of nodes. We were using this for our Recipe reviews and we literally have thousands of recipe reviews by our community. Reviews were a core element to the website so we paid to have the module upgraded.

I am happy to report that Drupal has improved its tools for communicating to users the status of modules. The "activity" report communicates clearly how active a module is: active modules have a better chance of being supported in the future. The introduction of pledges and roadmaps, detailed summaries of module update status, etc have made it easier for users to know the future status of a module. While there continues to be a host of modules that randomly die off as well as significant duplication of modules with overlapping functionality the situation has improved. I hope the Drupal team continues to address the issue of communicating the status of modules--maybe someday where older modules will work on new versions of Drupal without incidence. This lack of continuity in conjunction with breakneck development of the core application while phasing out support for older versions is a rough spot that has been frustrating for us. We take our fair share of blame here (if we hadn't used non-core modules we wouldn't have this issue! If we had asked the right questions about module development, etc) and we paid (literally!) for these mistakes. Hopefully as Drupal matures this issue can be further addressed. Maybe developer pledges for Drupal 8 support now will give users a sense of developer commitment well into the future?

Module Installation / Uninstallation. Ever find a module with poor installation instructions? It probably means it has worse uninstallation documentation! As an open source project it really does fall on us to help resolve this issue, but a good piece of advice is if the documentation consists of less than a couple lines for all but the simplest modules beware! Drupal 5 now has uninstall on the module page for many modules but in 4.7 uninstalling a module could be quite a pain. In 5 I have already had the issue where a module I thought was uninstalled (Google Sitemap) conflicted with a new module (XML Sitemap). update.php didn't indicate any updates but that didn't prevent receiving errors.

Test site. One of the issues we ran into early on was that TammysRecipes.com was my first test site. My wife was excited to start blogging. The goal was to test things out and then go live with a new, clean install. This never happened. So early on we had a number of unused test modules laying around. What a mess! Having a dedicated test site is definitely a good thing, especially for your first Drupal site. Make it a sub-domain (test.domain.com) so you don't get tempted to just "go" with it. As you test Drupal out, play with settings, and try different configurations you run the risk of breaking something. This is a good process! Just don't do it to your live site! This also applies to sites “in development” and testing new modules. I had a case where I had added about 50 pages of content to a site and wanted to test out the taxonomy access module for private forums and in the process every node on the site was disabled! What a mess! We only have a small mess on the back end, but as I deployed my 2nd and 3rd Drupal site I realized a lot of little configuration mistakes I made with TammysRecipes.com, especially with Taxonomy. I could have been a lot smarter in how I organized content. I strongly encourage new Drupal users to create a "faux" site and really test drive it hard before doing "real" sites. There are so many things to do in Drupal and only through experimentation will you be familiar with the options available to make the best decisions.

Server Reboot. One issue we have not been able to tame is every server I have had this Drupal site on has required regular reboots or the server hangs after a couple weeks with HTTPD and MySQL chewing up resources. Currently we have a fairly beefy server with only a handful of small sites on it (Linux server with Cpanel/WHM, 2GB memory, 2.4GHz dual core processors, fast HDDs, 100Mbit Ethernet in a tier 1 facility) and the server runs great but if the HTTPD (Apache) and MYSQL processes don't get restarted every week or two the server inevitably hangs. If I had to guess it looks like a memory leak or thrashing (it isn't an attack and doesn't appear to be related to spikes in traffic) but I don't have enough information/skill to diagnose this (WHM and "TOP" newb here--not even enough to be dangerous). The servers run fine until this site is migrated over. Adjusting the MySQL and PHP cache settings may help, but I am no Linux guru unfortunately. I am definitely on the hunt for quality, and accessible, "How To" tutorials and guides for optimizing a web server for Drupal. Currently we are afraid that any large spikes in traffic could crash the server. The site handles hundreds of users at a time without issue but it seems as time goes on (without a process restart) the hang ups return.

As wonderful as Drupal is—and it really is—it does show signs of a rapidly changing product constructed by a “loose” community. Lack of documentation or clarity (do I need to disable every module to do an incremental update from 5.18 to 5.19? Why doesn’t update.php say there is anything in need of updating?), unknown contributed module stability and longevity, installation/uninstall issues, lack of application notifications (why didn’t Drupal comment on the mixed charsets?), organization of module control can be confusing (especially what options are where… Roles page? Setup page? When creating the content?) and so forth are general issues. Some would argue primarily user issues experienced by those unprepared to deal with the rigors of open source platforms and an application as robust as Drupal—and there is a lot of truth to this! Of course stability, accessibility, and ease of use need not be the foil of the Drupal vision. While I have seen great strides in these areas they do continue to be areas of need of improvement. For new Drupal users who are unprepared (technically or fiscally) to deal with a lot of these issues my advice would be to find a solid Drupal host and utilize the core technology (Drupal, CCK, Views, etc) and minimize your dependence on contributed modules for critical content on your website. This will make updating your website much easier so you can maintain pace with the rapid growth of the Drupal project. It is one thing to lose a fun widget that contributed nothing to your content, it is utterly depressing to be confronted with losing thousands of pages of content that produce hundreds of thousands of page views a month. The other suggestion to avoid issues is to dig into Drupal, test new ideas, be active in the community and try to do something to support the platform (e.g. improve documentation, design a theme, answer forum questions, etc). It won’t only help others but it will give you a better understanding of the tools you are using on your own website. The more you know about Drupal the better use you will get from the platform in addition to the ability to foresee undesirable development paths.

Our Favorite Modules

Below are some of our favorite modules and how we are using them. Hopefully for those looking into Drupal for the first time the following gives a basic idea of the flexibility Drupal offers. One thing lost in all the feature chatter below is how FUN it is to deploy new modules that meet your needs. It is a pleasure to have a site need/challenge and be able to deploy a solution that perfectly meets your needs, and then do what you really like: use the solution to create great content!

TinyMCE (WYSIWYG Editor). Drupal doesn’t ship with a stock WYSIWYG editor but this module is a high quality module that loads quickly and works well with roles/input formats. Looks like a paired down word processor and works just as well. The ability to reference custom CSS styles as well as the picture inserting (which works well) are especially useful for those with no HTML skills.

CCK. While you can create custom pages using “blog” “page” or “story” content types you won’t gain the advantage of filtering that content. Enter CCK. We are using this for Recipe content; every section from cooking time, servings, description, ingredients, instructions, picture, etc is a custom field. These custom fields along with Taxonomy tags create a lot of possibilities for content presentation. The ease of receipe entry and every page having a uniform and consistent look that can be altered universally (via CSS and the module) is a big plus. Another advantage is that in conjunction with Views we are able to create custom teasers (e.g. Recipe name, picture, description, and userreview score) and create pages based on taxonomy (e.g. Desserts, Main Courses, etc). We have barely scratched the surface of CCK, but this is an exceptional module. (Note: we did our initial custom content types with Flexinode.)

Taxonomy (Categories and Tags) . I really enjoyed Biology in college so I can understand the affinity the developers had for the term “Taxonomy” but, unfortunately, it probably made a lot of eyes gloss over one of the most important parts of Drupal. A core module, Taxonomy is essentially the ability to place “tags” on content (on the fly or pre-defined, your choice!). You can then link to the “tag” which displays all the content with the tag(s). If you are using Drupal you need to use this feature! Even for simple sites it is an easy way to organize data, e.g. lets say you do a sports blog. Create an NFL, NCAA, NBA, MLB, etc tags. You can then have links in your header primary-links or a block that directs to all this content. By simply adding a tag “NFL” or whatnot to your new content Drupal automatically organizes your content. Do a hierarchal tag system or multiple tag categories (League, Team, Player, etc) you now have a powerful content management system with minimal effort. We have used significant use of Taxonomy on our cooking website. It not only has allowed my wife to organize her 500+ recipes in the appropriate categories with no additional work on her part (!) it also has a significant benefit to SEO. We were delighted to see a number of tags showing up as the #1 search item on Google—all because Drupal is well formatted and the use of tags creates high concentrations of quality content.

Views. Organization and presentation are core to data drive sites. For this reason Views has been indispensable on my wife’s cooking block. The ability to create new blocks (e.g. 10 most recent recipes) or more complex filtering of recipe type tags to create customer pages has been a big help. While I still find things I cannot figure out how to do (how can I take the timestamp off of comments? I have had a tough time creating cascading pages where the first couple entries are large title+excerpt+picture, the next couple entries are title+excerpt, and the next handful are just titles) in general Views is as powerful as you need it to be for most uses. Oddly I bet someone can show me how Views can do the very things I have trouble with, which just goes to show that a little persistence pays off!

Userreview. We had some trouble getting this to Drupal 5, but it is worth it. This module allows registered users to review recipes (title, text review, and score between 1 and 10) and the reviews appear at the bottom of the associated recipe. Our users really enjoy this module and it is a great way to get your community active in your content. For recipes (and I would imagine any product) it is a great way to get additional feedback. We really hope this module makes it to Drupal 6! I cannot recommend it in its current state with no Drupal 6 branch and Drupal 5 support soon disappearing, but this is an excellent module.

Adsense. Technically you can insert your AdSense code into your template pages or custom blocks but this module does help ensure pages don’t have too many ads and can be used with other modules of tracking. We had been using the AdSense injector that allow you to insert ads at the bottom of posts (e.g. 3 small adds on the first 3 teasers on the home page, etc) but this module is no longer supported. I hear the Adsense module will be adopting this concept—I cannot wait!

Captcha. For a while there we dealt with a lot of spam comments that were really detrimental to the site—even when in the moderation que. With captcha were reduced spam easily by 90% while being able to allow non-registered users to post comments. Who knew computers were so bad at doing math!!

Themes and Blocks. Theming in Drupal makes a lot of sense. It doesn’t take much time to take a stock CSS theme (either your own or an open source theme) and convert it to Drupal. Drupal has “id” tags for almost every element of content so with a little CSS and HTML knowledge you can quickly change the look of a site. I have found the Drupal system very logical; e.g. in a CSS theme I would make a “primary links” area using unordered lists (pretty standard practice). To make this work with Drupal you insert your PHP code for “primary links” and you are done! Your theme is essentially full of “snippets” of code. The community also has a lot of solid layouts. Our current design used a community design as a starting point. The theme’s code was well organized so once we had our color scheme and “look” in Fireworks it was a matter of changing the basic site dimensions, a couple code changes, and then just changing out graphics and CSS styling to match our design choices. If you know CSS and HTML you can easily use Drupal themes. This is one of the best parts about Drupal. The use of dynamic blocks that can be changed from the administration panels is the icing on the cake—moving a piece of content has never been easier and requires no coding. Although you can code by inserting the code into a block, so how cool is that? The ability to disable block titles has been a big step forward into creating custom layouts that have a unique non-CMS look. Equally the ability to enable/disable blocks based on user roles is an excellent feature. Our site isn’t quite there yet (still quite square!) but with less than 10 hours of work into the new design it really shows how much flexibility Drupal offers for putting up a new look.

Panels. I was scratching around trying to find out how to manually “hook” a block in Drupal when Michelle kindly recommended Panels. We are just starting to use Panels, but it has been a “to do” list for a long time. Ours are rough right now because we plan to add a themed login menu and change the content in the panels but I must say this is a fun module as it allows a lot of new opportunities to present data without a lot of extra coding. You can go the route for a special homepage or use modules for custom layouts based on taxonomy, node type, etc but panels is quick and dirty. It is also easy to use. Right now we are using it to move some of the sidebar data on the homepage to a “dashboard” block just above the blog content. This makes the homepage more of a content portal which is helpful when you have a lot of content. This module could also be useful for multi-blog sites or websites with a lot of different categories (news sites?). Panels could also be used to prototype a layout idea before doing a specific theme.

Admin Menu. In the past we used the Control Panel module but after our Drupal 5 upgrade I have been using the Admin Menu. To my surprise my wife has as well—and she has found it much faster/easier to administer the website with this tool. This with the block editing tool allow users to cut through some of the layers and layers of features (which are great!) to get to the area they want to change quickly. Changing a view, updating a block, moderating comments, or creating a new page are very, very easy with this module. This should be a standard Drupal module imo.

Flags. With our site re-launch we wanted to have “Recipe Boxes” for users. Users tell us all the time how they use various methods to archive their favorite recipes (and frequently lose these!) Our solution was to use the Flags module to allow users to tag recipes and add them to their own “Recipe Box.” Next to recipe nodes can now be found an, “Add recipe to your recipe box” link. When selected the recipe is added to their own box and a view shows the contents of their personal box.

There are a lot of other great modules for Drupal (WebForm, XML Sitemap, pathauto, IMCE, etc). One of the more exciting “tools” for Drupal 5 users (standard in 6) is the Status Update Module that notifies sites concerning the status of their modules (are they up to date?) There are many great modules like this that work behind the scenes to make site administration better, some are cool widgets to hook users, and still others that can be used as central content presentation tool. The amount of developer activity dedicated to module development is jaw dropping. If you have an idea someone probably already has a module! And if they don’t maybe you can make your own with CCK? Some modules will give you problems (finding a good theming solution for the login block has been a pain! Or something as simple as removing the time stamp from comments) and you have to watch out for modules “burning out” but in general Drupal has an amazing array of great modules. Of course other uses have their own lists so you will want to check those out (e.g. http://drupal.org/node/121775 also check out http://drupal.org/project/usage and http://drupalmodules.com/top-rated).

The TammysRecipes.com Re-launch: Today, Tomorrow, and Beyond!

The recent re-launch of the website coordinated the upgrade to Drupal 5, the migration from Flexinode to CCK, and a new website design. The first stage has been to fix out problems (security and performance, discontinuing unsupported modules, etc) and getting a basic theme deployed that made better use of space and color coordinated better with the content of the website. We have moved to a “dash-board” style homepage. Thanks to block display properties we are able to display the mini-panels on the homepage only which allowed for a very quick and easy way to move frequently updated content blocks to the “dash-board” on the homepage. The goal was to highlight the cores of the website (Tammy’s posts, the social activity on the website, and the recipes) and the new layout, while rough, does a much better job of getting all the primary content visible without scrolling. It was unbelievably simple to achieve these changes through Drupal. The only thing that has given me fits is theming the login block. As time goes on we will be moving more relevant content to the mini-panels dashboard, but for now having new recipes, the most recent poll, and comments works. Eventually we would like to add recent recipe reviews and replace comments with content (forum and blog posts) most recently commented on.

One of the nice things about Drupal is that it is quite easy to add new features. Someone asked if we could add some “Link Back” code so they could copy and paste it to their website for a graphic “button” to advertise Tammy’s website. Enabling and customizing the Flags module took 30 minutes (!) and adding the Amazon 2.0 search box was just as easy to add. Without the AdSense Injector we are going to have to rethink our advertisements (I guess I could just edit the node.tpl and put an ad link at the bottom of nodes before the comments); we aren’t too keen on putting them in the header or creating a sub-header and don’t want to compromise content accessibility. There is a lot of clean-up to do with the new design so this will probably take a back seat for now.

As we work on Tammy’s new ebook we are looking to deploy a Slider to maximize space; finding a good compromise between technology (Flash versus Javascript) and integration (standalone or integrated into Drupal) has been a big internal debate. I am currently testing the Featured Slider; although it doesn’t have integrated audio, video, or advertising tools (like SlideShowPro or the like) the fact it works on Drupal 5 and is simple to update (create a new Drupal “featured” node!) are big pluses. I am working out the theming kinks right now, namely the node header and footer are present even with a custom node tpl. I guess for every cake walk (Flags Module for the Recipe Box, Panels for the dash board) module installation there are those that require you to roll your sleeves up and think outside the box.

The biggest change we hope to introduce to our site in the coming month or so is a forum. We have held off on using a bridge for a number of reasons and it looks like the Advanced Forums Module is finally at a point where I might give it a whirl. Admittedly I am concerned about the utilization of a half dozen non-core modules for such a central component of the website. My poor experience with trying to do something as simple as adding a private forum also remains vivid in my conscious. Ultimately, as we and our users want a forum, the choice has come down to a forum unconnected with the website, using a bridge, or using the default Drupal forums module. The last has won out in our minds. In the first scenario there is the issue of registration, block integration, and general cohesion and maintaining two distinct parts of the site (the CMS and Board). The bridge, while maintaining a common user pool, poses a number of technical issues and potential security nightmares. The last option allows for tight integration with the Drupal core, allows us to utilize our current users, content remains within the Drupal platform, and so forth. While the robust nature (features, moderation tools, layout functionality) of native BB scripts still lingers we feel Drupal has matured enough to use the internal tools. It looks like the Advanced Forums Module glues enough features together to make it worthy community tool and the tight Drupal integration is a positive. The fact it works on Drupal 6 and a Drupal 7 will soon be in development are quite positive signs!

Through the remainder of 2009 we have a couple more things we would like to try. We would like to do some more videos and trying integrating these more tightly into Drupal. Our current kitchen is quite small but users really enjoyed these. We are considering more user tools as the community is quite active. Reviews are a popular part of the website and I am tinkering with the idea of allowing users to upload pictures of their reviewed recipes and use the Images Module, Views, and a “slider” viewer so visitors can see the uploaded recipe pictures on their respective recipe nodes. The biggest item on the table is how we will distribute our ebook. It is looking to have about 300 recipes and be a substantial PDF. We are undecided whether to use Drupal modules for the shopping cart, referral tracking, payment gateway, etc and setting up an SSL certificate or using a dedicated ebook shop. A lot of this depends on how well the current configuration runs (does it continue to hang every couple weeks?) as we expect our traffic to see significant spikes. Ultimately it comes down to whatever is easiest and most efficient. Thankfully Drupal is robust enough to allow us multiple options, native and otherwise.

And that is a good summary of why we love Drupal. It is easy to use yet powerful. Equally important is that the Drupal platform is exceedingly robust but is also quite pliable in regards to working with non-Drupal tools. Drupal is very much about options and using the features and tools that meet your current needs and abilities. Drupal continues to meet our needs as well as having the vision and vigor to meet the demands of a growing and expanding social web. A number of CMS solutions may have been able to meet our specific needs but I am glad to say we decided on Drupal. The community is great and the tools are, in my humble opinion, second to none.

[Ps- Of course the first thing I am going to do tonight is fix the horizontal login which, as I discovered this morning, is broken! Doh! The site is very much a work in progress (: ]

Special Thanks.

While we have received a lot of assistance and guidance from the Drupal community a few notes of special thanks are in order. I BIG thanks goes to JirkaRybka and wmostrey for helping us resolve our MySQL 4.0 to 4.1 migration issues and developing documentation to address this issue (http://drupal.org/node/187689). Likewise Ron Williams from Ron’s Nexus (http://drupal.org/user/44026) for helping us migrate to Drupal 5 and updating the Userreview module and migrating our Recipe nodes from Flexinode to CCK. I would like to thanks Michelle for the number of times she lent support in IRC and how she always had a really positive, and helpful, attitude. The fact she is working on the Advanced Forums Module (http://drupal.org/project/advanced_forum) makes me feel very confident about its future. We are currently using a theme developed from the Addari theme from Worthapost (http://drupal.org/project/addari). The documentation in the CSS is excellent and the theme has worked flawlessly across all major current browsers. To each of you, and many others, thanks for helping us with our website.

Of course the entire Drupal team, as well as the community members making awesome modules and documentation, deserve a pat on the back for making Drupal an amazing platform for web content. Without your help our website would be but a shell (literally!) of what it is today. Our site has a long ways to go, but the fact Drupal has allowed my wife to create thousands of pages of content and interact with thousands of people is an amazing achievement and a testament to the usability and versatility of the tool.

The best thing I can say about Drupal is we look forward to the next 3 years of our Drupal Adventure!

Thanks Drupal!