Installation was easier – not that a single site install was ever that complicated for this developer… but it ‘looks’ nicer now and had some very clear warnings about file permissions etc…

The default theme has a nice black admin bar at the top that reminds me of the administration menu module we always install here.  It’s definitely not the same – it doesn’t have the full set of dropdowns and all but it looks similar. Also, there’s a nice shortcuts menu below that admin menu that you can customize. Again – might not be helpful to an admin since you need to get to sooo many different things but will surely help out the average user or content editor.

All the edit screens load up using ajax now which is a bit surprising! It does break down nicely and the back/forward buttons work fine. I didn’t see a big boost in load time (internet is slow today so maybe it’s just that) but I do hope that this ajax loading translates to smaller server requests and load times when editing.

Another ui shocker – the content editor doesn’t have those familiar collapsible framesets anymore. All of those sections are at the bottom of the page in a mini-sidebar type of layout. I like this layout better – no scrolling scrolling scrolling and many of those sections you rarely deal with anyway so they can just stay hidden.

And some admin candy – you can install modules directly from the admin tools now. That is REALLY nice as I managed to install the Link module right from the backend. Sweet! It’s similar to installing plugins in wordpress where you can specify ftp info and pull files down from a url.

Ok, last comment for now, cck functionality is now in the core (under ‘Structure’) so you can create custom content types right out of the box. There’s a number of input widgets pre-loaded but like I mentioned I had to install the link module myself. Image IS in there as a field type though – crackin!

Well, there is still a lot more to try out but so far I’d say most of these changes are going to add up to a much better experience for the basic user and it brings drupal’s administrative interface closer to the ease of use that you get/expect with a wordpress. In my mind that is a pretty big deal because it’s always been a critical distinction between the two and seen as a barrier to using drupal. Time will tell but it looks very positive.

Oh – and a quick shout about the drupal 7 release party here intown in Atlanta.  Get out there and raise a glass to celebrate with the community. Hopefully someone from here can attend.

mysql> select filename from system where filename like ‘%/my-module-name/%’;

This will give you a relative path to the module.

At first I got bogged down trying to get it to work with some url rewrites in the .htaccess file. It seemed logical but it didn’t work because passenger does it’s thing before .htaccess even kicks in. Besides, the best approach is to bypass passenger completely for that directory – better for optimizing and is really more true to what we were trying to setup.

After digging I discovered the ‘PassengerEnabled’ directive! I know RTFM. Just set PassengerEnabled off for that directory and we’re golden.

Now how to fit it into cpanel but just for this domain? Not as simple as it sounds. Editing the httpd.conf is of course NOT the right solution. Cpanel does expose some parts of the apache configuration in the admin but it’s not vhost specific so again it would affect all sites when I just wanted to change one. RTFM again and you’ll see there are some manual ways to insert things directly into the vhost. You have to manually create a series of directories (the userdata one at the top of the chain is not there by default) and put an override file named anything.conf in the right place.

In my setup i created the file override.conf here:

/usr/local/apache/conf/userdata/std/<vhost account number>/<cpanel user name>/<domain name>/override.conf

And put this in it (/drupal is the folder i want to run php in).

<Location /blog>
PassengerEnabled off
</Location>

And now one more hitch…

Running /scripts/verify_vhost_includes like it says to in the cpanel docs said that my vhost file had an error!!! It said PassengerEnabled was not a valid directive. I ended up just giving it a shot anyways and was pleased to find that it worked just fine! I suspect that cpanel just doesn’t know this directive becuase it is specific to passenger. So you run:

/scripts/ensure_vhost_includes --user=<cpanel user name>


to rebuild the vhosts file for this user and restarts apache and voila!

Whew

Here’s some more details… http://buytaert.net/whitehouse-gov-using-drupal