If you are building a site and you expect significant traffic from mobile devices, you have a choice. Buy the latest and greatest Adobe Dreamweaver version and build an alternate site just for mobiles or get WP Touch.

If you are already using WordPress, then download and install the WP Touch plugin. I cannot vouch for all smartphones, but for the iPhone it produces a terrific looking site without having to direct traffic to an alternate site.

iPhone 4S screenshot of a WordPress website using the WP Touch plugin.

According to the plugin info page, WPtouch automatically transforms your WordPress website into an application-like theme, complete with ajax loading articles and effects when viewed from the most popular mobile web browsing devices like the iPhone, iPod touch, Android mobile devices, Palm Pre/Pixi and BlackBerry OS6 mobile devices.

The admin panel allows you to customize many aspects of its appearance, and deliver a fast, user-friendly and stylish version of your site to touch mobile visitors, without modifying a single bit of code (or affecting) your regular desktop theme.

The theme also includes the ability for visitors to switch between WPtouch view and your site’s regular theme.

PS. If you want to know how to do screen capture on an iPhone 4S, it is simple.  Get the view on your Safari browser, hit the awake/power button and the Home button and in a moment you should hear the photo sound.  Do not hold too long or it could reset your phone.  You can then retrieve the screenshot under Photos.

Truth is while I was waiting for 6 months – nothing happened. It seems that while I was making my stand, the rest of the Drupal Programming Community moved on.

Drupal 7 is now at version 7.10 and many of the modules that provide the features needed for news and newsroom sites are increasingly available. Maybe it is time for me to move on.

Much of what I have been programming lately are WordPress sites. WordPress has a wonderful system of maintenance updates and module updates.

Drupal 6 moved in 2010 to create dual upgrades so that security and bug fixes could be in their own versions. It means that website maintenance doubled and having a test server was vital to ensure upgrades did not break major functions of a website.

At the same time that maintenance became so difficult for Drupal 6 upgrades, a number of Drupal hosting services were launched that offered free sites – see for example www.drupalgardens.com .

Looking a the open-source content management systems, WordPress is now more than 50% of those sites. WordPress is an inexpensive solution that is fairly easy to configure on a commercial server and handles the maintenance and security update issues well.

Maybe it is time to stop holding at Drupal 6 and move on to Drupal 7.

This essentially means that you have to go back to the old method of updating version changes. That method is a very tedious process that requires one to backup the sites directory and any custom files, backup the database, put the entire site in maintenance mode, disconnect all contributed modules, delete the code base, copy in the new core directories, copy in the old /sites directory and any custom files, run update, reconnect the contributed modules, rerun update, return site to online. Two parts are particularly cumbersome – disconnecting the contributed modules and FTPing in the /sites directory files. For example, on my main Drupal site supporting Compton Communications there are sixty contributed modules that will need to be disconnected and reconnected. Also FTPing in the /sites directory requires moving more than 100MB in 8000 files. This process is time consuming and will mean extra expense for clients.

Also, with this update/upgrade to Drupal 6.22, we have a few other problems. In the forums, there are discussions of block configurations that were lost and ecommerce modules that no longer work with this update. With the files only upgrade, one was only changing out files that needed updating – a much more efficient and effective method. Take a look at http://drupal.org/node/534950 for all the details. I plan on staying at Drupal 6.20 until I see some of these conflicts resolved. I hope we can find a way to restore the files only update option.

Other Notes:
If you use the files management system for Drupal – Filedepot, you got a nasty little surprise with the last module update to 6.x-1.2. Filedepot had to remove some key libraries and the module will be broken when updated. The process to restore it is in the README file with the update. All the details are at http://drupal.org/node/1125192 , but you will find no reference to the new version at the filedepot page http://drupal.org/project/filedepot . It is not a simple process because it is dependent upon a module termed libraries that is hard to find and the required three libraries have to be built and added to the libraries directory.

Solution:
1) After deleting semaphore in Variable table….
2) Set XML Sitemap module chunk size to 10,000.
3) Set Search Settings to “10 per cron”
4) Set PathAuto General settings from 50 to 25 for objects to alias.

Helpful:
Supercron – http://drupal.org/project/supercron

