Sometimes Drupal makes me bang my head on the desk. It can perform all these incredibly complex tasks and support countless technologies but occasionally it's the simple problem that flumuxes it. For a long time I've been banging my head against just such a problem: lets say I want to create a list of content containing different types of content each with an image.
Sometimes you have to do a whole lot of stuff during an update. Sure you could just write a standard hook_update_n() function and try processing 50,000 nodes but if you do you're almost guaranteed to run out of memory or timeout or generally make your web servers unhappy. Luckily you can use Drupal's batch API within your update hook.
It's well known that websites have traffic patterns and that there are those times of the day/week/month/year were traffic predictably increases or decreases. Just like the 405 in LA, or the LIE in New York, or the 75/85 connector in Atlanta, traffic is likely to be pretty light at 2:00am on a Sunday, but travel those same roads 30 hours later and, well, bring a book...
So you've jumped on the responsive design bandwagon? Good for you. You've spent weeks coming up with an awesome content strategy for your site and you've spent countless iterations perfecting your users' experience across devices with different screen sizes and less-than-awesome download speeds. You've even taken ambient light into consideration (who knew?).
By now we have all (hopefully) heard the Drupal mantra "Don't hack core!" Usually this statement is followed by a quip about killing kittens and then a long (and necessary) diatribe about how hacking core makes it more difficult to maintain your site; leads to unexpected behaviors; and makes debugging issues ...um... adventurous. These things are all true. Very, very true.
On nearly every site I have ever worked on there has been one or two settings that I wanted set differently on dev as compared to prod. Of course I could just set the settings locally, however every time I would bring the production database down those settings would be overridden. For example I always want to have the devel module enabled locallay to —ya know— help me devel, but I amost never want it enabled on production. To solve this problem I've written a simple Drush command called "environmnet." Here's how it works…
I used to apply patches from drupal.org by goeing to the issue page where the patch has been posted, downloading the patch to my desktop (or wherever) and then applying it using git apply /path/to/file.patch. Today I figured out a better way.
Open your favorite terminal application <cough>iterm2</cough> and cd to the git repository to which you want to apply the patch. Then type
What do Google's Doubleclick for Publishers (aka DFP) and Drupal have in common? They each have a zillion different ways to set things up. Read on to see a walkthrough of how you might configure everything to get your display ads going using the DFP module.
Contextual links are a great new feature of Drupal 7. Basically, links are added to various elements of the page to make it easy for site editers to make changes to whatever content they currently see.
It turns out that the Update module that comes with Drupal runs some pretty hefty queries. While trying to debug a crazy mysql error we were seeing on one of the sites I work on (http://drupal.org/node/361563) it occured to me that there is no reason why we should have the update module enabled on our production site at all.
Turning it off on production (while leaving it on on staging) gave the site a nice litte pick-me-up especially after clearing the cache.