分类： 系统运维
2009-04-23 11:08:26
Joomla has been my primary content management system since it branched from Mambo in 2005. Since then, I’ve come to realize its shortcomings fairly well, so here are 10 things Joomla could fix to become a better content management system.
Every article must exist within what Joomla calls a “category”, and you only get to choose one. Every “category” must exist within one “section”. For the sake of confusion, I’ll refer to these as Joomla Sections and Joomla Categories. Joomla Sections and Joomla Categories are both essentially just categories or folders: one parent category (Joomla Section), and one child category (Joomla Category). So you end up with something like this:
Not only do your articles need to have two categories (one Joomla Category and one Joomla Section), they can only have two categories. Smaller sites with less content will find themselves creating redundant Joomla Sections to meet the two category requirement, while larger sites with more content will have to sacrifice proper categorization and and force articles into a confusing, underdeveloped categorization structure.
It would suck to be the guy who categorizes the movies at Blockbuster, because the movie Tremors is really funny but technically it’s a horror film. So which section do you put it in if you can only pick one? I personally would be very conflicted. Joomla is the same way, you can’t pick multiple categories to put your articles in.
The core files that will be used to display your articles and article lists are littered with depreciated attributes, illegally nested tags, and other HTML errors that will prevent your site from validating if using strict mode encoding. Unless you intend to use transitional mode encoding, you must override the default output using the Joomla provides.
This one may be debatable. I suppose it’s a question of how much flexibility is too much, and is it worth the sacrifice of simplicity. If you intend to template the way your articles and article lists appear (not to be confused with the template for the overall layout of the site) you will need to using Model View Control (MVC). Obviously there will be a learning curve for any templating API, but more so with MVC because its greater flexibility comes with greater complexity. I suppose your appreciation of this feature will depend on the complexity of the templates you intend to design. I’ve personally found all the templating functionality I need in other content management systems without the use of MVC.
Joomla has over 4,000 extensions including components, modules, and plugins. Out of all of the extensions I’ve tried, I’ve only found a few that provided the functionality I needed right out of the box. You’ll either end up writing your own extensions, using multiple extensions to compliment the limitations of the other, hacking the core of the extension, or pulling out your credit card to buy the only extensions that seem fully developed: the commercial ones.
I first ran into this problem trying to find a decent events calendar, and then again with a decent drop down menu, and again with a commenting system. I eventually noticed that most of the decent extensions seemed to be commercial, especially those that provided functionality that Joomla should already have. It has been rumored that the lack of core functionality was a design decision made by the developers of Joomla so they could later profit from the development of commercial extensions. True or not, I find it frustrating that I have to pay to get the functionality I need from Joomla that other content management systems provide right out of the box.
Right out of the box you need to install:
It’s one thing to provide an API that will help developers create extensions, its another to create a whole new “Joomla” programming language. This is especially evident in Joomla 1.5, where you feel like you spend more time referencing the documentation for the API than coding your extension. I’ve found myself bypassing the API all together in some instances, which if nothing else, proves that most of the functionality provided by the API is unnecessary. There is such a thing as too much encapsulation, which often leads to a constrictive and bloated development environment.
Settings for Joomla are scattered all throughout the site. For example, some of the settings for the way article listings are displayed are in the menu manager, some in parameters in the article manager, some in parameters in the articles themselves, and some in the global configuration. The lack of organization makes it very difficult to manage the settings in your site effectively.
I’ve often felt as though the complaints of Joomla community have gone somewhat unnoticed, especially the complaints about the categorization of articles, which have been around for several years. I’ve always appreciated the way WordPress and Drupal have been responsive to their community. Requests for additional core functionality and bug fixes are addressed very quickly. It’s clear that the developers lend a listening ear to their community before they begin development on the next release, which has produced two the best content management systems to date. As the developer of the NextGen Gallery plugin for WordPress put it:
… before I started writing the plugin, I studied all photo and picture plugins for WordPress.
With such great design philosophy in their development community, I haven’t had to modify a single core or extension file in WordPress or Drupal since I’ve been using them.