Probably the biggest black hole and last technical hurdle in Drupal 6 is “cron”. If you are building a glorious modern CMS website with all the bells and whistles, then cron is the “outhouse” you have to build outback. Looking at the forums and all the problems with this single file, I think it probably singlehandedly causes more programmers and enthusiast to quit Drupal than any other task.

My own frustration with cron came when I wasted (still in the outhouse mode here) three days trying to solve a simple “cron failed” on a test server site. It wasn’t even a site, I was not planning to go active anytime soon. The site was part of a club-type site that I just played with ever so often. But once I saw that message, I started tearing it apart to find the problem. Above is a list of the major cron topic pages. You can spend days trying all the solutions, coding examples for finding the cron problem and just outright wrong suggestion for a cron fix.

First, if cron fails, look at the error message in Reports > recent log entries; apache error logs; php error logs; and mysql.log. Do not jump into doing things suggested in the Drupal forum especially if they are based on Drupal 5 or pre-2009. Quite often those suggestions can make the matter worse and harder to debug/decipher later. The old forum entries are of the format – try this or use this script to debug. With Drupal 6, such methods are not helpful. My suggested first step is to apply the solutions that merely change some module settings and clear the cron_semaphore and cache. If you need to debug further, then I recommend you install the Supercron module. Supercron will show you what modules are using the cron process and allow you to invoke them one-at-a-time to find the problem module.

Please do not waste three days in “cron”ic mode.

I learned a lot from six days spent testing and retesting Flashvideo. According to the Drupal project page the module is a complete turn-key video solution that expands Drupal’s upload capabilities to allow web developers and users to upload video files, automatically convert those videos to the popular Flash format, and then embed their video in any node type using the simple [video] tag. The module is about four years old and thus there is a lot of information available online and a lot of that information is outdated or pertains to previous updates of the module.

There are also a couple of videos of the Drupal Flashvideo module and how to install it. Most are at least two years old. Part of the problem with Flashvideo is that the module depends on two other elements. FFmpeg is a binary application that must be installed on the server. Most hosting services charge additional for the application – not my service – and installing it on a test server such as WAMP or MAMP can be a real challenge.

So assuming a correctly installed FFmpeg, the next problem is the player. During the four years that Flashvideo has been versioning from Drupal 5, many changes have occurred. So if you depend on a two year old video, you will find at the end of the installation that it does not work. This is exactly what happened with my client.

When you go to the Drupal forums and various blogs you will find numerous problems that have been found and solved, but only a couple of them may really solve the problems – Yes, problems for the more recent versions of Flashvideo. There are essentially three that I found – FFmpeg commands, content type added fields, and the video player.

FFmpeg has been versioning just as Drupal has, so the default command in the Flashvideo > Content Type Setting > FFMPEG settings is likely wrong. If you are using a recent version of FFmpeg you may need to change the command line to replace “mp3” with “libmp3lame”. At any rate you will need to understand the commands for FFmpeg to make the conversion do what you want.

Content type is the second problem. In the original any number of videos could be placed on the node to include the original video and the converted flash version. But that process no longer seems to work. The original upload video content type needs to have under the “display fields “ the type excluded.

Flashvideo display settings for content type fvideo

Last is the player problem. The whole time that Flashvideo has been versioning, the media player has been drastically changing as well. With a whole lot of work you can get the original Flowplayer to work with Flashvideo, but then you will not have the poster image only a black screen. Even worse is that if you turn on Jquery with SWF Tools, your Views module no longer works. So I strongly recommend the JW_player. You will need to install the jwplayermodule, but it is worth the effort and the added cost. The player retails for $89. With JWplayer 5.5 you can insert video into any content type. The instructions are in a PDF for Drupal with the download. It is a very nifty solution that uses file attachment. After you have installed the JWplayer module you will need to put a copy of player.swf from the JWplayer directory into the directory where the videos are output and rename it “Player.swf”.

It took six days of trial and error to get to this solution. Good luck with your flashvideo install.
Sample Flashvideo on Compton Communications Drupal site – http://www.comptoncoms.com/cc/content/welcome-compton-communications-video .

A current movement in video is to have a fallback scheme for any video. This scheme called “video for everybody” allows the browser to find the video in a format it can handle without the requirement to download and install some specific player format like flash.

