After upgrading a site with complex CCK node types, I ran into this error on the node type’s manage fields page:

This content type has inactive fields. Inactive fields are not included in lists of available fields until their modules are enabled.

It went on to list every Computed Field and FeedField I was using as inactive, even though those two modules were enabled and all updates had been run.  Googling the problem found lots of people who have run into the error.  The suggested solutions vary wildly in their complexity.

I decided to try disabling and re-enabling the modules responsible for the inactive fields.  Re-enabling the CCK related modules fixed the issue.

Some people are seeing the same error for non-CCK modules and/or re-enabling the CCK modules didn’t fix their problem.  This d.o comment links to a bunch of solutions.

I’m not a programmer so I’m especially happy when I can contribute to Drupal meaningfully.

I submitted a patch today to add caching to the Whois module.

http://drupal.org/node/698850

My first taste of Drupal was the 4.6 version in 2006.  I very clearly remember running into the flexinode module and thinking “OMG, custom content types!  Woo! That’s exactly what I want in a CMS!”  Haven’t looked back since.

Below are the slides that Dries used to present the State of Drupal at Drupalcon ‘09.  Yeah, it’s from 5 months ago, but I just ran into it and it was entertaining, so I’m sharing it here.

If you’d rather read about the State of Drupal, here’s a writeup from Lullabot of Dries’ talk.

Watching the slideshow is entertaining, even without sound or the actual text for reference.  It very clearly shows the rapid evolution of Drupal and the Drupal community.

I’ve worked in IT for nearly 10 years now.  First as a help desk operator, then a Linux sysadmin, and now a Drupal developer/webmaster.   In that time, I’ve run into a handful of really perplexing problems.  ”Perplexing” meaning after hours (usually, days) of troubleshooting, I can’t figure out why the system is suddenly unstable.

You know those type of problems, right?

The kind that’s so perplexing that you’re sure it’s gotta be a hardware problem, even though your years of admin experience tells you it’s almost never (like 99.999% of the time) a hardware issue.  But you’ve looked at (seemingly) all the possible software causes.

I was just reminded of this recently, and I’m here to remind you:  It’s never a hardware problem.  It’s always a software problem.

PS: If you’re looking for VPS or dedicated server hosting, Rimu Hosting is a great choice.  When they say they have “professional technical support with a personal touch”, they mean it.  Rimu has by far the best support team of the half-dozen hosting companies I’ve worked with. And great support is the only differentiator that matters when choosing a hosting vendor.

I took my sysadmin friend Marc to DrupalCampLA 2009 this past weekend. When we get together, I go on and on about Drupal and he waxes on about Django.

I think he got the sense of why I tell everyone I know to use Drupal for their web projects. Especially after sitting in on Rain Breaw’s (awesome name btw) great Views Demystified session . Wow, point and click content slicing and dicing?! Awesome.

I wonder if he’s going to make me learn Django. Uh oh.

I’m going to DrupalCampLA 2009.  It’s at UC Irvine this weekend (in less than 8 hours actually).

I’m excited about learning new tricks, asking questions, and meeting other Drupalers face to face. It’s my first Drupal live meetup.

It’s also my first barcamp.  Being able to vote on sessions and have them be rearranged on the schedule based on demand is very neat.  Even if you do have to play tag with the schedule as your chosen sessions are moved around and conflict.  I wonder if the schedule will shift again.

Sessions I definitely want to go to:

• Views Demystified (super 2 hr session). I sense there’s a lot of power I’m missing out on.
• Services module. Gotta have your own APIs.
• Theming with Views. I totally understand why this is the most popular session.
• Functional Interaction Design. Usability/design is so important but I suck at it.   It can always be easier.

There a good mix of beginner, intermediate and advanced sessions.  It’s a good opportunity to introduce someone to Drupal.

Some essential links for the weekend:

• Schedule
• Getting there
• Parking ($8 at structure at Peltason Dr. and Anteater Dr.)
• Venue map and info (rooms spread across a couple of buildings around the Engineering quad)
• Where to eat and drink

If you’re upgrading from Drupal 5.x to 6.x, and you’re using the Block Cache module, be sure to drop the cache_block table prior to upgrading.

Update.php fails to create the cache_block table if it already exists from the 5.x install of the Block Cache module.  Turns out there’s a patch for update.php created by chx way back in ‘07, but it never made it in.

I ran into this issue upgrading our internal forums from 5 to 6. Hopefully, you catch this before running update.php, but if you didn’t here’s a fix.

There’s no uninstall option for Block Cache, so unfortunately, you’ll have to get under the hood whether or not you anticipate this upgrade problem.

Not Yet Upgraded

If you haven’t run update.php yet, you can save yourself some hassle by dropping the cache_block table first.

Use phpmyadmin or ssh+mysql to do it.

DROP TABLE IF EXISTS `cache_block`;

Already Boned

If you already upgraded and got the “failed to create table error”, like I did, then you’ll need to manually drop and create the table.  It gets a little complicated because there isn’t a schema to just copy and paste anymore (Drupal moved away from that in 6).

Option #1 – ssh+mysql

If you have direct mysql access, here’s the cache_block table’s schema.

DROP TABLE IF EXISTS `cache_block`;
CREATE TABLE `cache_block` (
  `cid` varchar(255) NOT NULL default '',
  `data` longblob,
  `expire` int(11) NOT NULL default '0',
  `created` int(11) NOT NULL default '0',
  `headers` text,
  `serialized` smallint(6) NOT NULL default '0',
  PRIMARY KEY  (`cid`),
  KEY `expire` (`expire`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

(I think you can drop and create the table using phpmyadmin too, but I’m not sure since I haven’t used it in ages.)

Option #2 – use the Devel module

Install the Devel module and enable the Development block.  Click on Execute PHP Code in the block (or go directly to /devel/php).  Paste the php code below into the box and execute it.

This is the code that sets the cache_block table’s schema and creates the table.  (It’s in the update_fix_d6_requirements() function in update.php.)

// drop cache_block table
update_sql('DROP TABLE {cache_block}');

// Create the cache_block table. See system_update_6027() for more details.
$schema['cache_block'] = array(
  'fields' => array(
    'cid'        => array('type' => 'varchar', 'length' => 255, 'not null' => TRUE, 'default' => ''),
    'data'       => array('type' => 'blob', 'not null' => FALSE, 'size' => 'big'),
    'expire'     => array('type' => 'int', 'not null' => TRUE, 'default' => 0),
    'created'    => array('type' => 'int', 'not null' => TRUE, 'default' => 0),
    'headers'    => array('type' => 'text', 'not null' => FALSE),
    'serialized' => array('type' => 'int', 'size' => 'small', 'not null' => TRUE, 'default' => 0)
  ),
  'indexes' => array('expire' => array('expire')),
  'primary key' => array('cid'),
);
db_create_table($ret, 'cache_block', $schema['cache_block']);

Drupal’s Vote Up/Down module version 5.x-1.1 is broken.  Votes aren’t saved.  The patch in comment #2 of this issue fixes it.

I keep forgetting the names of the date formats in Drupal’s format_date() function.

They’re “small“, “medium“, ”large“, and “custom“.

I keep wanting to use short / medium / long because it feels more natural to think of the date formats as lengths.

In any case, that’s not reality. So to help me remember the options, I think of Drupal date formats like pizza sizes.

Even though I tell everyone I know to use Drupal for their web projects, I finally caved and set up my personal blog (what you’re reading now) on Wordpress. I finally faced reality — using Drupal for my personal blog was overkill and added so much unnecessary complexity.

Don’t get me wrong. I’m not defecting. It’s not a war where Drupal and WP can’t coexist. Each CMS has its place and purpose.

For example, if I had to do it again, I would still build the Top Personal Finance Blogs directory and Money Tips Network aggregator using Drupal.

But for personal blogs, Wordpress is the right way to go. I don’t need complex custom functionality. I just need a basic blogging app that makes it easy for me to post my random thoughts.

For years, I thought that as a self-respecting Drupal webmaster, I should use Drupal for all my projects. Then I started using my personal blog as a Drupal sandbox. The more I experimented, the less usable the blog became. I stopped posting because I didn’t want to deal with the mess my futzing had made.

Now I just want my blog software to just work, so I can just blog instead of spending time under the hood.

So here’s to using the right tool for the job. Wordpress rocks.