A little more on Drupal vs WordPress

Here’s a link to an interesting question on Quora about WordPress vs Drupal that got a thoughtful answer from Dries Buytaert, the guy who created Drupal. A number of the other answers are pretty interesting too. It’s actually an older question, but it rose to the top of my Quora feed today, for some reason. Quora is sometimes very good at surfacing useful answers to questions, and avoiding the flame wars and trolling that would normally clutter up any “X vs Y” discussion on the internet.

And, hey, here’s an article on migrating from Drupal to WordPress. I’m curious as to why anyone would want to do that though. If you already had a site up & running in Drupal, what would you get by migrating to WordPress? I could see cases where you’d want to go in the other direction, since Drupal has some functionality that doesn’t exist in (base) WordPress. I guess I could think of a few cases where you’d want to go from Drupal to WordPress, if you were dealing with a simple site and didn’t need all the overhead of Drupal, and/or wanted the WP admin interface, which (for some things) is nicer looking & friendlier than Drupal’s.

from Drupal to WordPress

As a guy with a good bit of Drupal experience, and a limited amount of WordPress experience, I’ve thought about writing up a little comparison & contrast essay for my blog. I just found this post from a guy who has a lot of Drupal experience, and is just getting into WordPress. I agree with most of what he’s saying here, and have definitely noticed some of the same stuff that he has. So now I guess I don’t have to write up that comparison/contrast post!

One note though: since I started using WordPress, I’ve been keeping an eye out for something similar to drush, the command-line tool for Drupal. Well, I stumbled across it today: WP-CLI. I’m not sure if it does quite as much as drush, and I’m also not sure if I’ll be able to get it working on my web host, but it looks useful.

Google+ surprise

So I got a little surprise today when I got a notification on my phone that someone had commented on my Google+ post. Now, I haven’t even *looked* at Google+ in months, so I wasn’t sure what had happened there. It turns out that Google has been helpfully sending all these blog posts to Google+. I’m sure I must have clicked “OK” on a dialog that popped up on the Blogger site at some point to allow that, but I’ll be darned if I can remember doing so.

It doesn’t really bother me that this is happening, but it’s one more little thing that makes me revisit the idea of moving this blog to Drupal or WordPress, hosted on my 1&1 account, and administered entirely by me. I have quite a few posts on this blog, so I would of course want to import them to any new blog, and there’s the rub. Some time ago, I tried to import everything to a new Drupal site, using this importer. To make a long story short, it didn’t work. (That may not have been entirely the fault of the importer; it might have been something with my local MySQL and/or PHP setup.) But now I’m thinking, more and more, that I don’t want to trust Google too much. With the direction they’ve been going in lately, I could see them, at some point, trying to fold Blogger into Google+, and I *really* don’t want that!

Drupal Rules

I haven’t blogged in a bit, and I have a few random items I want to write up. I’m doing a lot of work with Drupal, and I’m still learning some little tricks here and there.

When I’m writing custom code, I often use Drupal’s cache. That’s pretty easy to do, with cache_set and cache_get. I recently found myself in a situation, though, where I wanted to clear a certain item from cache any time a user created or edited a node of a certain type.

It turns out to be really easy to do that with the Rules module. Just set up a rule that is triggered on insert or update of a certain node type, and make the action a simple line of PHP code:

cache_clear_all(‘your_cache_key’, ‘cache’);

Easy!

my first Drupal module

Here’s my second blog post for today. (Still sitting around at home, watching storm coverage.)

I recently read an article on CNET about how companies are increasingly looking at sites like GitHub when they’re looking at potential hires, to see actual code, rather than just going on what people say about themselves on, say, LinkedIn. I think the article exaggerates a bit, and maybe overgeneralizes. There are plenty of great programmers working in environments where they’re not likely to be posting any code on GitHub. I have been thinking lately, though, that it would be good if I had some open-source code out there for people to look at. My boss recently wanted me to write a Drupal module that would allow people to embed our store locator in a Drupal site. I recently finished writing the initial version of that module, and posted it as a sandbox project at drupal.org. You can find it here.

