Category Archives: drupal

On this page:

Free Drupal-IBM-Acquia webinar: Integrating Drupal with Enterprise Back-office Systems – Thu Jan 21 2010 1PM EST

I coached developers on this project. =) It was pretty darn cool, what they did with Drupal, Websphere, DB2, and web services. Check it out!

Integrating Drupal with Enterprise Back-Office Systems to Deliver a Best of Breed e-Commerce Sites

Join Drupal experts from IBM Global Services as they detail the process of defining business requirements, selecting the appropriate technologies, overcoming the technical enterprise integration challenges, and ultimately launching best of breed e-commerce sites with Drupal.

Key takeaways will include:
A review of the key business and technology decision criteria for selecting Drupal and Acquia
An example of a 3 tiered architecture designed to deliver end-end automation and a flexible platform for future innovation
Tips on how to integrate front-end and back-end systems including Drupal, Websphere, DB2, and ERP system for launching a best of breed e- commerce solution.
A discussion of which Drupal modules and Acquia services are recommended.
Best practices and technologies for building a development and test environment to optimize parallel development and ensure security

This Webinar is designed for those who want to learn more about best practices for designing an enterprise architecture with Drupal at the core and integrating Drupal with other enterprise systems.

http://acquia.com/resources/webinars/integrating-drupal-enterprise-back-office-systems-deliver-best-breed-e-commerce-s

Enjoy!

(Update: Thanks for catching that!)

Drupal workflow for small projects

One of the recent hires dropped by with a few questions about Drupal development in small projects. She wanted to know if it was worth having another person do the HTML and CSS theming if that person didn’t know PHP or Drupal, and what the workflow might look like.

As a Drupal developer who really hates working with cross-browser fiddliness, I think it’s almost always a good idea to have someone else do the HTML and CSS theming. In an ideal world, that person would also create the Drupal theme and whatever Javascript behaviors are desired, but it seems hard to find people who are comfortable with both front-end and back-end development. A reasonable compromise is to have someone else translate the visual design into cross-browser HTML and CSS for the splash page, an inside page (anything representative of the main layout), and other layouts. What takes me four hours of teeth-gnashing may take an experienced designer just one, and he or she might even be happier doing it. So go ahead and optimize for developer productivity and happiness.

Another benefit of splitting up the work is that you can work in parallel. While you work on the technical bones of the application, the designer can get the theme just right. The earlier in the project that you know about complex parts that could be problematic, the better, and this is true for both theme and function. You’ll still need to integrate the theme at the end, so budget at least a few days for that.

So here’s what the workflow might look like:

  1. Developer installs modules and configures them to work together.
    Designer prepares basic HTML and CSS.
  2. Developer fleshes out site and adds custom functionality.
    Designer fleshes out individual forms/pages requiring special treatment.
  3. Developer ports HTML and CSS theme to Drupal.
  4. Developer and designer collaborate on fixing any cross-browser problems that show up.

Build the functional parts of the application before worrying about the theme. Problems in the theme layer can mask problems in the functional layer. If you build the theme first, then build the features, tracking down bugs might take more time.

It’s usually a good idea to build the hard parts first, so you can get a better sense of how much more effort is needed and whether you need to scale things down. If you’re new to Drupal, you may want to build a few easy parts first so that you can familiarize yourself with the system.

Hope that helps!

IBM Drupal Drop-in Clinic

I love this! I’m practically running an IBM Drupal drop-in clinic at 120 Bloor E, helping five developers on two projects become that much more productive. They’re all working with Drupal 6, but my experience with developing and debugging on Drupal 5 is still helpful, and I can navigate through Internet posts pretty quickly too. I get to help with the tough and interesting bits without needing to set up my environment or work on the boring bits. ;)

This is definitely worth the subway ride. I create more than CAD $4.50 of value and save people more than 60 minutes of time total. Besides, I usually get to sit down and write a blog post during the commute.

Some things from today:

  • Want to protect files from being downloaded? Set your Drupal file system handling to Private, manage your view uploaded files permission, and don’t forget to add an .htaccess in your files directory with the following:
    SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006

    Options None

    Options +FollowSymLinks

  • Use hook_form_alter to print out the form_id if you want to change where a form redirects. After you figure out the form_id, set the appropriate form’s #redirect property.
  • var_dump may look different if you don’t have xdebug installed. Check the HTML source for your expected output.

Lots of other HTML- and Drupal-related things, too.

Good leverage on time and experience. =D I wonder how to get even better at this…

Lessons learned from this phase of our Drupal project