This is a precursor for HTML5 in which the “video” tag will handle the presentation to a video player that the browser supports. Part of the fight in “video for everybody” is to prevent Web video from being forced into a proprietary player or format like flash. For developers the hope is to find a way to present video without great difficulties such as presenting multiple video file formats.

Mac users, iPhone and iPad users (myself included) need a video alternative to flash. In a website I built for one customer, I faced the problem that government website prevented users from downloading and installing video players, so I ending up encoding and embedding multiple players in a page and allowing downloaded versions for those customers restricted from streaming. The “video for everybody” and HTML5 represent much improved solutions for these problems. But they also require the multiple encoding for multiple browsers. For Drupal 6 the video solution can get even more complex.

The effort to present video consistently in Drupal is hindered by video players heading off into multiple proprietary efforts. The developer faces flowplayer, flowplayer 3, dash and other players that no longer work in Drupal. Or he faces using a proprietary player that is supported today that may be abandoned tomorrow. Those proprietary players also may have a whole new set of embedding and coding requirements. This concludes my rant about Drupal shops that offer proprietary players that chip away at Drupal as an open system.

The video solution I offered my client initially was based on a commercial player. Jwplayer is an excellent commercial player that offers a good, flexible interface with Drupal. Ultimately, I was able to solve the embedding, content type configs, FFmpeg commands and player problems and make Flashvideo module work for the client. I will discuss that a future blog.

My solution

I wanted a solution that supports insertion of video into any content type and would not require the creation of a special content type. Three modules need to be installed: jwplayermodule
, file attachment utilities, and Stylistics. You will also need to install the Jwplayer 5.5. For commercial sites you will need to buy a license for the jwplayer.

The process of uploading videos and embedding them in a content type is shown on the Longtail site and comes in PDF when you install the jwplayermodule. Details are on the Longtail website in an article entitled “Embed the Jwplayer using the Drupal module.
That’s it. So simple and so elegant.

I just looked at the Symantec Connect. It is a major-scale Drupal site that uses a wide variety of videos, screencasts, etc. I did a little “page info” surfing to discover that their video service – uploading, encoding, content management, optimization, etc. are all farmed out to Brightcove. Brightcove claims hundreds of businesses are using their video platform to host their video needs.

What makes video on Drupal 6 so complicated is the FFmpeg application engine that does all the encoding. FFmpeg is complicated to install and when teamed with a web server can demand a lot of computing resources. Many hosting company sysadmins may have removed FFmpeg , fearing its use would bog down shared servers. For example, if you want FFmpeg on Hostgator, you will need a dedicated server. Bad news for thrifty users, but delightful of video server hosting firms like Brightcove and Zencoder.

Right now, I am working on a project to put video on a new Drupal site. It took four days of testing and work to come up with an interim solution that allows an excellent video display. At the core is a super videoplayer for Drupal that allows easy insertion of video into most Drupal 6 content types without a lot of configuration or modules. Good luck finding it yourself, but if you do … leave a comment.

In a couple of weeks when the site is launched, I will blog about this solution. I will give you a hint. The system not only gives you multiple players and plugin features for social media, but the player handles Macs, iPhones, and falls back to Flash if all else fails.

I had just started a project in which the client wanted a document repository to handle a bunch of Portable Document Format (PDF) files. I stumbled upon Filedepot and began testing it. My faith in the future of Drupal 6 was restored as I uncovered this module’s great features.

You can have your own cloud computing repository that stores the type files you want in a secure area, organized and searchable. There are flexible, granular file permissions that allows you to fully control access to a file down to a single user. You can set permissions for the folder for users, groups or roles.

Wait, there’s more. You can view the document repository via tags. But wait, there is even more. You can upload newer files and older files are versioned. Users can subscribe to the file and get notices of updates. But wait, there is still more. File Owners can use the broadcast feature to send out notifications as well.

Problems are already on the horizon with Drupal 7, however. A lot of coding work went into filedepot and making it available in Drupal 7 will require a major rework since the database APIs are very different.

Lastly, Filedepot has a series of reports available so users may view latest files, most recent folders, bookmarked files, and un-read files.