Because Drupal itself is open-source, and because PHP is interpreted, you really have to expose your code if you’re writing a Drupal module. So, as a beneficial side-effect, I now have some code out there that I could point someone to, if I needed to show a code sample to anyone. Mind you, I’m not actively looking for a new job, but it’s good to have something out there.

Given the kind of work that I normally do, it’s not that common that I work on any code that (a) I can post openly, (b) isn’t part of a “group effort” that multiple people have worked on, (c) is (somewhat) self-contained, and (d) is non-trivial. I think a lot of developers are likely in this category. It’s a good idea to keep an eye out for opportunities to work on occasional projects that fit these criteria, and can be posted publicly to GitHub or similar sites.

I’d like to do a couple of blog posts later highlighting some of the stuff I learned while writing this module. While Drupal is reasonably well-documented (for an open source project), there are a fair number of “dark corners” that are hard to get a handle on, and which I could possibly write some useful posts on.

Stumbling my way through the Drupal API

I’ve had to fix some interesting problems at work recently, related to a Drupal site that we’ll be rolling out soon. I just finished fixing one issue that, while seemingly minor, took quite a while to figure out.

I’m really glad to have come up with a good solution. The thing that amuses me most about this is that, after more than eight hours of messing around, the final solution involved writing only about a half-dozen lines of code.

The problem, in a nutshell, is that we have a content type in the system that represents a university. There’s a location field on each node with, minimally, city and country specified. The user can search for locations, using some custom search code, and the search results are displayed via a standard Drupal view. We allow the user to sort the results by one of a few different fields, with the sort drop-down exposed from the view. This works fine, except when sorting by country. On the location record, only the two-letter country code is stored, for instance “AE” for “United Arab Emirates”. So, when you sort by country, it’s really sorting on country code, so “AE” goes to the top, which isn’t really what the client wanted.

Of course, the first thing I did was Google the problem. I found this issue discussion, which pretty much matches my problem. There was a suggestion in the comments there about using hook_views_pre_render to re-sort the results right before displaying them. That works great, if you’re not paging results. But, if you’re pulling results back one page at a time from a large result set, this doesn’t work, since the pre-render hook only gives you the current page.

So I figured out that I really need to sort by country name at the SQL level, while retrieving results. This led to my next problem, which is that, even with the location module installed, there’s no SQL country lookup table in Drupal. The list of country codes and names is just stored in code, in an array, which can be retrieved via _country_get_predefined_list. (You shouldn’t call that directly, though, of course; you should use country_get_list.)

So off I went to find a module that could give me a SQL table with country info in it. The countries module does that, and a bit more. So, I installed that and figured out where the country table was. Then, my next blind alley was figuring out how to join to the new country table in a view. I was hoping I could just add a join to it in the view definition, and go from there. Well, I still don’t know that much about Drupal views, and it didn’t seem possible to do that easily.

So, the next blind alley was to see if I could alter the view SQL with hook_views_query_alter, which seemed sensible. Well, the query object that you get from that hook isn’t a nice simple query object that can easily be changed, so that turned out to be another dead end. (It’s likely possible that I could have figured it out, but it seemed like the wrong approach.)

Then, finally, I stumbled across this SO question. The one answer posted there led me in the direction of modifying the query with hook_query_alter, which can be used to modify just about any query Drupal issues to MySQL. So, finally, I found a workable solution.

hasAllTags('views', 'views_university_search')) {
    $ord =& $query->getOrderBy();
    if (array_key_exists('location_country', $ord)) {
      $query->addJoin('INNER', 'countries_country', 'cc', 'cc.iso2 = location.country');
      $ord = array('cc.name' => $ord['location_country']);
    }
  }
}

So that’s it. I add a join, and replace the ‘order by’ clause. About a half-dozen lines of code. Oh, and I now also understand passing by reference in PHP a little better too!

NYC Drupal Camp

I went to the NYC Drupal Camp at Columbia this weekend. I only made it out on Saturday, but I would have liked to have gone today also, if I didn’t have other things to take care of.

