On 15 January 2010, I installed the Drupal 7.0 Alpha 1 release on a Linux server used for testing here on my home network. The server uses the following LAMP configuration:

• Linux – Ubuntu 9.10
• Apache 2.2.12
• Mysql 5.1.37
• PHP 5.2.10

Installation

The installation was uneventful.  I noticed that it now requires that the following folders be present in the Drupal root.  If they are not present, the installer will not proceed until they are created.  One must leave the installer and create the folders via the operating system’s file management utility or command line interface.

• sites/defaults/files
• sites/defaults/private/files
• sites/default/private/temp

Other than that, and the much improved UI, my impression is that the Drupal 7 Installer isn’t a big departure from those of previous releases.

New Features

The Drupal 7.0 Alpha 1 core contains a number of new features.  The subsequent text summarizes those that were, in my opinion, the most significant.

User Interface

The most visible change in Drupal 7 compared to previous releases is the redesigned Administrator UI.  The administration backend has a new default theme called Seven, which looks good with Firefox and Chrome, but needs some tweaking to render correctly in IE8.

The new UI has a top horizontal menu containing links to various management functional areas, along with a configurable “shortcut bar” that can be customized by the user.

In addition, there is a configurable “dashboard” page that the administrator can use to organize administrative tasks and track site information.

For the most part, I found the new UI well organized and easy to navigate.  I may be biased here as I am one of what seems to be a small minority that thought the Drupal 6 UI was not really all that difficult to understaqnd and navigate.

There was one change I thought was really not needed:

• Using “People” as the label on the tab that opens the configuration panel that manages “Users.” 

One rationale I’ve heard for this is that it is done to make a distinction between administrators and other users (anonymous, registered, etc.). To me this is going a bit too far as the IT industry has historically used the term user to identify people who have access to a particular software application.  For example, one can characterize an administrator as nothing more than a “User with Benefits.”

Update Manager - Automated Installation

Drupal is finally on par with Joomla!, Wordpress and a number of other CMSs in this area.  I tested this feature by installing the Drupal 7 development version of the popular Views module via its download URL at Drupal.org.   No need to download it to my PC and then upload it to the server and do a tar to extract the files.  Better yet, for those who do not have shell access to their servers, no more downloading to their PC,  extracting the files locally, and then uploading the expanded files to the server.

Custom Fields

The Drupal core now supports the addition and management of custom fields.  Custom fields can be added to content types, along with other entities such as users and taxonomies.  This includes both text and image fields.

            

Image Handling

The Drupal core now supports native image handling including as cropping and scaling.

Under the Hood

There are also a number of “under the hood” updates and improvements.

Theme Development

There are a number of changes to the theming which I am still digesting.  Hopefully, this will be the  the subject of a blog entry here in the not too distant future.

Odds and Ends

One thing I noticed is that there is no longer a distinction between “Core – optional’”and “Core - required” modules.  The required modules (Block, Filter, Node, System, User)  are no longer shown on the Modules page.  I’ll leave it as an exercise to the reader as to why this is a good thing!

Conclusions

Alpha1 is a much more polished release than the development snapshot I wrote about a few months back.  However, as with any Alpha 1 release, many rough edges still exist. 

Disclaimer

Any errors or inconsistencies in the above are no doubt due to oversights and/or technical ignorance on my part.  The authoritative source for information regarding Drupal 7 is Drupal.org.

On 15 September 2009, I downloaded and installed the Drupal 7.0, Unstable 9 development snapshot of the upcoming Drupal 7.x release.  I did two installs: one on my desktop and one on the Linux server used for testing here on my home network. 

The desktop runs Vista Ultimate 64-bit, SP1 and uses WampServer as its LAMP environment.  The configuration includes:

• Apache 2.2.11
• PHP 5.3 or PHP 5.2.8
• Mysql 5.1.30.

The server runs Ubuntu Linux 9.04.  The LAMP configuration includes:

• Apache 2.2.11
• PHP 5.2.6
• Mysql 5.0.75.

Installation

I did not notice much of a change between the Drupal 6 and Drupal 7 installation procedures.  One thing I did notice was the changes in the terminology to create a more user friendly experience. 

Other than the usual Linux file ownership and permission inconsistencies I encounter when installing applications on the Ubuntu Linux server, installation in both environments was uneventful.  PHP did run of of memory during the install on the server, but that was not really a Drupal 7 problem.  I upped the PHP memory allocation from the default 16M to 128M and that fixed the problem.  I need to check this later and determine what the real PHP memory requirement for a Drupal 7 install is.  I'm sure it's much less than 128M.

Administration

Drupal 7 introduces a number of changes in the administrative backend.  The most obvious change is that if you are logged in as the administrator, a menu appears at the top of each page that contains links to the various administrative functional areas. 

