We have noticed many attempts to access our site with the purpose of adding dubious material or to gain control of the site from all over the world and indeed have even made blog entries upon the subject.  In an attempt to better understand where these attacks are coming from we have developed a Joomla component which shows the source of the IP addresses upon a Google map.

Be aware that the specific IP address has been identified as the location of the attack, but the person behind the attack may be located in a different location.  Prolific spammers bounce around the world and use IP addresses other than their own.  For that reason care should be taken before making any decisions based on the data.  

The results for the last 15 days are displayed below.

SPAM attempts

Spam attempts are where some one has attempted to add comments or entries which have no relevance to the site contents.  Typically these are advertisements for products. The list incorporates entries obtained from the Project Honeypot black list.

These results exclude persistent offenders who we have blocked for persistent attempts to submit SPAM.

Loading map...
IP Mapping by Macrotone Consulting (UK) Ltd.
Date Country City Referer

These displays are generated by our own IP Mapping component which is available in the download area.

This article started off as a Blog entry but as things have been discovered it was decided to make it a full article.  It describes the changes that have been made to our extensions as a result of enabling them to run under Joomla 3.0.  When we are satisfied that the extensions are fully tested we will release updates to the wider community. Some of the changes required were the result of features deprecated in earlier versions which only now have started to bite.


Joomla 3.1 Observations
Joomla 3.2
Supporting Joomla 2.5 and 3.x in one component.


There is a document listing backward compatibility issues with Joomla 2.5 and the Joomla Platform 12.1. Also this link.

Description of 12.1 MVC framework is here.

Some of the following changes have been identified in the document referred to above, but others are the result of our own testing. So far we have discovered (and made the following changes):

1. In the Joomla! 3.0.0 version get an installation error that shows Directory separator constant DS error. Solution is to add the following code:


This is still present in the full release as well.  This code has been added to all of the files where required.

2. Seems that JController::getInstance is no longer around. Need to use JControllerLegacy instead.

The old JController, JModel and JView classes have been renamed to JControllerLegacy etc.

The ‘new’ JController,JView, JModel are now classes in the new MVC implementation.

The solution is to use the legacy classes.

The following code does work:

$jversion = new JVersion();
if( version_compare( $jversion->getShortVersion(), '2.5.6', 'lt' ) ) {
$controller = JController::getInstance('IssueTracker');
else {
$controller = JControllerLegacy::getInstance('IssueTracker');

However there are numerous places particularly with class definition where we refer to JController, JView and JModel where such a construct will not work which will all require changing.

So in the situation of a moving 2.5 extension to 3.0, we have to

    1. modify JController::getInstance to JControllerLegacy::getInstance in master component file.
    2. modify extends JController to JControllerLegacy in master/default controller.
    3. modify extends JView to JViewLegacy in all view classes.

In the general case, we have to change JController to JControllerLegacy, JModel to JModelLegacy and JView to JViewLegacy. [We have only found once instamce where the change to JModel has been required.]

3. JHtmlBehavior::mootools not found.

Use JHtmlBehavior::framework instead.

This includes constructs such as : JHTML::_('behavior.mootools'); which becomes: JHTML::_('behavior.framework');

4. A few database class routines have changed.

Instead of $db->nameQuote we have to use $db->quoteName

and instead of $db->getEscaped we use $db->escape

Also JDatabase::loadResultArray() has been removed. Use JDatabase::loadColumn() instead.

5. The library routine jgrid has moved its directory. It was formally in libraries/joomla/html/html/jgrid.php

It is now located in libraries/joomla/html/jgrid.php.

Update for 3.1.x, seems it has moved yet again, now located in libraries/cms/html/jgrid.php

6. Our templates do not display nicely in the Isis template with a lot of items overlapping. Thus there is a need to rework our displays. [See section below on handling both templates.] Hathor template looks OK (as far as it goes!) Seems that the adminlist class has been replaced with the table class (from code inspection). Also the 'btn-group' class has replaced classes such as filter-select, and there are pull-right and pull-left classes as well instead of fltlft and fltrgt.

Note: A number of these changes are related to the change to use BootStrap templates.

These changes have been handled by extending our use of the css definitions file, introducing our own table class.  [Note that we have also introduced colour coding for priority and these are handled in the css classes as well.]

7. JDate::toMysql() has been removed. Use JDate::toSql() instead.

Change: $get_date= JFactory::getDate();


To: $get_date=JFactory::getDate();


8. JUtility::sendMail() has been removed. Use JMail::sendMail() instead.

9. JUtility::sendAdminMail() has been removed. Use JMail::sendAdminMail() instead.

10. JDatabase::query() is deprecated, use JDatabaseDriver::execute() instead.

Change: $db->query();

To: $db->execute();

11. JFile::read is deprecated. Use native file_get_contents() syntax.

Change: $textfile= JFile::read(JPATH_COMPONENT . DS . 'text.txt');

To: $textfile=file_get_contents(JPATH_COMPONENT.DS.'text.txt');

12. JRequest is deprecated. Use JFactory::getApplication()->input

See: http://docs.joomla.org/Retrieving_request_data_using_JInput

Change: $post=JRequest::get('post');


To: $input =JFactory::getApplication()->input;



Change: $task= JRequest::getVar('task');

To: $task=$input->get('task');

Change: $groupid= JRequest::getVar('id');

To: $groupid=$input->get('id');

Change: $limitstart=JRequest::getVar('limitstart', 0, '', 'int');

To: $limitstart=$input<->get('limitstart','0','INT');

Change: $controller=JRequest::getWord('controller');

To: $controller=$input->get('controller');

Change: $controller->execute(JRequest::getCmd('action'));

To: $controller->execute($input->get('action'));

13. JViewLegacy::assignRef is deprecated. Use native PHP syntax.

Change:  $this->assignRef( 'userlist', $userlist);

To:  $this->userlist=$userlist

14. JParameter is deprecated.

Change: $retval [] = new JParameter(JPluginHelper::getPlugin('system', 'passwordcontrol')->params);

To: $plugin = JPluginHelper::getPlugin('system','passwordcontrol');
         $pluginParameters = new JRegistry();
         $retval [] = $pluginParameters;

 15. A number of function calls have been changed to resolved warning messages encountered when site reporting is set to 'Development'.  Most of these involve removing the '&' from the the calls to JFactory etc.

16. Discovered that modal windows are not opened and a full window is presented if the XML description text contains a window link when a plugin is installed (or displayed in the plugin manager).  In Joomla 2.5. the self same code opens a modal window, but with the Isis template a full window is opened.  We are using the modal window to display a changelog for our plug-ins.  Not a show stopper but slightly annoying never the less. Resolved by adding JHtml::_('behavior.modal') to template.

17. Review usage of jimport.  Should we be using JLoader::import instead?  jimport is a simple wrapper around the JLoader call and has been there since Joomla 1.0 but does it have a future?

18. Seeing the following message with using the search mechanism:

Notice: iconv() [function.iconv]: Wrong charset, conversion from `UTF-8' to `ASCII//TRANSLIT//IGNORE' is not allowed in /J31/administrator/components/com_search/helpers/search.php on line 233


Handling both Isis and Hathor admin templates

With the change to using bootstrap in the Joomla back end, provides a new 'opportunity' to have to support two possible admin templates.  If one converts all the views to use bootstrap so that Isis displays are correct. they do not display correctly if one uses the Hathor template. 

The answer is of course to make use of template overrides. Fortunately the 'old' templates designed for Joomla 2.5 display corrrectly with only a few minor changes in the Hathor template.

It is desirable to install the Hathor template overriides when the component is installed, and likewise remove them when the component is uninstalled.  There does not appear to be any way in which one can automate this process using the standard manifest file.  Instead it is necessary to perform the task within the 'installation script' itself. This works well with our components and is relatively easy to implement.

Of course changes would be required if any of the 'new' Joomla 3.x features are required, such as tag support.

Note that the JHtml tabs work with the Hathor template but it is necessary to use the JHtml bootstrap panes with the Isis template.

Joomla 3.1 observations

  1. Observed that the use of the JHtml:: bootstrap tabs has changed between 3.0 and 3.1. This resulted in the 3.0 changes failing in 3.1.  Most of the documentation still refers to the 3.0 code base, and has not yet been modified for Joomla 3.1. With the official release it has changed yet again. Instead of using bootstrap.startPane use bootstrap.startTabSet, instead of addPane use addTab, etc.

  2. Tags component is nice and reasonably easy to add to our component. [Pity in one way that it keeps changing between each beta release, but such is the way with beta code. :-) ]. Tags support doesn't seem to be present in base components with Hathor template!

  3. Looks like tags implementation has changed again in 3.1.4/3.1.5 since it now appears be be using observer.  More changes to make, so much for backward compatibility. 3.1.2 worked fine with our Alpha release. A fix is supposedly being developed for Joomal 3.1.6/3.2(?) but it is easy to modify the existing set up just by changing the Table class as described in this document.

  4. Differences between protostar and Beez 3 templates means that chosing a style that is consistent with both is difficult.

  5. Legacy View problems in 3.1.4. We do not currently think this affects our components. See this post for more details. There is expected to be a 3.1.5 release shortly, but in the meantime this fix may help.

  6. When reporting is set to 'Development there is an undesirable side effect that the size of the displayed text in list and item views is reduced to almost being impossible to read.

 Resolved Problems

1. Front end column sort did not seem to work in Joomla 3.1. Even the distribution base components (i.e. contacts) didn't sort.  Code call to Joomla.tableordering was suspected to be the cause. Works in back end fine.  This was tracked down to an undefined variable causing a Java exception.

Resolved: This was determined to be a problem with the underlying component templates not setting the undefined variable. It seems that Joomla 3.1 is not quite as forgiving as Joomla 2.5 in the templates defined.

Joomla 3.2

Whilst still in Alpha state, the following may not be present in the released version but it is worth noting the issues found so far.

1. The Smart Search Finder component is not working. No error messages just doesn't index anything.

2. The change to the new TinyMCE edit 4.0 has resulted in the back end edit boxes being full size with no apparently easy way to specify the size (height and width). This means that when there are two or more editing areas on a page then all occupy virtually a whole screen to each editor window. Very messy.

3. Using calendar type produces error:

Notice: Undefined index: class in /J32/libraries/cms/html/html.php on line 967


Supporting J2.5 and J3.x in one component

Have spent some time now working on integrating a Joomla 2.5 version and a Joomla 3.x version of our componnets into a single package.

There are a number of changes to consider but these break down into a few places as described below. There may be other places which depend upon the actual structure of the components but these were the ones that we determined for our components.

1. The changes nearly all involve the back end, which reflect the changes in the admin templates.

2. The changes can nearly all be allowed for by adding code of the following type:

$jversion = new JVersion();
if( version_compare( $jversion->getShortVersion(), '3.1', 'ge' ) )
   // Joomla 3.x code.
} else {
   // Joomla 2.5 code

3. The places to change fall into a few areas:

    1. In the helper files which display the list view menus in the sidebars.
    2. In the views where we need to change which template is being displayed.
    3. Alternative view templates (i.e default.php or default25.php).

4. Changes relating to the 'moving' of core files.

    1. Typically we have had problems with the moving of 'grid' support files.


The Password Control System Plug-in is the first step in what is intended to be a comprehensive control system for Joomla passwords.

This extension is intended to introduce some security into the users access into Joomla. Currently as released Joomla has only a simple user name and password mechanism but there is no checking of the password itself once it is defined and it could easily be the same as the user name.

The documentation is available as web pages and as in PDF format which covers all releases. For the current release it is also available as a separate document on the web site as indicated below.

Release Versions

Release 0.1.4

Minor enhancement release to extend the control over who is required to change their email address upon initial login. Also add an additional check for Joomla 3.4 where we are in edit mode but the layout field is set to null.

Release 0.1.3

This release adds a new requested optional feature which is to force the user to change their email address upon their initial login. Some components such as eshop virtuemart, have a situation where sites such as cosmetics saloons will give their customers free logins. They create a number of logins with usernames such as the name of salon + number of client, password 12345 and with a created email similar to This email address is being protected from spambots. You need JavaScript enabled to view it.. When the user logs in there is a need to force the customer to change their password, and we have introduced the option that forces the mandatory email change on first login.

Release 0.1.2

This release supports the use Joomla 3.3 which introduced more encryption mechanisms. If also has been modified to allow for Joomla 3 user password reset required flag. Other changes include altering the defaults to use JQuery-ui version 1.10.4, and jQuery 1.11.0. Modifications were also made to the checks when a password change is required.
It also introduces the ability to hide some of the other user profile fields such as the email, username and name fields, and permits the addition of an informative text area field to display some helpful text to assist the user in entering their password.
Due to a coding conflict between jQuery-UI dialog windows and mmenu (a jQuery plugin for mobile menus) the ability to use an alternative jQuery bootstrap dialog plugin was also added.
Another change is to extend the exemption checks in the onAfterUserSave event to permit password reuse for exempt users.

Release 0.1.1

This release supports the use of the 'new' PHPass encryption mechanism present within Joomla 2.5.18 and Joomla 3.2.x. It also fixes the placement of the generator button to the revised 'User Profile Edit' screen in Joomal 3.2.

Release 0.1.0

This release adds the long awaited checks upon users password in terms of the password specification criteria. It also incorporates an optional Password Generator that uses the site specified password criteria to derive a suitable password which the user can then select and which will be automatically entered into the password fields upon the form, without the need for the user to perform a 'cut and paste' action.
There is one fix incorporated in this release which addresses the usage of the users 'old' passwords stored in the control table when the PHP supplied routine is used. The database supplied routine is unaffected.The is the initial release of the component.

Release 0.0.9

This release adds a few enhancements such as the ability to specify exemption groups and the change to specify the exempt users from a select list rather than providing the user ids specifically. The release reworks the 'single change' option to be more robust and also adds a PHP routine to update the control table for those users who cannot use the supplied database routine due to difficulties with thier hosting providers. The password checks are now performed in the onBeforeUserStore method so that the #__users tables is not undated if the password checking fails. There is also integration with Akeeba System Restore Points..

Release 0.0.8

This release corrects a few minor problems and allows the specification of the redirection link. If also changes the database based password checking routine to be 'deterministic' which resolves a problem of the password checks failing if the underlying database binary logging is not set to 'row' or 'mixed' format.

Release 0.0.7

This was never publicly released. It was a special one off release for a client running Joomla 1.5 and as such was specific to that version of Joomla.

Release 0.0.6

This release corrects an error when displaying information about encountered database errors. It also changes the changelog display to use a modal window.

Release 0.0.5

This release introduces Joomla 3.0 compatibility as well as correcting an unrequired 'feature' (resulting in a forced password change request when an administrator edits a users profile) and meeting 'Strict' PHP coding standards, thus removing warning messages displayed when the site reporting is set to 'development'. The documentation remains unchanged as no new functionality as been introduced other than the presence of a changelog in the description of the plugin.

Release 0.0.4

This release was intended to mainly be a stabilisation release. There are however a few new features included. The main addition is to incorporate Joomla update functionality and an installation script. There is an enhancement to permit unlimited (well up to 999) previous passwords for a user, each of which is checked to prevent reuse. There is also the ability to not check the previous password at all if that is the sites policy. A minor addition is to allow integration with the Password Control component which is currently under development, and a few minor fixes required to resolve problems encountered with the 0.0.3 release.

end faq



Frequently Asked Questions

Password Control User Profile Plug-in

The Password Control User Profile Plug-in is an optional piece of functionality that may be installed to provide the user will details of their most recent password change and the next scheduled forced change. It also provides the site administrator with similar visibility and and allows the next password change date to be set for an individual user. Certain restrictions apply. More details can be found in the Password Control documentation (see above).

Release Versions

Release 0.0.4

This minor cosmetic update cleans up the code a little. Functionally unchanged.

Release 0.0.3

This minor update changes the changelog display to use a modal window

Release 0.0.2

This release supports Joomla 3.x as well as meeting 'Strict' PHP coding standards, thus removing warning messages displayed when the site reporting is set to 'development'.

end faq


These plug-ins will become part of the Password Control Component (currently under development), but are intended to be retained as separate stand alone plug-ins for those who do not require additional functionality.

This article describes a couple of methods for creating a language translation for a Joomla! extension, in this case Macrotone's Issue Tracker.


One method that we have recently decided to make use of is the ‘Transifex’ project. To be truly multi-lingual most freely available Joomla component (including modules and plugins) relies on local communities to create language packs.  We realise that is can be a very dirty job, that is very time consuming.  Transifex provides a mechanism to make language translations faster but with less work. Making use of this mechanism we hope to be able to provide users with a wider variety of available languages ready to download.

Looking at the number of existing components already making use of Transifex, we are joining an already varied and wide ranging community.

Transifex comes with the options of a client or a web interface and also has an extensive help system.

One site that might provide useful to translators starting to get to grips with Transifex and its usage is provided here. Not being multilingual ourselves we cannot really make any valid comments upon how useful they specifically are, but they certainly appear to be informative and complete.

Basically the language files are placed upon the Transifex server by ourselves within a 'project' i.e 'Issue Tracker'. The translators have an account (free upon request) on Transifex and request access to a language, which if granted allows access to the specific language files. The translators can edit the language strings for their specific language directly online, or via the use of a 'Transifex client' (freely downloadable) download the files, perform the translation loacally and then upload them back to the Transifex server.

On our end we are kept informed of the state of translations automatically and via the use of a Joomla component named CTransifex (Compojoom) which can automatically generate the required installable zip files and make them available for users to download.

This avoids the need to create multiple zip files manually making the distibution task much simpler and relieving the translators from the tedious task of maintaining zip files, and at the same time providing an easier translation tool.

 Manual method

For those unwilling or unable to make use of Transifex, we here describe a manual mechanism for creating an installable extemsion pack.  For translating extensions for Joomla! 1.6, 1.7, 2.5 see this article: Creating language packs for extensions in Joomla 1.6/1.7  http://docs.joomla.org/Creating_language_packs_for_extensions_in_Joomla_1.6/1.7

For an example we will illustrate the build of the Portuguese Brazilian language for the Macrotone Issue Tracker component.

1) We will prepare folder structure for the new created translation. Create the following folders on your disc:


