Stop MySQL giving up on Drupal


With Drupal, if you have a content type with lots of records you can run into a problem where you start getting lots of "server has gone away" errors from MySQL. This stems from queries getting too long and MySQL giving up before the query has finished loading. So, to fix it, just edit your my.ini or my.cnf file to add the following line to the [mysqld] section:

  • max_allowed_packet=24M

There are other settings that can make a difference too, but this seems to be a good starting point.

One solution for "unexpected T_SR" errors in PHP


Here's a little tidbit. If you ever get "Parse error: syntax error, unexpected T_SR" errors in PHP, check to see if you had any svn merge conflicts. This error raised its ugle head this evening for me and that's exactly what it turned out to be. Then just bounce over to your svn client of choice, fix the conflict (or just delete the offending files and grab the latest file again), and the error will disappear.

Drupal imagecache setup on OSX


As mentioned before, PHP is misconfigured on OSX and you don't get their customized sourcecode in order to recompile it with the options you need. As such you can't run the GD plugin which is what most OSS programs use for image processing, and is generally the most recommended way of doing it. For Drupal's ImageCache / ImageAPI module(s) what you can do instead is install the ImageMagick package and then just tell Drupal to use the ImageAPI-ImageMagick module instead of the GD one. I've already got ImageMagick installed on my McBook for Rails use so it was only a few seconds to get it going for Drupal too.

Key Drupal 5 concept - boxes are not automatic


A key feature in Drupal is being able to create plugins/modules that create their own blocks, chunks of functionality that can be placed anywhere on the page by using the blocks/regions configuration or panels. If you do happen to create your own, bear in mind that while you automatically gain the features of the mail blocks table, you do not gain access to the boxes table, so you have to create your own body content block. Just thought you should know. And yes, this fact has just dawned on me. Doh.

Why does PHP still suck on OSX?


I'm a little puzzled and frustrated with Apple.

With Macs, or more specifically OSX, becoming the platform of choice for web developers world over, why do they still insist in neutering our capabilities by bundling limited versions of the most common web development tools rather than all or nothing? With Leopard they at least improved the Ruby install to the point it was useful (you could actually now run Rails without having to compile from source) but PHP is missing so much functionality through the lack of pear and shared libraries to make it a pain to use.

On Linux it's almost standard practice to compile PHP from source, because so few installations include all of the required libraries (due to varied quantities of "suck"). Amusingly on Windows you can obtain all of the libraries out of the box and just enable the ones needed. Contrast this to OSX, which promotes itself as being so much better than Windows, and you get the worst of both worlds - no source to compile and an incomplete binary install.

Even if they insist in bundling their own customized build with the OS, the least they could do is make all of their customized source builds available through MacForge, which would allow those of us who need more than the basics to at least keep our recompilations matched to Apple's standards.

Come on Apple, do the right thing!


Subscribe to PHP