Macrotone Blogs

Macrotone blogs upon Joomla, our products and other matters.

Implementing Joomla 3.1 Tags feature

J3.1-Transparent-bgWe originally implemented the Joomla 3.1 tags feature within our Issue Tracker component. This was done using the documentation[1] by Elin Waring the originator of the feature.  This worked fine until Joomla 3.1.4 was released when it changed to use the JObserver classes.

The basic change (as we understand it) is that the tag fields were originally stored within the ‘metadata’ field where as using the (new) JObserver class removes this requirement and the tag is not required to be saved with the item at all. Both methods were intended to be supported but the implementation is broken, but may well be fixed in a later update.

We found another document[2] describing the modified configuration/setup. The problem was we couldn’t get it to work as it was described.

We eventually found a solution which is as follows.

1) In the components table class we added the following line:

JTableObserverTags::createObserver($this, array('typeAlias' => 'com_xxxxxxxxxx.yyyyyy'));

Where the component is xxxxxxxxxx and yyyyyy is the tag type.  (The differs from the suggestion in the documentation[2] which we couldn’t get working.)

2) Double check the field mappings which get placed in the #__content_types table.  The configuration document[2] shows square braces in the string but these are not required or necessary.  It is also important that the field mappings accurately match the fields within the referenced table.  A small mistype or wrong name will result in an error being generated when the tab is saved.  It doesn’t help that the error message only tells one that an error has occurred not what the actual error is.  We found out through trial and error. [We note that there are a few other fields in the #__ucm_content table that can also be populated, notably the created_by_alias.]

3) We also found that we required the following in the getItem method of the model (despite the documentation[2] saying otherwise).

$item->tags = new JHelperTags;
$item->tags->getTagIds($item->id, 'com_xxxxxxxxxx.yyyyyy');
// $item->metadata['tags'] = $item->tags;

The last line we have commented out since we do not observe any impact of it being present.

4) In one of our tag types we were using the table class method called directly, calling the various bind, check and table store methods. This meant that some code that is required to handle the tags did not get called.  The easiest way we resolved this was to instead call the parent:save  routine. This was achieved by slightly restructuring the model save method and also meant that we didn’t have to add additional code and also enabled us to simplified our code.

5) The other change we made was to the 'Hathor' template view overrides to display the tags. Again the suggestion in the documentation[2] didn't work for use and we resorted to the standard display mechanism.

Considering Metadata for our Joomla extensions

The use of Metadata within web pages to provide a ‘richer’ and more tailored data structure is not new.  The term metadata is defined as "data about data". The term is however slightly ambiguous, as it can be used for two fundamentally different concepts (types). Structural metadata is about the design and specification of data structures and is more properly called "data about the containers of data"; descriptive metadata, on the other hand, is about individual instances of application data, the data content. In our context we are really talking about ‘data about data content’.

We say it is not new because many years ago we worked upon implementing some of the ‘Dublin Core’ metadata into some specific sites that we were working with.  The focus now seems to be the use of the vocabularies as defined by ‘schema.org.  This is no doubt influenced by the fact that it was promoted by Microsoft and Google themselves.

Deciding to implement it is not for the faint hearted especially if the ‘intended’ target is composed of entities that do not easily fit into one of the defined ‘standards’.  As an example we have looked at our ‘Problem/Issue/Bug Tracking’ application.  At first glance it looks to be a ‘Product’, but the products are those that are sold, or available to hire etc.  The output from our ‘Issue Tracker’ is a set or series of ‘reports’ which describe reported problems or improvement tasks for a ‘product’ hence perhaps they should instead be an ‘Article’.  Here again they do not really fit into the current ‘standard’.  The best we can come up with would be a ‘CreativeWork’, and more specifically a ‘SoftwareApplication’, but even here we would need to add some specific custom extensions, which is possible with ‘schema.org’ to more accurately reflect information that should be in the meta tags. We require the metadata to describe the output from the application and not the application itself.

At the moment the jury is still out as to whether we wish or desire to add an automated mechanism to our application to generate the meta data automatically.  We will probably continue to monitor the situation before deciding whether to implement it as a feature or not, especially as it is not certain whether including it will improve the page rankings within Google, since the exact details of the algorithm used by Google is their secret.

Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries