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 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

FROM node_revisions
WHERE body LIKE '%getnodecount%';

And edit the offending nodes in Drupal with a URL such as

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…”