Bleh! I hate with something like this happens. I'm happily working along and suddenly get something like this:
Uncaught exception thrown in shutdown function. PDOException: SQLSTATE[HY000]: General error: 2006 MySQL server has gone away in ...
If you go and search this class of error you'll find all sorts of advice. Some say start over because you're hopelessly beyond salvage. Other say you only need to raise memory limits in your my.cnf file.
Before you go do anything as drastic as messing with config parameters or resetting and starting over, try opening up phpMyAdmin and Optimize and/or Repair all tables in your database. The problem is very likely with only one table but you won't hurt anything doing this operation on the entire database. In fact it's a healthy thing to do from time to time anyway.
If you're not using git in all your projects, you should be. If you're using it then you already know how great a tool it is.
But even if you are using it you might not know or yet have found a few of the really awesome things git can do that don't immediately present themselves. What I mean is, you might be the kind of git user who does all their ordinary tasks at the command line - init, add, commit, merge, pull... - but who also falls back on a GUI client when the going gets rough.
Here's a simple little code snippet that might save you some time sometime.
I'm working on a new site that will largely be driven by a single custom module surrounded by any number of smaller dependent modules. Each of the children modules will have a set of menu callbacks, most of which are cut from the same cloth as all the other child modules. It only made sense to have the parent module set up the menu structure for each child, right?
So that's what I did. The only thing I needed was a way to pull together an array of the dependent, or child, modules. Drupal makes that fairly easy. Here's the code:
I had a recent inquiry about the event registration system I wrote for a client in Drupal. The inquirer wanted the code, but unfortunately I'm not able to release the code because of the license covering it.
What I was able to do however, was to outline the workflow process for the system. It's really very simple, and I think shouldn't be really difficult for anyone to replicate.
First and foremost the event registration workflow does not register anyone to the Drupal site. The client insisted that users do not need to register as users for the Drupal site. In truth, we are already collecting enough information during the sign-up process that we could create accounts. But that wasn't an objective. Maybe in a future enhancement? Time will tell.
So at a very high level the event registration process is as simple as this:
I wish I had a million dollars for every hour I've spent trying to track down little nagging problems I encounter in the process of developing custom modules for my Drupal clients. Truth is I'd settle for less. Truth is, just getting past some of them is reward enough. Today's was one of those.
I keep all my error logs for each of my development sites in a folder just off my dev server's document root. On my machine that's ~/mark/Sites/_logs. I keep it there so it's easy to find and check:
- periodically just to make sure nothing's awry
- when I'm having some kind of problem with the way a site is behaving
- just before deployment to production
This morning I checked it and found that the error.log for one of the sites I'm working on had grown fairly huge in too little time. I had only begun working on this site - really just laying out the framework for a new module - a few days before. Prior to that there was nothing in the error.log.