Open text editor and paste the the following content:

     <html><body bgcolor="#FFFFFF"></body></html>

Save it as index.html in all folders (as lang/admin/index.html, lang/site/index.html and lang/index.html).

2) Unzip the Macrotone Issue Tracker component ZIP file somewhere on your disc. Go to:

    admin/language/en-GB/ folder (which is included in the unzipped Macrotone Issue Tracker structure)

and open both files:


in your text editor. Translate the strings to your language and save them as (in our example we use Portuguese Brazilian prefixes):


Go to:

    site/language/en-GB/ folder (which is included in the unzipped Macrotone Issue Tracker structure)

and open the file:


in text editor. Translate the strings to your language and save it as (in our example we use Portuguese Brazilian prefixes):


Files should be saved as UTF-8 without BOM encoding.

3) Open text editor and paste there the following content:

<?xml version="1.0" encoding="UTF-8"?>
<extension type="file" version="2.5" method="upgrade">
    <author>Macrotone Consulting Ltd</author>
    <authorEmail>This email address is being protected from spambots. You need JavaScript enabled to view it.</authorEmail>
    <copyright>(C) 2012 Macrotone Consulting Ltd</copyright>
    <license>http://www.gnu.org/licenses/gpl-2.0.html GNU/GPL</license>
    <description>Brazilian-Portuguese language pack for Macrotone Issue Tracker</description>

       <files folder="admin" target="administrator/language/pt-BR">
       <files folder="site" target="language/pt-BR">