If you have ever inadvertently destroyed your public theme as I have, you really learn to appreciate Drupal's option of having a separate administrative theme.  Prior to Drupal 7, I typically used the Garland theme for administration.  I was happy to see that Drupal 7 includes a one-column, fluid width theme called Seven that is tailored for use with the administrative backend. 

 

One often heard criticism of Drupal is that its administrative backend navigation is less than straightforward and the terminology is too abstract and/or contains too much technical jargon. 

Drupal 7 has made a number of terminology changes and reallocation of functions to categories to make the administrative backend.  The changes are too numerous to delineate here, but comparing the new administrative backend view to that of Drupal 6 shown below, it's obvious that a lot of time and effort has been put in to make the Drupal 7 administration a bit more user friendly, more intuitive and easier to navigate.  To really appreciate all the changes, one must really install Drupal 7 and work their way through the administrative backend.  It is still far from perfect, but it is a big step forward. 

Core Modules

A list of the Drupal 7 optional core modules are shown on the right.  Modules that are new in Drupal 7 are outlined in green.  The Drupal 6 optional core modules are shown on the left.  Those which are not present in Drupal 7 are outlined in red.

What's New in Drupal 7 Core

I guess the biggest news for Drupal 7  is the incorporation of basic Content Construction Kit (CCK) functions in the core (Field, Field UI and File modules).

The Image module incorporates a more sophisticated image manipulation function than previous releases. 

The SimpleTest module provides a framework for unit and functional testing.

The Toolbar module provides the UI for the new top horizontal administration menu.

What's Gone in Drupal 7 Core

The BlogAPI module is gone.   I was initially a  bit disappointed to see it go as I use Windows Live Writer (WLW) quite a bit.  However, it will still be available as a  3rd-party module.

The same goes for the Ping module.  The growth of social networking has resulted in a number of 3rd-party modules that provide this capability plus more.

The Throttle module is also gone in Drupal 7. 

One other thing I noticed is that there is no longer a distinction between "Core - required" and "Core - Optional" modules.   In Drupal 6 and earlier, the Block, Filter, Node, System and User modules were classified as "Core-Required." 

Theme Development

I haven't quite digested all the changes in the theme system; however, at first glance there appears to be a number of  changes needed to upgrade a Drupal 6 theme to one that is compatible with Drupal 7.  You can read about the changes here. 

The goal of these changes is to make Drupal easier to theme.  I guess I'll find out about that soon enough.

Conclusions

From a user point of view, the big change is in the Administration UI, which is a good thing.  I know there there are numerous changes under the hood that make Drupal 7 faster and more reliable than its predecessors.  However, I feel that Drupal still has a bit more work to do in the UI and ease of use areas.  

Disclaimer

Any errors or inconsistencies in the above are no doubt due to oversights and/or technical ignorance on my part.  The authoritative source for information regarding Drupal 7 is Drupal.org.

I recently completed a major update of my oldest internal Linux Server here at hrpr.com.  The server, whose name is Doofus,  is hosted on a Dell Dimension XPS T500 that has been in service here since April 1999. 

For the last eight years, Doofus has been running Slackware, which is a hard-core, no-frills, very stable Linux distribution that has been around since dirt was new.  If you aren't on speaking terms with command line shells such as Bash and are not familiar with the Linux Directory Structure and its contents, then Slackware is probably not for you. 

Back to the update stuff...

I was getting ready to download the latest, greatest version of Slackware and install it on Doofus when it suddenly occurred to me that I had recently downloaded the latest version of Ubuntu Linux and had made an installation CD-ROM for it.  It was the Desktop Edition, but as a local test server, it would do just fine.  I was also curious to see how GNOME would perform on a Pentium III with 256M of RAM.  After all, I was essentially starting with a blank slate and could revert back to Slackware if I really wasn't satisfied with Ubuntu.

I did the Ubuntu install and, as usual, it was fast and uneventful.  Doofus rebooted and up came the GNOME GUI.  And surprise, surprise!   It was quite responsive.  The mouse was responsive and GUI applications ran fast enough to meet my "wait-time" expectations.  Which really didn't matter much anyway since Doofus would be running 99.99999% of the time as a server with remote administrative access via SSH and/or Webmin.

I installed the LAMP stuff and a BOINC Client for running SETI at home tasks.  And that was it - Doofus was back online doing its thing.

I am still a Slackware fan and highly recommend it to anyone who enjoys tinkering at the command line level and/or wants to learn Linux from the ground up.  However, Ubuntu brings added value such as automatic notification of security updates, a more feature rich software package manager and other administrative tools that make life a bit easier.

And who knows, next week I may change my mind again and install Slackware Linux on Doofus yet one more time.

Back in the day, when the TCP/IP protocol suite was the new kid on the block, one of the classic issues was how to deal with half-open connections:

A TCP connection is considered “half-open” when one party thinks the connection has been closed and the other party thinks the connection is still open.

One solution to the half-open connection is the old "When in Doubt, Time Out" rule.  That is, if no packets have been sent/received on an existing connection for some preset period of time, unilaterally close the connection.  Not elegant, but works great. 

The Internet has grown exponentially over time and TCP/IP has become one of those things that are just there and works the way it is supposed to 999.999999 percent of the time.  Today's average PC user really doesn't think or care about half-open connections as defined above anymore, or even how TCP/IP does what it does!

Why am I writing about this?  Well, over the past week or so connections to two of my web sites has been bouncing, i.e., the monitoring service I use has been reporting intermittent loss of connectivity:

Alert Type: Site Not Available

Result: Failed

Time: August 11, 2009 10:39:23

HostName/URL: portal.hrpr.com

Monitor Name: hrpr.com

Service: http

Alert Type: Site is Available

Result: Ok

Time: August 11, 2009 11:09:24

HostName/URL: portal.hrpr.com

Monitor Name: hrpr.com

Service: http

I opened up a trouble ticket with my host provider and after a few back and forth conversions with them, ended up with this more or less "final" answer to the root cause of my problem.  Although not mentioned below, the implication was that the PHP scripts used by my sites were exceeding the server's PHP memory usage and/or processing time limit.  And I knew this wasn't the case:

Well, unfortunately, I have to maintain that the problem lies elsewhere at this time. Your server is rock solid stable, your apache instance is unwavering, and the ONLY reason I've found, other than an external connection issue, somewhere between yourself (or your monitoring service) and our servers, is the process watcher entries. If this were our issue, I'd be very quick to point it out. We're not really about shifting blame here...check out http://... for shining examples of our "we screwed up, we'll fix it" mentality.

However, in this case, the two possible issues are a bad connection between yourself and our servers, and the process watcher/resource issues. Again, if you want a useful diagnosis, we'll need to see a traceroute taken at the time that the problem is occurring. I never suggested you had networking issues anywhere else...but incorrect routing, or network issues along the specific path that your connection takes can cause a perceived interruption in service. You may also try checking your site via proxy such as http://... the next time it appears to be down.

Let me know if you have any other questions!

After reading this response, please consider visiting the URL below to comment on its quality.

Thanks!

http://...

To which I replied:

OK, I give up, you win. I'll continue trying to isolate it on my own.  And a few other choice words I will not repeat here. 

As suggested, I did visit the "URL below" and sent a comment on the quality of the response.  As you might suspect, my comment was somewhat negative.

A few hours later, I got this in an email from the host provider's support team:

I think I found your issue. I apologize that this was over-looked but this actually isn't supposed to happen as on our newer servers we have implemented FTP connection limits to stop them from piling up. Basically I saw your user had a huge number of stale FTP connections.

There was about 100 of them. Our process watcher will kill your processes if you have too many processes running and that's why your processes were being killed (99% of the time they are killed for memory usage not process count). Our process watcher won't kill FTP or shell connections as its hard to tell if the connections are legit or not but they are still counted towards your total process limit.

I killed all your stale FTP connections so I think you won't be getting killed by our process watcher anymore (or not nearly as much). It looks like all your processes that were killed were due to the process count limit (not memory).

I apologize that this was over-looked by ... but I can understand why as this isn't even possible on our newer servers because we limit the FTP connections to 7 total by IP or account and again 99% of the time processes are killed for memory usage not process count. Please feel free to email me at ... if you are still running into these issues and think this issue might have popped back up.

In 25 words or less, the intermittent connectivity problems were being caused by half-open (stale) connections. 

The host's FTP server thought the connections were still open and as far as my FTP client was concerned, they had long since been closed.  The nasty side effect of this was that other processes such as those spawned by the HTTP server were getting killed off because of this.

What's the moral to this story?  Well, there really isn't one.  I just wanted to write this down somewhere as it brought back memories to me of days gone by.

I just finished reading an article with an interesting view on the economic effects of the Internet by Tom Foremski of ZDNet.  It made me think a bit about what long term changes the Internet might bring to our way of life and economic well-being here in the USA.  We all hear the mantra that losing jobs to other parts of the world will more than be made up for by the the "better" hi-tech jobs that will be created here in the USA. 

Sounds great, but in reality not everyone will be equipped to do these "hi-tech" jobs.  I wonder if we will eventually become a nation of people with low paid service jobs and high paid technology jobs with nothing in the middle.