Drupal versus Proprietary Web Content Management Systems

With any Web content management system, you’ve got to budget for continued support, training and improvements. After more than ten years’ experience setting up sites, and moving content between straight HTML, to writing my own customized content management system, to migrating to custom enterprise systems, including proprietary systems, and now to Drupal, I’ve found that the smart money in Web content management goes to systems that are open source, and broadly supported by the community.
We used to suffer from being “locked-in” to proprietary systems, and our vendor would milk us for all they could, or nickle and dime us to death… but now, since Drupal’s software and security improvements are free for anyone to download, all we pay for is great service. That’s what Drupal vendors compete on; they can’t lock you in.
Proprietary Web content management systems are basically fighting for their lives right now, and are working hard to find a niche where they can survive — so they’ll say anything to get you stuck to their product. This is called “vendor lock-in.” Once you’re in those systems, how do you escape? Your choices are limited, since the number of “partners” is likely nowhere near as big as the number of shops supporting Drupal now, and in the years to come. How big is your proprietary system’s development team? Drupal 7 Core had nearly 1000 contributors, and the number of folks working on Drupal contributed modules is now up above 23,000.
By the way, almost 6000 modules are available for Drupal 7, the most current version. Drupal is widely supported by a huge, vibrant community and is currently installed on over a million Web sites (see http://www.drupalshowcase.com/ for some examples).

Drupal Security Team response to bogus 7.12 CSRF issues

“The Drupal Security team has concluded that this does not constitute a valid vulnerability. The attack depends on a ‘Man In the Middle’ attack or sniffing software, which is outside of Drupal and presents a much bigger problem.

The Drupal Security team provides an easy way to report issues by sending emails to security@drupal.org, and we will credit researchers with all issues they report in this manner. No formal report of this issue was filed directly with our team. We encourage all researchers to follow the practice of responsible disclosure, and report directly to our team to ensure both that we can provide public credit for authentic vulnerabilities, and keep our users as secure as possible.”

Well, there ya go.


Drupal very popular for observable “dot gov” .gov sites

Drupal has been steadily growing in popularity among live “dot gov” domains. According to one analysis, it powers nearly twice as many of those .gov domains as all other CMSs combined — though 93% of those run no detectable CMS. The analysis is currently being updated.


Enabling Apache’s PHP execution in User Directories on Ubuntu Lucid

Ubuntu Lucid ships with PHP disabled for user directories. That’s a sensible security default, but it won’t allow your developers to get their work done. And if you’re working with Drupal, you’ll need all the steps listed here.

First, you’ll need to install Apache:
sudo apt-get install apache2

Then the compiled PHP binary (or “shared object” in Apache lingo):
sudo apt-get install php5

You may need to do sudo /etc/init.d/apache2 restart or sudo service apache2 restart to have it pick up the updated configuration file that loads the PHP5 module. Try visiting your own box at “localhost” to see if you get a nice “welcome” page. You can put an “info.php” file in /var/www to test if PHP is working (the contents of your info.php file are simply <?php phpinfo(); ?>), and visit that in your browser.

Once you’ve gotten PHP running under Apache, edit /etc/apache2/mods-available/php5.conf and comment out the lines as instructed:

<IfModule mod_php5.c>
    <FilesMatch "\.ph(p3?|tml)$">
        SetHandler application/x-httpd-php
    </FilesMatch>
    <FilesMatch "\.phps$">
        SetHandler application/x-httpd-php-source
    </FilesMatch>
    # To re-enable php in user directories comment the following lines
    # (from <IfModule ...> to </IfModule>.) Do NOT set it to On as it
    # prevents .htaccess files from disabling it.
#    <IfModule mod_userdir.c>
#        <Directory /home/*/public_html>
#            php_admin_value engine Off
#        </Directory>
#    </IfModule>
</IfModule>

If you’re developing with Drupal, the following step may also be necessary: In /etc/apache2/mods-available/userdir.conf, you should allow Drupal’s local .htaccess file to override the Apache-wide configuration file, with:

(...)
        <Directory /home/*/public_html>
                AllowOverride All
                #AllowOverride FileInfo AuthConfig Limit Indexes
                #Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
(...)

Restart Apache with sudo /etc/init.d/apache2 restart and you might be done!


Drupal fatal error: cannot redeclare function()

Ever seen this when in Drupal’s administration pages?

Fatal error: Cannot redeclare getnodecount() (previously declared in /var/www/sites/site.org/htdocs/includes/common.inc(1685) : eval()'d code:3) in /var/www/sites/site.org/htdocs/includes/common.inc(1685) : eval()'d code on line 9

There are a few causes for this, as mentioned on drupal.org, but the one in which you might be interested (because your error message looks more similar to mine, above, than to the drupal.org documentation) is when PHP is actually contained in a block or node body. That’s something you should suspect if you see the above error message referring to PHP’s eval() function.

To fix this, do something in MySQL like

SELECT nid
FROM node_revisions
WHERE body LIKE '%getnodecount%';

And edit the offending nodes in Drupal with a URL such as
http://example.com/node/123/edit


whitehouse.gov moves to Drupal, recovery.gov migrated from Drupal

Whoops! Chris Wilson had one good point, but some big misses in this article. I guess this is a danger for a writer — for example, the “PHP” input filter setting allows JavaScript by default, but Chris didn’t select that setting.

The biggest problem is that he claims that Drupal is impenetrable, which it is. For many beginners, it has a steep learning curve. But he never makes the connection; why do your site visitors care? If millions of them appear, and your site continues to work well in response because it was built with a solid operational foundation instead of being built with something that has a cute-but-heavy GUI on the backend, don’t they benefit? It looks to me like Chris has unfortunately conflated the needs of end-users with the needs of site developers.

Also, I’d like to take my hat off to the organization that landed the $18M contract to migrate recovery.gov into Sharepoint. That’s a lot of money for a site built using tables in HTML and containing leftover hidden cruft like “this Web Part Page has been personalized. As a result, one or more Web Part properties may contain confidential information. Make sure the properties contain information that is safe for others to read. After exporting this Web Part…”