Edit it, changing the language specifics and the author as required and save it as :

    lang/install.xml file.

So now you should have the following folder structure in the folder lang:


Select all files included in lang folder and add them into ZIP file called lang-prefix-LANG-PREFIX.com_issuetracker.zip (in our example the file will have the following name: pt-BR.com_issuetracker.zip).

Now the translation is ready and can be installed via standard Joomla! installation procedure.

Remember that the Joomla Language core pack for your desired language must be installed otherwise the language installation will fail.


It is possible to expand upon the above so that all of the language translations for plugins and modules can also be included within the zip file. To do this just create the appropriate language translation files and add then into the directory structure at the appropriate place.

An example of this can be seen in some of the language translation available for the Issue Tracter component on this site. The pt-BR translation by Carlos Rodrigues de Souza is a very good example.

There is one thing to note regarding language translations for the Smart Search (finder) module. In Joomla 2.5 and Joomla 3.x it has been discovered that the Joomla Smart Search module has a specific requirement that the finder plugin has a name composed of the plugin itself.  This was discovered after Issue Tracker 1.3.2 was released and a work around was implemented to ensure workability. Subsequent to the release the 'undefined' requirement was determined and hence the work around is no longer required.  The problem is best described as Smart Search looking for a 'strange' named language file based upon the provided name of the plugin. In our case because the plugin was name 'Smart Search - Issue Tracker', the smart search module was looking for a file named 'en-GB.Smart Search - Issue Tracker.ini'. [The spaces in the file name are significant.] The contents of the file are not a problem, it being a simple copy of the standard named 'en-GB.plg_finder_issuetracker.ini' file, so no further translation is required.