Why am I so excited about Filedepot? I use organic groups as a way to have areas on the website for my clients and partners on a project. With Filedepot I am able to set up a client area with a file repository of all the project files that is readily available to me and to the client or project partner. If we are working on an important file, I can simply use the broadcast function to notify the client of changes and updates in an email that automatically links to the document in the file repository.

This is a terrific Drupal 6 module. More information is on the Drupal siteFiledepot module

I tested the new Drupal 7 back in Aug 2010. First Words on Drupal 7 It looks pretty slick and the admin interface is a whole lot better.  But my main concern is that many of the modules – a large number are pledged to be ready for 7 – may not be available in the early stages of Drupal 7.

I am really pleased with how well Drupal 6 works with so many modules, but would love it if a great many of these modules were added to the core. As  I said in my November post, I have to update from 6 to 15 modules in many of my sites every two to three months before I do the core update.  Sure would be nice to cut down on the maintenance time.

On the other side of Drupal 7 problems is themes. I noticed that a large number of template makers are no longer building custom themes for Drupal.  I wonder if this creativity gap is caused by the pending change to Drupal 7 with its 53 changes to Drupal 6 themes, or the variety of free Drupal themes available.  Looking at the Drupal Themes page, there are 110 Drupal 7 themes and most can be easily customize. Looks like we no longer need to edit the template pages and CSS to get custom looks.

Recalling the mountain of hours I spent modifying a custom theme for one project, I am glad to see themes evolve into themes that are designed to be more customizable. The direct modification of base CSS files was never a good method. I just hope the new 7 themes will offer a lot more options with mobile devices like iPad and iPhone.

I spend all day yesterday looking for a template for an upcoming project.  It took all day because I kept jumping out to new sites that were built with Drupal.  Take a look at http://www.watchgmctv.com/ and you will see the best of design with Drupal 6 programming.

The best time to decide on the maintenance plan is while you are building the original site.  Many Drupal sites are likely built once and unless security changes or code updates come during the development, they are not maintained so long as they continue to function properly.  The reason is obvious.  Why go back and update code when the Web site is working OK?  Clients do not like paying for maintenance that does not appear to add desired features.  I do think that for most sites, security upgrades should be applied and periodic maintenance such as quarterly security updates should be made.  The upgrades should be made if the site is vulnerable to hacking and involves large amounts of user data or ecommerce.   At a minimum, these type of sites should have maintenance planned into development plan. For my production sites, I plan on minimum of 4 hours of work every two months.

At Compton Communications, we plan six months of maintenance into site development.  I have found that for Drupal 6 sites, I will have a minimum of 15 contributed modules with code changes and 3 contributed modules with security updates in a two month period.  In a three month period I can count on at least one core upgrade.

For production sites that I am continuing to maintain, I apply security updates and upgrades at least monthly.  I also maintain test sites for each of the production sites.  The test sites allow me to apply changes and then test to make sure the changes do not modify significantly the operation of the site and that key features continue to operate properly.

One caveat, if you apply changes to the theme CSS or page templates, updates to themes can wipe out those changes.  Most better themes use a CSS changes file so that you can upgrade without having to redo CSS style sheets.  Do not apply CSS changes to core module style sheets as those changes will be lost with any upgrade.

For the maintenance process, I always apply contributed module security updates first to the test site, run update.php, and test major pages and features.  Next I apply the contributed module code changes, run update.php, and test major pages and features.  Hardest part of updating contributed modules is with modules that have plugins such as CKeditor or JQuery_UI.  These modules need to be rebuilt with the plugin added back to the contributed module directory.  I do these type module updates and test separately.

The last part of the maintenance process is to upgrade the core module.  Drupal 6 is now at upgrade 20.  I use the files only update method since it is easier that the standard method of deleting the files for the entire site and then FTPing the new upgraded core and adding back the sites directory.  If you have 20 or 30 contributed modules, the FTPing can be time consuming on most servers.  With the files only method, you merely FTP the changed files to the server.  You can find the files only upgrades on the XLEcom site – http://xlecom.com/?q=node/5 .

On production servers,  removing the contributed module directories by FTP can be time consuming.  Look for a file manager control panel for the server that allows for simpler deletion of directories. You first action on production servers should be to put Drupal in maintenance mode so you do not have users attempting to use the server while updates and upgrades are in progress.