As explained in Part 1 of this series, a Drupal Lemon is a disaster site which needs to be rescued (or, really, re-built). In this installment, I'll observe types of lemon sites and how to recognize a lemon.
elkit via flickr
A few of the different varieties of lemons:
If a site has horrendous usability problems, it indicates that it was not built by professional web developers. Why do I make this claim? The entire purpose of almost every website is for human beings to use it. A developer who does not focus on usability is therefore not a web developer, in much the same way as many designers assigned web projects are not web designers.
The infested lemon is one with a lot of bugs. There are error messages on the screens, a watchdog full of errors, and pages on the site that whitescreen. A developer who sees bugs but continues working around them is a frightening force. Imagine how his home looks if he uses this same philosophy toward household pests. Personally when I see a bug I squash it. I don't wait for there to be hundreds of bugs and then fix them all in some "QA period" that may never come. When bugs are allowed to persist they become more difficult to track down; their origin cannot be recalled, and they may interact with other bugs. Web development is complex work and should be done in a metaphorically sterile environment.
I'm a Drupal Fanboy! I drink the Kool-aid! Everything Drupal smells like roses to me!
The Fanboy Lemon has lots of junky contributed modules because its creator believes more is more when it comes to Drupal modules. This fanboy has not learned to be skeptical and discriminating with contributed code, reviewing unknown code and seeking experienced recommendations. These sites have too many modules enabled, some of which are probably not being used at all, and several of which are buggy or even insecure. The administrative experience is cluttered and the site is slow. No one can figure out how it's all glued together.
The Desperado's problem comes from the opposite sentiment. This developer hates Drupal and resents having been forced into working on a Drupal project. She refuses to engage the community to learn about best practices in module usage and the phrase "The Drupal Way" just makes her cringe. Therefore she writes lots of custom code (appearing to be working very hard) to work around what Drupal does, not really knowing what that is. These sites typically have completely broken Drupal in that key features you have out of the box no longer work, making the site basically less good than a brand new install.
Site owners experience various symptoms of problems in their Drupal site. Sometimes the symptoms are caused by a serious disease, but other times they are relatively easily fixed. Symptoms can arise from any or multiple layers of the stack. Some of the symptoms site owners will report include:
- Staff usability problems
- Public usabilty problems
- Performance issues
- Security issues
- Missing features
- Lack of robustness / difficulty expanding
- Inability to upgrade
A lemon can cause any of these symptoms. Of them, those most closely correlated to lemon-ness are staff usability problems (staff usability is closely related to the content architecture), lack of robustness, and inability to upgrade. A site can have serious problems, such as 5 second page loads or show-stopping bugs, that are actually easily fixed in a non-lemon scenario.
Some easy to spot indications that a site may be a lemon:
In addition to the Fanboy Lemon's Just-another-module syndrome, other types of Too-many syndromes include Over-templation, Content-typitis, Role-mania, and Block-a-modium. Adding is easy, but taking away is harder, especially when no one can remember why things were added or whether they are being used.
Lack of semantic sense
If the content types are not really types of content or the user roles don't represent permissioned roles on the site, the site build doesn't make semantic sense. For more on that topic, see my talk on Semantic Site Building
Use of the PHP input format
AKA the red flag of Drupal core. If the site functionality is made up of snippets of PHP in blocks and nodes and views headers shoved into the database, the prognosis is poor.
Going around the Chain of Command
The chain of command for most customization goes in the following order:
- Drupal configuration
- Custom PHP
- HTML (template) change
Often a Lemon that was been developed for months has less features than Drupal core out of the box. This is because it has broken the configurability of Drupal. For example, Drupal core out of the box lets you add new fields to content types and configure their output. Does your site still do that, or do you now have to edit a template file to include the field programmatically? If the site has configuration screens which no longer do anything, or worse, may break the site if used, the integrity of the CMS is not intact: it's suffering from a Drupal violation.
A more famous Drupal violation is hacking core or contributed modules. If your site's code has been edited from what was downloaded from drupal.org (without the accompanying process of maintainable patching) you can no longer perform security updates. It's also an indication that the site builder had no thought to site maintainance, which will mean there are many other issues.
Drupal has a few important security conventions to follow in the custom modules and theme to prevent XSS and SQL injection attacks. Failure to adhere to these standards is another Drupal violation red flag.