Well, I've been casting about for a topic to blog about on this day off and I've finally got one that I can get traction with, I think. If you're reading this, then I must have published it. :)
I've been doing a lot of work building Drupal sites of late and I've decided that I really like Drupal for a number of reasons, but I really despise it for others. This is a common theme on my blog: I like things, but there are a lot of things I don't like about the things I like. Well, I'm going to list of my top five Loves and Hates for Drupal 4.7.
Hates
So that I may end on a postive note, I'm going to cover the hates first.
- The documentation is out of date. This can be said for a large number of development projects, particularly those that are run by a community without the influence of much corporate backing. Drupal isn't used widely by corporations as much as it is used widely by non-profits, special interests, and other associations. That's not bad, it just means that there aren't a lot of QA folks demanding proper documentation.
I do want to make some clarifications:
- This issue doesn't extend to the API documentation, which is quite possibly the best documented API of any system I've ever used.
- This is partially a symptom of the fact that there is so much documentation and that development progresses so quickly. It's easy for a document to become outdated quickly and not enough eyes to go back and fix it quickly
Finally, I'd like to suggest that Drupal might be able to help with this problem if they allowed more freedom with editting the documentation content. I believe this is part of the reason the Drupal community would like to see an integrated wiki module. It could certainly help.
- it is hard to determine what capabilities are available and which modules work well. Without a PhD in Drupalology, it's hard to know what functionality is available through modules. Furthermore, since there's no evaluation system for modules, it's hard to know which implementations work well. People should be able to state whether they like it or they hate it. It isn't easy to know which module is a hack and which module is a mature product. It isn't easy to tell who is contributing to or leading the development of which projects. It's hard to tell how active an individual project is.
- Each project must have a single sentence description that is shorter than the teaser provided on the main projects pages. This would help folks find them.
- Project owners should be able to annotate their project with notes showing the development state: pre-alpha, alpha, beta, released, and mature.
- There should be a list of all active project participants with a clear delineation of who is in charge of a project and a better indication of orphaned projects.
- There should be a clear show of updates to the project. When was the last commit? When was the last release posted (shown on the project page, but not part of the summary list)? Frequency statistics would help.
- Drupal suffers from non-developerism. This has gotten better, but one reason why I usually hesitate to use PHP is because the language is so easy to use. Drupal has done a wonderful job of extending PHP into a very easy to use and easy to understand framework.
This is fine, but making a programming framework easy to understand has a price: those who aren't programmers will start to patch it and work on it. These folks may be ignorant of the full ramifications a particular action might have. This doesn't make them bad people, it just means their expertise lies somewhere else. It's no worse than me relying on a mechanic to fix my truck while attempting to do some simple things myself. I could cost myself a lot of money if I started messing around with the wrong pieces. I probably wouldn't know I was breaking things while I did it.
In the case of programming, the cost is the potential for code that is difficult to extend, vulnerable to security issues, and inefficient. A non-programmer may not realize that using nested loops might be a worse idea than serial loops in a particular case. A non-programmer may not realize that using a certain function makes it possible for a malicious user to inject code into the system. A non-programmer may never have heard advanced data-structures to help him choose a better solution through a problem.
In the case of Drupal modules, I've found several look gorgeous inside when you crack them open. Others look like someone implemented the functionality by copying bits and pieces from elsewhere and then just made it work by brute force. Others look utterly horrible. This is the case with any OSS projects, but I've found the range in quality in PHP projects to be a bit wider than say Perl or Java projects. They're simply not as accessible.
This is why the previous point is important. It should be easy to determine whether members of the community like or dislike something and why they have those opinions.
- Taxonomy is underused. Taxonomy is, in my opinion, the coolest feature of Drupal. Using taxonomy, you can carefully control the tags associated with any document in the system. You can set up free tagging (a.k.a. folksonomy) where any keyword or collection of keywords can be associated with a document. You can set up specific hierarchies so that a document must be placed into the tree at some point. You can create relationships between different branches of the tree. You can create synonyms. You can mix an match these in just about any way you can think of.
And yet, taxonomy hasn't been used to facilitate a number of extensions that could have. The best example of extending the taxonomy is the built in forum system. Determining which post a forum topic belongs to is a matter of checking which taxonomy term it belongs to under the forum vocabulary. Forums can be arranged into hierarchies themselves, which are also controlled by the taxonomy. This is very flexible.
However, many other modules have chosen not to use the taxonomy. The clearest example of this is the Organic Groups module. This, in my mind, is a clear and obvious case for using taxonomy. Each group is a term in a taxonomy vocabulary. If a site wants nested groups, they can do so by making the vocabulary hierarchical. If they want related groups, they add those relationships in the taxonomy. If they want groups that have multiple parents, they can do that. If they want a plan flat system, they can do that. Other examples include the Book module, the Workflow module, the Voting API, and the CCK.
The taxonomy system is beautiful and it should be used more. I can only think of two reasons why it isn't:
- The taxonomy system isn't easy to comprehend and requires some planning to take advantage of properly. Since it isn't easy, that could be an obstacle, though it shouldn't be.
- The taxonomy system is pretty weak. As it comes, it doesn't have anything but the ability to create structure and attach documents into that structure. Which leads me to my next and final hate...
- The taxonomy system is underdeveloped. This system should have been massively enhanced long ago. There is an excellent improvement to the taxonomy system in the Category module. This enhancement replaces the Taxonomy and Book modules with a new system that elevates every vocabulary and every term to first class citizens: nodes. The Category module allows for much greater flexibility and allows you to treat any term as a node, which has the added benefit that it can now be assigned full-text values.
In addition, I think there should be an enhancement to the Taxonomy (or Category) to allow for values to be associated with a term. This would allow for an even more flexible way of implementing the features of CCK or the Voting API. In fact, with a combo like this, you wouldn't really need much of anything other than Taxonomy, Node, and Forum. This is probably a little radical, but I really like the idea.
Loves
Okay, now that I've exposed why I don't like it, let's consider why I still use it anyway.
- It's under active development. This is the most important selling point for any piece of software I use. If there hasn't been a change to the code within the last year, I will look for something else. If there hasn't been a change within the last month, I start to worry. Open source projects should continue to update on a very regular basis.
Drupal is one of those projects that if you forget about it and come back in a year, you have to take some extra time reading about it to catch up. It's not just that those two or three key things you really wanted got put in since you last looked, but that a dozen new features were added and a couple of them are really cool and you hadn't realized how cool until you realize how they work. That's what Drupal has been like for me over the last year.
I don't necessarily agree with some of the direction they've chosen, but when do I ever agree with all the decisions other developers make? I, of course, know better than they, but I must be patient since not everyone can be as brilliant as me. :P
- It's got an active community. There are very few posts to the online forums that go unanswered unless the question is completely out in left field or already answered if they'd use the subject line to search instead of creating a new post (of course, I see a lot of those answered with somebody saying "Already answered, look at these links"). Sometimes the answers demonstrate a completely lack of knowledge, but there is an enthusiastic community.
In the case of Drupal (by my perception, someone else's might be different), there's not a lot of criticism when someone writes a dumb answer to a question or asks a dumb question. In a way this encourages stupid questions and answers, but it also means that the community is willing to help newbs. This is refreshing, since many OSS communities eat their young (another one I participate, in particular, summarily executes the newbies on a regular basis).
- Easy to understand/extend/install. You can know just enough to purchase a hosting service and then drop the files into place and you're practically running. If you use CivicSpace, the deployment doesn't even require messing around with any SQL scripts, if I recall correctly.
After installation, turning modules on and off is very easy. Adding new modules might be a bit of a chore, but once you get the files unpacked and FTP'd to the correct place, that's generally pretty easy too. Configuring modules is also very easy once you find where the options are held (harder than modifying the actual configuration).
To extend Drupal, you just design a new module or tweak an existing one. This is generally very easy as well. This has the caveats I mentioned above as being a little too easy. However, overall, it's really a cinch to do most things.
- There are lots of documentation and examples. I mentioned that the documentation is a bit out of date in a lot more places than it should. On the other hand, there's just so much documentation. There are examples showing how to do many common tasks. There's documentation covering several theme customizations, starting custom modules, tweaking various things, etc.
- The system is extremely flexible. Want to do something with Drupal? There's probably a configuration option, a module, or a module setting that does that. If it's something unusual, you can probably arrange it by combining two or three add-on modules in various ways. If it's way out there, you could surely do it with a little bit of custom development because the module system is fantastically easy to put to use.
All in all, I like Drupal. It's not my favorite CMS system ever, but it's my favorite that is under active development. Now, if only it were written in Perl....
Cheers.