What is allowed in .ini files

Comments are made by a leading ";"

The translated string must be enclosed by double quotes.

COM_ISSUETRACKER_SAMPLE_PARAMETER_FILE_NOT_WRITABLE="Can not make the parameter file writable"

Do not split translations into multiple lines (only first line will show up).

parameter file writable"

If you want a new line, write

<br />


COM_ISSUETRACKER_SAMPLE_PARAMETER_FILE_NOT_WRITABLE="Can not make the <br /> parameter file writable"
[Note] Ensure your translations are valid XHTML 1.0

Not <br>, not <br/> - only <br /> is valid.

If unsure, please use the current markup method.

[Note] Note

Files must be saved in UTF-8.

[Tip] Tip

Take care when using Double Quotes (") in your translation, used incorrectly it will break the translation.

Under Joomla! trying to escape double quote in language files will cause issues with some php versions:

COM_ISSUETRACKER_STICKY="My great \" string which is broken"


The way to escape double quote is the following :


COM_ISSUETRACKER_STICKY="My great "_QQ_" string which is broken"


This may seem strange, but it's the only way to escape double quote under Joomla!

As release Joomla only provides some rudimentary control of user's passwords.  The basic Joomla authentication of the user's password is whether the two entries match.  If they match the user can continue.  What is required is control over the specification of the password itself?  Must it contain upper and lower case letters?  Should it also contain numbers and/or special characters' such as underscore (_), hash (#) etc?  Also how many of each should it contain?  Should there be checks upon real words?  Password Control tries to address some of these questions.

Translation Credits

Frequently Asked Questions

Password Control Overview

The documentation in PDF format and also as web pages is available upon the site. [Please see links under 'Joomla Extensions' on the site.] This document only presents a brief overview of the functionality.

Currently the existing capability is provided by a system plug-in.  The plugin addresses the more pressing issues:

  •  Forcing the user to change their password on initial logon

  • Forcing the users to periodically change  their passwords every 'n' days, where 'n' is an administrator defined variable, typically set to 30 days.

  • Ability to optionally block users.

  • Ability to store up to 999 previous passwords for a user.

  • Supports Joomla update functionality.

  • Ability to specifiy site password criteria that must be met and provide user with feedback on how their password fails.

  • Inbuilt password generator that creates passwords matching the site specified criteria.

More details can be found in the Password Control Documentation

An additional optional capability is provided by the Password Control User Profile Plug-in.  This is described in the documentation, but permits the site user to see details of their most recent password change and the next scheduled password change.  It also allows the site administrator to view this information and edit the next password change date if required.

Translation Credits

We would like to thank all the people who have donated their time and effort in providing translations for our extensions, either individually or as part of a translation team, so that they may be used by the wider community.

Go To Top

The Macrotone Consulting Web site would like to use cookies to store information on your computer, to improve our website. Cookies used for the essential operation of the site have already been set. To find out more about the cookies we use and how to delete them, see our Privacy Policy.

I accept cookies from this site.