The sessions I went to were all great (which isn’t always the case at free “code camp” events like this). The first session I attended was on node access, by Ken Rickard. It was a well-presented talk on a fairly dry subject. I’m not sure I’ll have cause to use much of the information in the talk any time soon, but it’s good to know.

The next was on using SQL within Drupal, by David Diers. His slides are here. This was a pretty basic talk, and I already knew the basics of both db_query and db_select, but I didn’t know some of the specifics, so the talk was useful and applicable to the kind of stuff I’m working on.

The next talk was on the Migrate module, given by Ashok Modi. He has his slides up here and a blog post covering similar ground here. This one would have been a great help to me a few months back, when I was trying to figure out how to import a lot of data into a Drupal site we’re working on at EVI. After this talk, I realize I did it the hard way!

After lunch, I went to a session on caching. Their presentation is available on Github. I’m not too familiar with Drupal’s caching, or Apache’s, or with third-party accelerators, so this was all good stuff for me. I’m curious about Varnish now, and I may follow up on that.

After that, I attended a session on Drupal Commerce, given by Richard Jones. I’m probably going to use Drupal Commerce on an upcoming project, so it was good to get a little more info on it.

Finally, I went to a session on hacking Drupal by Ben Jeavons. Very informative. It looks like XSS attacks are the most common problem for Drupal sites. He talked about using the Vuln module to identify problems, which sounded pretty good, but it looks like that module hasn’t been updated for Drupal 7. His slide on handling strings safely was useful; I might need to print it out and keep it handy. I need to remember those functions — check_plain(), check_url(), check_markup(), and filter_xss().

So, overall, a good day. I wish I could have gone back for more today. The main purpose in writing this blog post, by the way, was to get some of this stuff out of my head, in the hope that writing it up will help me retain some of the information. When I go to one of these things, and sit through a half-dozen 45 minute presentations in one day, it’s easy for the information to fade quickly. I’m hoping that writing this stuff up will help me remember.

Drush on Windows and Mac

Yes, this is another post about Drupal. I just feel like I need to write some of this stuff down as I figure it out, for my own reference if nothing else. I recently got Drush working on both my work PC and my Mac.

Surprisingly, it was a lot easier to get working under Windows than under Mac OS X. The Windows setup is mostly accomplished by just running this installer. The main MSI file up on the site right now is dated 6/4/12, so it’s up to date. The only thing I changed was to edit the path settings post-install to put my existing copy of PHP in my path, so Drush could find it.

On the Mac, I wanted to follow the recommendation on the main Drush page to do the install via Pear. I did not have Pear set up on my Mac, though, so I needed to figure that out first. That’s not hard to do under 10.7, as described in this blog post. I then had a couple of permission problems to work through, but after taking care of those, I seem to have a working Drush install.

I also needed to do a little follow-up work to add /usr/local/mysql/bin to my path, to get archive-dump to work. I’m not sure why I hadn’t added that to my path when I installed MySQL back in December. (I was amused, by the way, to see that the last edit to my .bash_profile was from back in 2005. Apparently, I was trying to get gpg working. Also, apparently, .bash_profile gets pulled along when you migrate to a new Mac, since my current MacBook isn’t quite that old.)

I intend to write a post soon on how I’m running a PHP script under Drush to import data into Drupal, but i don’t think I’m going to write that up today.

Drupal 7 Development

I’m continuing my somewhat slow attempt to become a Drupal expert. After finishing up a couple of general Drupal books from Packt, I started “Drupal 7 Module Development,” also from Packt. I got up to chapter four, then put it down in frustration. I’ll likely pick it up again, but it’s not an easy book to read straight through, with little prior Drupal dev experience.

So, then I picked up “Pro Drupal 7 for Windows Developers,” and I’m doing much better with that one. I just finished chapter 5, which walks you through the creation of a simple, but non-trivial, module. I found it fairly easy to follow, and a good start. The book is (obviously) written for Windows programmers looking to learn Drupal, specifically ASP.NET developers, so it’s a good fit for me.

There’s still a lot more to learn. Drupal’s API and hook system are fairly complex and extensive. But I think I’m on the right path.