I learned a lot from another three months doing Drupal. Here’s a summary:

  • I learned how to write low-level design documentation. I used to hate doing this because I was much happier prototyping things in order to figure things out, and writing in a word processor instead of a code editor seemed slow. Also, laying out images was a pain in both OpenOffice.org and Microsoft Word. The key breakthrough was that after a lot of iterations, I finally got to a document that had the level of detail my project manager wanted. Once I knew what he wanted, it was easy to write documents like that. In fact, I did one better–I filled in lots of details in the validation section of the design document, and I used that for test-driven development.
  • I smoothed out more of the kinks in our deployment process. Always testing our update scripts with update.php’s access check set to false helped flush out assumptions about user ID. Our regression tests came in handy, too.
  • I practiced more test-driven development. And I loved it! =) Yay yay yay yay.
  • I learned JQuery and the ins and outs of Views+Calendar. We customized our calendar implementation extensively, and it doesn’t look half-bad. Working with timezones had given me a lot of pain, though, but I managed to address all of those issues (and I have the regression tests to prove it! ;) ).
  • I learned that I should’ve gotten a second computer a long time ago. Having a dedicated development computer and another computer I can leave on Microsoft Windows means less hassle and less stress when it comes to working with other Windows-centric people and tools.
  • I learned that I have a lot of things I can teach people about Drupal. =) Mentoring is fun!

I’m moving to strategy-focused projects next quarter, but if I were to continue on this project, I’d probably:

  • Learn more about optimization (started doing a little bit of this, speeding up a page by an order of magnitude)
  • Write more validation tests in my design documents
  • Figure out how to check that coding standards are consistently applied ;)
  • Find some way to convince folks to go for Drupal 6, or find another project that uses Drupal 6.

Drupal in the trenches: MySQL and DELETE joins; multiple tests

Today was the first time I used a DELETE statement that joined multiple tables. I didn’t even know you could do that. =)

I needed to look into this because my update function was just taking so much time and memory. We have a little over 3,000 nodes, most of which are usernodes automatically created by the usernode module. I needed to rebuild the node access entries for a few hundred content nodes to take into account the new partner access module I wrote, but node_access_rebuild took quite a while.

The first approach I thought of taking was to delete usernode because we didn’t seem to need it any more. In order to do that, though, I would still have to delete all the user nodes, though, and invoking all the hooks for each of the 2000+ user nodes took a while as well.

The second approach was to delete just the node access records related to the nodes I needed to update. I found a way to do it even faster – instead of querying the node IDs and then deleting individual rows, I could do something like this instead:

db_query("DELETE FROM na USING {node} n
          INNER JOIN {node_access} na ON (n.nid=na.nid) WHERE n.type='%s'", $type);
$rs = db_query("SELECT nid FROM {node} WHERE type='%s'", $type);
while ($row = db_fetch_array($rs)) {
  $node = node_load($row['nid'], NULL, TRUE);
  if (!empty($node)) {
    node_access_acquire_grants($node);
  }
}

(UPDATE: Fixed MySQL statement)

That was interesting. =)

I was also running into memory problems trying to run all the unit tests in one go. I broke it into individual tests with:

drush test list | grep KEYWORD | xargs -n 1 drush test run | tee out

where KEYWORD is the keyword I use to filter the list for just the tests I wanted to run, and out is the file that stores a copy of the results. It’s not neatly summarized, but oh well. =) It works.

Drupal from the trenches: This is my game

I’ve been coaching a senior architect on a Drupal site he’s developing on a tight schedule. With a little bit of help, he was able to build all the functionality needed and keep up with constantly changing requirements. Now it was time to theme the site. As I was walking through how to modify the Zen theme to use the HTML, CSS, and images that he received from the designer, flipping between Vim editors in two Putty sessions connected to the web server, I saw his eyes start to glaze over. Hmm. He was definitely interested in learning how to do it, but I knew he’d enjoy learning it more if he had most of the framework already in place.

I offered to get things started. The senior architect asked me how much time I thought it would take. “Two hours,” I said, which was the first number that came to mind.

After lunch, I headed to the senior architect’s desk with my laptop and wireless mouse. I thought about asking him to change his password to something I could easily type, just in case I needed to start multiple sessions. Then I realized a much better way to do it would be to use my Emacs environment, which is already set up for doing really cool things with Drupal. So I switched my keyboard layout to QWERTY, used ssh-copy-id to copy my authentication ID to the server, and then opened the directory in Emacs using the location /ssh:user@host:/usr/share/drupal6.

Emacs worked like a charm. I edited files on the server as easily as those on my own computer, with all the syntax highlighting and keyboard shortcuts I’d gotten used to. I split windows, moved windows around, copied and pasted regions, and even did a little autocompleting.

I think I made the senior architect’s jaw drop.

I finished almost all the basic theming (minus a few quirky CSS things) in one hour and fifty minutes, ten minutes less than my thumb-in-the-air estimate. The senior architect said it would’ve probably taken him 16 hours over the weekend.

While we were chatting about the changes he’d need to make and the other things he could learn, the senior architect asked me if I played any games. I told him that I play one computer game–Nethack (an old text-based roleplaying game)–and I only play it in airports. I pointed to my laptop and said, “This is my game.” Programming has its own major challenges and minor opponents, it has progress, it has points, it has that adrenaline rush of trial and triumph. Programming is my game. Life is my game.

And it’s tons of fun. =)