Blogs

Below is a video and some notes from my presentation "Giving Back - Helping with Drupal's Issue Queues", which I gave to the St. Louis Drupal group at the April 17 meetup. Please post any feedback or additional resources/suggestions in the comments below or on YouTube.

• Note: This presentation roughly coincides with the Drupal Ladder lesson, Getting started in the issue queue.

• We’ll look at three different ways you can help contribute to Drupal’s success in the issue queues.

• Cleaning up an issue queue, testing and reviewing a patch, and writing your own patch.

Clean up an issue queue

Reference: Helping maintainers in the issue queue

Recently, I upgraded one of my CentOS and Ubuntu servers to a new version of Munin 2.0.x, and started getting an error stating that munin-update.lock already exists:

Munin hadn't been updating for a couple weeks, so I finally deleted the existing munin-update.lock file, and munin started running again. If this doesn't help solve your problem, have a look inside the various munin log files in /var/log/munin/ to see if one of them contains more details as to why munin isn't working for you.

Also, for some reason, munin 2.x isn't working for me on CentOS 5.x, at least on servers where IPv6 is enabled, unless I manually edit one of the main munin config files. I've opened this bug in the munin issue tracker to see if it will be resolved. The errors I get look like the following, inside /var/log/munin/munin-update.log:

Edit: There's a module for that™ now: Pingdom RUM. The information below is for historical context only. Use the module instead, since it makes this a heck of a lot simpler.

Pingdom just announced that their Real User Monitoring service is now available for all Pingdom accounts—including monitoring on one site for free accounts!

This is a great opportunity for you to start making page-specific measurements of page load performance on your Drupal site.

To get started, log into your Pingdom account (or create one, if you don't have one already), then click on the "RUM" tab. Add a site for Real User Monitoring, and then Pingdom will give you a <script> tag, which you then need to insert into the markup on your Drupal site's pages.

The easiest way to do this is to use drupal_add_html_head() within the page_alter hook (in your theme's template.php, or in a custom module):

I registered isthereamoduleforthat.com on 2010-08-19 for fun—but after three years, and little traffic (besides bots and the occasional Drupal user popping over from an old link), I'm shutting down the site, and will let my domain registration expire.

If someone is interested in the domain, let me know how you'd use it in the comments below, and I'll consider transferring it to you instead of letting it expire and a squatter taking over.

DrupalCon Portland is only a couple months away (early bird registration ends soon, so get your tickets if you haven't already!), and I'll be headed out that way. If this will be your first time attending a DrupalCon, be sure to read my First Timer's Guide to DrupalCon from last year.

At this year's DrupalCon, I'm excited to hear about everything going on with Drupal 8, as we're nearing the end of the development cycle, and a release candidate is on the not-too-distant horizon.

After having a baby and shying away from much Drupal contrib/core work, I finally had some time in the past few weeks to get up to speed on many of the Drupal changes that have been committed in the past month or so—and boy are they amazing (CKEditor in core, new node edit form, new responsive layouts, new admin toolbar, config, views, etc.)!

In addition, since the feature freeze deadline has passed, I decided to try porting Honeypot (a popular spam bot-fighting module) to Drupal 8. So far, most everything works, but I'm still working on making sure new configuration changes are accounted for.

PHP's command line interface doesn't respect the max_execution_time limit within your php.ini settings. This can be both a blessing and a curse (but more often the latter). There are some drush scripts that I run concurrently for batch operations that I want to make sure don't run away from me, because they perform database operations and network calls, and can sometimes slow down and block other operations.

Can you tell when the batch got backlogged? CPU usage spiked to 20, and threads went from 100 to 400.

I found that some large batch operations (where there are hundreds of thousands of items to work on) would hold the server hostage and cause a major slowdown, and when I went to the command line and ran:

I found that the execution time was set to 0. Looking in PHP's Docs for max_execution_time, I found that this is by design: