OK – so this week I thought it was time to take a look at the new Drupal 7 – alpha 6 version on my test server.  First for the good news.  It installed very simply using the old procedures I was used to.  You still have to set the settings files the same old way.  No automated install script yet, although there is an update  manager once you get Drupal 7 set up.  The update manager is not like Wordpress in that you cannot click on “install update” and automatically fetch a widget and install it.  “Install module” links to the project page and you need to select the module FTP and paste it into the form window.  You have to know the ftp location or have the module downloaded locally.  Setting up the settings file is like the version 6, only now you can use multiple databases.

Drupal 7 frontpage for the admin shows a topmenu.

The look is much cleaner and much improved over that in Drupal 6, but the menu is still only one level and you will need to know where the various components are on submenus, but this is a vast improvement over the old system.

A number of contributed modules have been moved into the core.  CCK, imageAPI, imagecache, and filefield  have all been moved into core so the system handles graphics and uploads better.

Big disappointment is that there are only two content types initially, pages and articles, and no text editor.  But I will say that CKeditor and IMCE work well together for 7. You just need to install WYSIWYG and IMCE WYSIWYG bridge to get them working.  I just don’t understand why they are not part of core.

The main admin menu has modules as a main menu item up top and help, but you will need to load advanced help menu for help on  major modules like views.   As Drupal 7 comes out of the can, it is configured as a Content Management System, pure and simple.  If you want additional functionality, you may have to wait for contributed modules to be updated for Drupal 7.  Right now(Aug 2010), a very large number are promising to be ready when 7 is launched.

The bets are on that Drupal 7 will be released in September.

You can update Drupal 6 and the contributed modules, but you are never finished.  Just like the song version by the Eagles, the next time you check status, there will be a version or contributed module that is already in need of an update.  If the site uses a large number of contributed modules, the updating job is never done.  This unfortunately means that a developer’s job with a site is never done as well.  Clients don’t like Drupal maintenance charges, and developers don’t like maintaining test sites and code bases after the site is launched.

I manage a number of Drupal installations.  The only similarity between the sites is the core code, the contributed modules and installed text editors vary from site to site.  I have looked at multisite installations, but that seems to not work well on shared servers, and may require some tricky DNS work.  Multisite installations appear to work best in site-sub sites configurations.

Most of the Drupal sites I build, the client wants the development to end at launch.  I routinely put into the letter of agreement on each Drupal project at least 3 months of initial maintenance for training, etc.
With Drupal, those hours for training and small fixes, often rapidly get eaten up with doing version upgrades and contributed module updates.  With three of my most recent installed Drupal sites, I had two version upgrades and more than 26 contributed module updates for security in the first 3 months.

Frankly, I am finding that the best method is to allow one day each month for updates and upgrades. I first do any upgrade and then test it on the test server.  This means I have to keep the test server going after site launch and keep the build configurations similar. Then test the module and site to ensure that any changes are stable and work for your site configuration. Be sure to check the error report as problems with the database may be indicated.

There are 17 steps in the upgrade instructions on Drupal – http://drupal.org/node/29161 and 9 steps for modules – http://drupal.org/node/672472 – both of these are certainly the safest methods.  It is also the most time consuming.  There are some simpler, but riskier methods – http://drupal.org/node/816600 – especially if you are upgrading/updating a number of sites. This method upgrades only the core files that have changes in the date stamp and can be installed on top of your already installed base.  I found that it works well and simply.

As I learned a couple of years ago, do not update a theme if you have modified the CSS file, graphics or php templates directly.   If you make changes to the CSS use a custom theme file for those changes, give graphics unique names and if you modify a template file rename it.  Otherwise those changes will be lost in an upgrade.

The question is should developers continue to upgrade/update after the site is launched?  The answer is yes and no.  If the upgrade is a security upgrade or update, then make the change.  If the update is a bugs and fixes for a module, then make the change if time allows.  An additional consideration is whether the optional module is part of the page building such as with CCK, views and panels.  Here changes can be catastrophic to your page look, so be extra careful.

If all possible, do not leave a Drupal site without an admin.  If you plan to leave, after site building and configuration, then train the client’s personnel in how to perform these tasks.

Like in the song, you can check out (of doing more upgrades and updates) to a site after launch, but you can never leave (the security concerns) behind.

Clients often ask me why custom websites are so expensive.  My reply is twofold.  Too often too much money goes into design as royalties on quality photographs can easily be $750 each.  The second major cost driver is added features such as search, analytics, slideshows, galleries and flash animations.  When a client wants a number of added features, I switch away from simple Dreamweaver CS site building to application programs that incorporate many features such as search, password login, analytics and content management. These systems are more difficult to configure and may require simpler design, but offer cost reductions in not having integrate separate applications or features.

Most websites seems to be classified by their use such as ecommerce, news, or corporate.  From a developer standpoint use or purpose is the most important aspect in deciding the best method or tool for developing the web site. The tool then becomes the major determiner of cost.

A Dreamweaver site consists of content, navigation, coding and design.  Dreamweaver is a good tool because it separates the design and content.  The design look can thus be constructed and placed into the templates.

A Dreamweaver CS site will always be the cheaper method if the design features are moderate and the amount of content is small and primarily text-based.  Dreamweaver offers strong integration of graphic design and flash or flash video with text but the process is manual.  Page templates and library items make building a moderate amount of content manageable and efficient.  This method is best for basic static sites that do not require frequent updates or changes.  Developers often refer to this type of website as online brochures or brochureware.  If the company has a good set of brochures that process is relatively inexpensive.

When the client wants a website that can deliver lots of content and with changes made by staff, then a content management system (CMS) application is the best choice.  If a client wants to restrict content to certain groups, the choice of a CMS-based system is a given.    If only a portion of the site is to be dynamic or restricted then a limited CMS like Coranto can be used.  Coranto works well for a dynamic newsroom application on an otherwise static website.

A secondary cost with dynamic sites is the requirement for hosting that supports configuring the server for an application and supports the use of databases. CMS applications such as Drupal, Wordpress, or Joomla are open source and well supported.  Good hosting companies for these applications are Webmasters or GoDaddy.  Most hosting companies charge $150 to $250 a year for business hosting of a website with database.

Lastly, most companies are poorly supported for photography of their products, services and operations. The cost of using a paid photograph on a site can cover the much of the cost of getting a good commercial photographer to document your products and services.



“A little good publicity will take care of that,” or “If we could just get in the newspaper more” or “nobody knows the great things this company does!”  We have all heard it.  When clients think it is time to turn to public relations for help, it is often because their own spells and voodoo dolls don’t seem to be working.

Dear client…PR is about relationships.  Experience has shown me that companies that want publicity also want to improve sales, raise their stock price, reduce the number of product complaints, reduce employee turnover, boost morale and get rid of the CEO’s idiot nephew that is running the PR program.

Make that “so-called PR program.” Just like most companies, public relations programs may have no plan.  Rather, the communication program is a collection of products – flashy annual report, lengthy news releases, narrative for analyst teleconference, unseen Facebook fan page or a CEO speech for the chamber.  There is nothing that defines, establishes, or builds relationship with a public or group.  Imagine if you dare, a relationship with your wife made up entirely of a Hallmark card each month, a couple of text messages each week, and a Facebook page with photos of you and the children.  I think you get the picture.

When I go into a company to help with their public relations or media relations programs, the topic of measurement frequently comes up.  Most companies have PR measurement programs built on the number of newpaper clips, number of annual reports requested, and/or dollars given to charity, but any reference to real relationships is just plain missing.  The discussion with PR staff about their relationship with news media, analysts, local leaders, industry trade publications is depicted as “we called the newspaper about our release so we know they got it”, or “ the CEO doesn’t go to Chamber events because they are so boring”.  And when the inevitable crisis arises, the staff analysis is short and sweet – “the newspapers are out to get us.”

If your company does not have a communications plan built on relationships, have fun when the crisis comes.

You will regret the day you decided your Drupal 6 should have a text editor. Just imagine, a major Content Management System without an editor.  I joke right.  No, Drupal 6 does not have a simple editor as part of its system.   If you want to see a text editor as part of the basic application, then better try Wordpress.  I suspect that the lack of a basic text editor is the primary reason that Drupal is not considered by many developers and users.

If you google “Drupal 6” and “text editors, you will see that Drupal users have been asking for a simple text editor in the core for 4 years and no one has answered the call. What a shame.

If you noticed my Mar 15 article, Keeping the “F” in FCKeditor might be best , my conclusion in that post was that installing the new CKeditor in place of FCKeditor unleashes a host of problems if you want to maintain the ability to upload and insert inline graphics.  I finally got some time to sit down and tinker with CKeditor and CKfinder and I got it working.  But the CKfinder is not open source and requires licensing (money) to use on commercial sites.

Two years ago, Drupal 6 users cries for a text editor raised to a crescendo when the only effective text editors were farmed out through the WYSIWYG API.  Since 2008 nothing has really happened or has it? FCKeditor has gone to CKeditor and effectively kills graphic uploads.  TinyMCE drifted unsupported for awhile but now is part of WYSIWYG API if you use a bridge module and ICME.   I finally got the TinyMCE working with ICME, but be careful there are a number of incompatibles.

Conclusion, the text editor is a mess unlikely to be resolved soon.  Drupal 7 does add image handling to the core. But even after four years of users calling for a simple text editor, those calls go unheeded.