Core Features I Want from the Components I Choose
The “core” components provide several valuable features like tags, versioning, and ACL settings per category. These features are available for integration and use in third-party components, but too often these components ignore them. Here is a list of the ”core” features I look for when I evaluate components. Think about them, and you might find that you want them, too.
I look to the “core” components as models of what I should want from extensions. They are the first to implement features that become standard in Joomla. They represent what we as consumers should come to expect from Joomla components. Extension developers should take note, as well. We can feel confident that these features in “core” will continue to be supported by Joomla libraries. One can study their implementation in core components to learn how these features can be implemented within third-party extensions. We should want them. Developers should want to include them.
Adoption of new features has not been as rapid as one might think. ACL is one example of this. For the first year far too many developers were slow to implement even “basic” ACL, even though it was documented how just 18 new lines of code was all that was needed.
When I evaluate third-party components, one thing I consider is the developer’s approach and track record. If they offer poor support for established Joomla features, I want to look elsewhere. Sometimes I have to compromise until someone builds and offers that “better mousetrap.” In the meantime “core” shows me what that “better mousetrap” looks like.
Here are “core” features that I look for. These features are supported by the Joomla library and can be added to any third-party component as long as the developer grafts in a small amount of code or develops a plugin.
Full ACL (Access Control List)
Joomla’s ACL is very powerful and flexible. It enables us to segment users however we want and to assign permissions to each of these groups.
Joomla provides the ACL framework, but it is the responsibility of each component to implement permissions as well as the level at which it can be segmented. Surprisingly, a component does not have to implement ACL to be listed in the JED. And many that do provide ACL, provide only “basic” ACL support, which is either full access or full denial to the entire component. A rich implementation of ACL allows us to segment actions like create, edit, and delete, as well as segment access by the component’s categories or differing data types. And a component that involves several different types of tasks or data should allow us to segment users into roles. For example, an ecommerce component should include actions supporting the different roles of product management, pricing, inventory, order fulfillment, and payment processing.
What to look for: If the component contains records of data, it almost certainly will benefit from the permissions of “create,” “edit,” “delete,” etc. Are these present? If the component contains categories, does it offer a set of permissions per category? If the component contains differing data types (such as multiple tabs or multiple database tables), you have found a winner if the component allows you to segment access to each of these parts.
Content History (Versioning)
This recent addition to the core was well over-due. Users make mistakes, and everyone comes to expect an “undo” option. Without the versioning feature, once an item is saved and closed, the previous version is lost. But this no longer needs to be – for any component.
The content history feature enables the user to review the history of changes as well as restore to a previous history. The component specifies which fields are to be tracked in the history and which of those are to be shown in the comparison screen. Content history can store and compare any field, not just large blocks of formatted text. So any component that stores field data adds value by allowing its users to review, compare, and restore the archived values of recent versions.
As it is for the ACL, Joomla provides the framework so that the component's developer has just to graft in a small amount of code to implement versioning. The ability to compare and rollback to a previous version is too important to ignore. Developers who provide content history will gain a competitive advantage.
What to look for: Open an item that has been saved. If this data type supports versioning, a “versions” button will appear within the toolbar.
Joomla categories and their capabilities are available for any component to use. They provide for a multi-level hierarchy, category-specific permissions, ordering items within a category, dropdown fields to select a category, etc. Some users of a component might not need a category, but some will, so providing categories is almost always wise. Sometimes a component will implement its own category type, but these seldom add value beyond the Joomla categories. Further, I have seen users struggle to learn the differing and quirky behavior of custom categories that differ from Joomla categories.
What to look for: If a component allows the creation of multiple items, it should allow you to create categories within the component and assign each item to a category. To know if the component is using Joomla categories, open its categories manager – if the URL states the option is com_categories, then it is using Joomla categories.
The recent addition of the tags feature opens new dimensions in grouping items: an item can belong to multiple tags without being restricted to a category hierarchy. Further, any given tag can be assigned to items spanning multiple data types. As long as a component’s developer ties the component into the Joomla tagging system, items of that component will be included site-wide as a taggable data type. Don’t forget that tags can be applied to Joomla categories, as well.
What to look for: The item will have a tags field. To confirm that this is a Joomla tag, you should see an entry for this component within the database table #__content_types. If the component uses Joomla categories, those categories are taggable as well.
When a user conducts a text search, that search relies upon a set of plugins, one for each component it searches. A fresh install of Joomla includes search plugins for content, contacts, newslinks, weblinks, and categories. If a component’s items would benefit by being included in a site-wide text search, the developer serves us better by providing a search plugin for that component.
What to look for: In the directory /plugins/search/, you should see a directory named after each component that supplies a search plugin.
We should assume any update is important –whether it addresses security, bug fixes, or new/improved features. Without auto updating, we require the site manager or ourselves to regularly check the extension’s website. Typically that leads to delays or even complete failures in updating to the latest version. An extension using Joomla’s updater reflects a commitment from the developer to the client.
What to look for: The surest way is to confirm that an extension is using Joomla updater is to look at the database table #__update_sites where the table includes a record for each installed extension that is checked by the updater. Some component's offer Akeeba's Live update, a reasonable alternative to the updater, and these typically have the folder liveupdate under /administrator/components/<component-name>/.
As I write this, microdata is a new Joomla feature slated for release this month in version 3.3. Microdata adds descriptive HTML tags around certain types of content, instilling SEO value. Google recognizes tags for reviews, people, products, businesses, organizations, recipes, events, and music. Many third-party components will likely benefit by leveraging this new feature. Don't expect to see this right away in thrid-party components, but hopefully we'll see microdata used in extensions where its data would benefit.
These two features are more deeply rooted within a component and thus require more work to integrate into a component that lacks them. Each adds substantial value and represents the preferred Joomla approach.
MVC and Overrides
The Model-View-Controller implementation is about more than overrides, but its most prominent value to site integrators is the ability to vary the layout of any given view without fear of those changes being wiped out with an extension upgrade.
Most components claim to have MVC, but some offer poor or custom implementations of template overrides. In some cases the file view.html.php adds formatting to fields or other layout features, and that makes it difficult to override the display of that data. Some components have large layout files which would be more manageable were they segmented into sub-templates. Conversely, some components overuse sub-templates making it hard to know how the subtemplates are related and which sub-template to override. And some components bypass the Joomla approach and implement their own method for overriding layouts.
What to look for: The component should have .php files within its views/<view-name>/tmpl folders. Open these and you should be able to see HTML and the code that displays the content or fields. If you don’t, the developer is probably by-passing the Joomla approach to overriding, perhaps offering a custom alternative. Long layout files typically would be better broken into sub-templates so that you can override just the portion you want. For a “core” example of how sub-templates are effectively deployed, look at the “blog” files in /components/com_content/views/category/tmpl/.
All core components use JForm to declare the component’s fields and their field attributes. These attributes include such things as type, default value, filters to apply on data input, etc. Initially the JForm feature seems to matter only to the developer, but I have found it to provide important value for the site integrator.
With a simple plugin, one can override the XML file that defines the fields. This allows one to change field attributes: setting a default value, making a field required or read-only, hiding a field, setting the filter that screens data input, using a different-but-related field type, changing the root directory when selecting a media file, etc. By overriding the XML file, we can declare additional fields which we add to the database table and to the layout files – all safe from component upgrades. But this capability applies only for components built with JForm, as are all the core components.
What to look for: In the component’s directory (both site and administrator sides), look for a models/forms directory with .xml files named after each view.
As I evaluate third-party components, I look for these features. I expect to see the Joomla MVC implemented correctly, and I want more than just “basic” ACL. The lack of JForms or the use of custom categories suggests to me that either the code base is old or the developer is not as committed to the Joomla approach as I prefer. On the other hand, components released with features like tags or versioning indicates a strong commitment from the developer and a promising future for the extension.
In recent history many components were slow to adopt the new ACL and too few provide search plugins. Without competition or demand from users, it is likely that many third-party developers will be slow in grafting in modern features like tags, versioning, auto updates, or microdata. But these features, which we find in the core components, hold much value for site integrators. Those of us who select and install third-party extensions should be asking the developers for these features. Developers who want to develop that “better mousetrap” can add them to their components.
The valuable features that have been added to the core components set our expectations as to what Joomla can do. Let's not lower those expectations.