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.

Website Anti-Spam


A recent comment requested some additional anti-spam option in our Issue Tracker component. That triggered much though on a topic that obviously impact all website and their components, be it blogs, commenting systems etc.

There are a number of different parts to preventing spam on a website and this is to expand upon our own particular take on the subject.

Spam is one of the many problem that face web sites today. It is basically the proverbial ‘pain in the neck’ and if not handled correctly can be very time consuming. How often have you viewed web sites where there are totally unrelated comments /registrations/ forums posts which has to make one think about the site’s reputation and credibility.

Our site is not immune to this problem and the source is not restricted to any specific country although there does seem to be a preponderance from locations such as Turkey, China, Russian Federation and more recently Ukraine and Brazil.

Continue reading

Joomla Development hints and tips

Whilst working on some Joomla component developments I encountered a few problems which, whilst I had encountered them, before didn’t stop me wasting time resolving them again.  So I have decided to post them to the blog in case others have the same sort of problems and it might save them some time.


1.  In a component item list view, the message ‘ Notice: Undefined property: stdClass::$editor in ~administrator/components/com_xxxxx/views/yyyylist/tmpl/default.php on line zzz’ was encountered.  This message was coming from the template file and related to the check of whether the item was checked out or not.   The item is returned directly from the database table but there was no ‘editor’ field in the table.  

What was required is a simple select over the table with the Joomla users table as follows.

        // Join over the users for the checked out user.
        $query->select('uc.name AS editor');
        $query->join('LEFT', '#__users AS uc ON uc.id=a.checked_out');

Where I was wasting time, was thinking that the ‘editor’ was the actual physical editor being used on the item, rather than the ‘person’ who was the ‘editor’ of the item.


2.  In an item view the JToolBarHelper buttons did not appear to be doing anything other than appending a ‘#’ to the end of the URL.    This one had me a little puzzled since the parameters to JToolBarHelper were perfectly correct.    The problem eventually turned out to be related to some coding in a java script incorporated in the default template.   The error was not generating any messages and it was only by a process of elimination that I tracked it down.

So the moral is to check for Javascript errors before assuming a php coding error !!


3.  The third opportunity was to discover why the use of an Editor (such as JCE) persisted in stripping out HTML code from the input.   I found an article on the JCE web site that explains about changing the text filtering options:

(Joomla! 2.5)

    In the Joomla! Global Configuration, click on the Text Filters tab.
    For the Super Users group, or any other trusted user group, set Filter Type to No Filtering. Make sure that you only set this option for user groups that can be trusted as setting the Filter Type to No Filtering will essentially allow the user to include any html in an article.

However checking my settings showed that I already had them set but I was still getting the HTML codes stripped out.

Investigation into the possible filters that can be applied to the editor field in the XML file for the object revealed a solution.    The possible filters that can be applied (which I discovered from code inspection) are as follows:

 

Filter Type Description
RULES A defined rules array
UNSET Do nothing.
RAW No Filter.
SAFEHTML Filter safe HTML
SERVER_UTC Convert a date to UTC based on the server timezone offset.
USER_UTC Convert a date to UTC based on the user timezone offset.
default Checks for a callback filter using either using the callback method or using the callback function.

 

        
   The solution I wanted was to set the filter to ‘RAW’.         

Lessons to be learnt from RBS debacle?

The recent debacle/fiasco around the RBS banking group has attracted much interest, with various comments made about whether it was preventable and the possible causes.

There have been many suggested causes such as whether this was an ‘accident waiting to happen’, or whether RBS should have retained IT support in-house rather than out-sourcing, a lot of which were by parties with their own self supporting agendas

One thing that did catch our eye was the article that RBS is set to sue the supplier for the problem.  Somehow it would turn our very ironic is the suppliers were insured for liability insurance (which all reputable suppliers are) though an RBS subsidiary.  That really would be something of an own goal, and for a group that is majority owned by the UK tax payer, must raise some interesting questions.

Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries