Macrotone Blogs

Macrotone blogs upon Joomla, our products and other matters.

Emailing €˜items€™ with relative image URLs from Joomla.

issues-48We have been looking at a small ‘opportunity’ which we discovered when we were emailing material such as an ‘article’ or Issue Tracker ‘issue’ from our Joomla system.

The problem is quite simple to explain since it can be caused by the content editor that is forced to use relative URLs.

This can be resolved by creating a new profile in the editor (such as JCE) which is configured to use absolute urls and then assign the profile to the particular component where absolute URLs are needed.

There is a small note on it for JCE which explains how to do this in more detail.

Continue reading

Joomla date/time displays and Database vales.

b2ap3 icon joomlaHave been looking at an interesting problem of the display of date/time values on Joomla screens.

First it is apparent from looking at the database stored values that Joomla stores all of the date/time values (calendar) in the database as UTC values, which means that all of the stored values are consistent.

However when these are displayed upon a form or in a tabular form, care has to be taken that the format of the values is consistent.  For example if the displayed value is shown as a ‘text’ field, the values stored in the database (UTC) is displayed, which is not necessarily the ‘local’ time.  We are in the London area and currently are using DST (Daylight saving time) which is an hour ahead of UTC (GMT – Greenwich Mean Time) .  One has to make consistent use of the ‘calendar’ type and if necessary make it read-only, thus ensuring the correct value, suitably converted is displayed.

Another complication that we have not yet worked out the cause of is that if using JForm with the calendar type and using the default of ‘NOW’ which should display the local time (according to the documentation),  it displays a time value 8 hours ahead of the local time.  Where is gets that from I am not sure.  i.e.  If local time is 11:30m, the ‘now’ value as determined by the JForm default shows as 19:30.  Go figure!  It was necessary therefore for us to specify the default value as empty and assign a default value in the view based upon the local time so that the form value is correct.

We have therefore decided that to avoid confusion all date/time values should be displayed using local time.

CSS: Text wrapping in a table cell. Part 2

CSS logoWe previously made an entry about long text strings overlapping table cells.  It was time to relook at the problem again after we saw a few more instances on our site.

The problem is quite common and has been mentioned in various articles upon the web for many years.  Solutions have ranged from the use of code to add extra spaces into the text fields, sometimes using ‘hidden’ characters, to various suggested CSS additions, many of which have browser dependencies.

This article on Stackoverflow summaries the suggestions quite adequately, but unfortunately didn’t provide a suitable solution.

Finally I discovered an article which describes the problem perfectly with examples. It is quite old (2007) but still holds true even today, with many revisions of browsers later.

In our case the final table cell was overlapping the right hand side menu and module displays, with the modules on top obscuring the table cell contents. We resolved it by using the suggestion in the article by changing to a fixed width table. Now the word-break could work.  It does mean that some of the other columns are slightly larger but it does produce a more professional output on the site.

This change will be implemented in latter releases of the Issue Tracker component.

Template Override

Whilst investigating this problem we had forgotten that we had implemented a CSS table override for the component so it is perhaps worth mentioning that here as well.  The CSS override is created by creating a file in the templates directory under template_name/media/com_issuetracker/css/ named issuetracker.css.  A copy of the distributed CSS file would serve as a starting point.  When changes are made to this file they take effect and override those in the media/com_issuetracker/css/issuetracker.css file.  This means that any changes you make would still apply even when/if the component is upgraded.  It is a convenient place to test out small CSS changes.

Bootstrap templates width of 'Text Area' boxes.

b2ap3 icon joomlaWe have been looking at the size of the 'Text Area' boxes displayed within the Isis back end template and the Protostar front end template and wondering how to increase the width so that it maximises the available space as opposed to being restricted to the small (approx 200px) size.

Attempts to specify the number of rows and columns made no difference and searching the web didn't reveal any solution.

So we are sharing the 'fix' for the 'width' text area boxes which achieves what we were trying to achieve.

In the form definition XML file navigate to the appropriate 'textarea' field, and then modify the 'class' entry (or add one if it doesn't have one) to the following:

class="inputbox textarea-span"

The important bit is the 'textarea-span' after the inputbox.  We have tried specify specific span sizes after the 'span' but these do not make any difference.  i.e. span6, span8 etc.

Once the from is refreshed then the boxes will occupy what ever width is available.  This works with Isis and Protostar templates, so should work with any Bootstrap based templates.

Strange 1604 errors with upgraded Joomla 3.1.5

b2ap3 icon joomlaWe today tried an upgrade of a copy of our Joomla 2.5.14 site to Joomla 3.1.5 as a test to see just how much we would have to change and the work involved.

The upgrade seemed to complete successfully and then we started to look further.

There are some obvious component that do not have Joomla 3.1 versions and we found that there was a need to upgrade some plugins which were causing front end site errors of various types but mainly relating to Mootools. Nothing too difficult to resolve.

On the front end we then started noticing a few page errors 1604 with messages similar to the following:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FROM WHERE ='index.php?option=com_xxxxxxxx&view=yyyyyy' AND ='1' LIMIT 1' at line 1 SQL=SELECT FROM WHERE ='index.php?option=com_xxxxxxxx&view=yyyyyy' AND ='1' LIMIT 1

It is very evident as to what is wrong with the SQL statement but the question is why and where is the statement coming from.  It certainly doesn’t look like a statement in any specific module as far as we can see.  The particular components (and modules)  in question work perfectly fine upon a fresh install of Joomla 3.1.5 so I think we can eliminate the component/module from being at fault.  It is not restricted to one component either.

Disabling module(s) sometimes indicates a specific module at fault but as I said earlier the module(s) works fine on a ‘fresh 3.1.5’ install.

We have also seen ‘404’ errors reported when trying to install/upgrade an existing component to the latest version to run on Joomla 3.1.5.  Again the components install fine on a fresh ‘3.1.5’ install.

Of course it could be that the various components do not upgrade correctly on Joomla 3.1.5 but this seems unlikely especially as one can update the component successfully on a ‘fresh 3.1.5 install’.

Our conclusion is that it is probably the ‘Joomla’ upgrade itself that is at fault. Even ‘reinstall’ of the Joomla update doesn’t resolve the problems. Inspection doesn’t provide any clear ideas at present as to what could be at fault, so it is probably fair to not even contemplate thinking about updating our ‘live’ site just yet until a few of the remaining ‘issues’ are resolved.  There is a need to ‘preserve’ our existing data and an export/import approach doesn’t really bear thinking about.

One to revisit later possibly once 3.2 has stabilised.

Tags:

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.

Experiences with JQuery and Dialog boxes

jqueryWe recently started work on a plugin enhancement that was intended to add a ‘button’ to an existing form programmatically which when pressed would open a ‘popup’ window where the user could review a generated ‘parameter value’ and either accept it or regenerate the value until an acceptable value was obtained, before returning to the calling screen, where the value is inserted into an existing form field.

With the design intent decided upon, the fun part of making the change started.  Firstly the existing form is an already existing Joomla form which for obviously reasons we do not want to modify, other than programmatically.  We looked at using Mootools  initially, but this is gradually being replaced by the use of JQuery, so it seemed sensible to start using JQuery.  An additional consideration is that the JQuery UI tools, specifically the Dialog boxes look very useful.

After much testing and frustration we discovered that there are some specific ‘id’ specifiers that JQuery does not like using. For example we could place the ‘button’ using the id field on the JForm label tag, but not on the JForm input tag.  No error messages were ever seen, just that the instruction was silently annoyed.  This seems to be related to the specific ‘append’ function we are using. There is the possibility to use ‘append’, ‘prepend’, ‘after’ and before (ignoring ‘appendto’ which is the same thing only with the arguments transposed). The input tag does not accept the use of append (or prepend). Very strange.  Investigation isn’t helped by the fact that viewing the web page, doesn’t show ‘our’ added button etc in the HTML code, presumably since this is not the ‘source’ web page but one we have modified. Not sure, or indeed found a solution to this particular problem yet.

Since we were using an existing (base form) we not only had to add the button to the form but also add a place holder for the JQuery UI Dialog box, otherwise the dialog box is never displayed.

Another challenge is the CSS involved with the additional strings. To get the popup box, one has to have  the CSS included in the page usually with one of the JQuery Template CSS types such as smoothness. Unfortunately this also changes the CSS of the newly inserted button used to call the popup. This is not really desirable since we want the calling page to ‘look’ like the existing form page with the exception of our added button. [Note this applies even if instead of a button, we use a simple anchor link to the popup, so is not specific to the use of a button.] So it is necessary to also include code to remove the CSS from the button that we had inserted to call our ‘Dialog box’.

Creating the generated popup window contents was relatively easy, as was also inserting the generated values back into the main form once the user has accepted them.

Since we want also to pass in certain parameters to the generated ‘parameter’ creation  code behind the ‘Dialog box’ we decided to add the Java via a PHP routine call. In this way we could also ensure that the appropriate language strings were also passed in, thus ensuring that the plugin was ‘multi-lingual’.

We do not consider ourselves Java experts by any means, but have little difficulty in generally getting what we want working.  We still a little bit of tweaking to perform on the java code itself, but we are pleased to say that it is working very much as intended so will be included in the next release of out Password Control plugin.

It was ‘fun’ although somewhat complicated by the apparent inconsistences of getting the initial button placement working in the desired position, and the need to modify the CSS on our original form for our newly placed button. The jury is still out on whether it is better than Mootools, but since Joomla is heading towards greater use of JQuery and phasing out Mootools it is a route that more and more will have to follow.

Component Translations and Transifex

b2ap3 icon joomlaPart of the task of providing a useful component for the wide community, we have long considered a way in which it is easier to provide language translations for our Joomla Issue Tracker component.  One method that we have recently decided to make use of is the ‘Transifex’ project.

To be truly multi-lingual each Joomla component (including modules and plugins) has to rely 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, it seems that 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.

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.

Converting Joomla Forum from Discussions to Kunena

b2ap3 icon joomlaI recently looked at the possibility of converting from using the Discussions component to using Kunena.  I will not go into the reasons why this may or may not be required or whether it is a good or bad thing to do.

Looking on the web, for the best method, it was a topic that several others have looked into, but there were no solutions offered. We therefore post this information which others may find useful.

There is a ‘Kunena Importer’ but according to the Kunena documentation this doesn’t work with Kunena 2.0.x or above. We were thus left trying to see how difficult it would be. The following describes the mechanism we used to get our ‘old’ posts transferred over to Kunena 3.0.0. It is possibly not the most efficient but given that it is likely to be a ‘one-off’ conversion, performance is not the prime criteria.

To convert Discussions v1.6.1 to Kunena 3.0.0

Continue reading

Implementing Smart Search

b2ap3 icon joomlaWe have changed the search mechanism on the site from the standard ‘Joomla Search’ to make use of ‘Smart Search’.

This will hopefully enable a ‘richer’ environment for our visitors.  The implementation itself was relatively painless. Our own Issue Tracker component, and the standard supplied components such as content etc. worked flawlessly ‘out of the box’.  In additional a finder plugin for our Blog was also found and implemented very easily.

Only our Forum component gave rise to any problems. It was necessary to prevent sh404SEF from interfering in the URL generation so that the Forum used the ‘standard Joomla router’ for its links. This also involved removing from the sh404SEF component all history of the forum component. Once this was done then it was plain sailing.

The only point that should be emphasised is that the ‘Smart Search’ does not make use of ‘wild card’ characters.  The ‘old’ Joomla search mechanism used a very primitive method of searching which relied on the FULLTEXT search provided by the database. This was very inefficient but provided a simple means of handling wildcard search queries. Smart Search provides an auto-complete feature which is effectively a wildcard search of terms in the index, but full wildcard searching is not supported due to the potential for crippling the server if the feature were to be abused. In most cases wildcard searching is used to cater for variations in a search term. For example, searching for "juggl*" in order to catch references to "juggling" as well as "juggler". Smart Search attempts to avoid the need for wildcard searching by instead supporting word stemming where words that have the same stem are considered equivalent so that searching for "juggler" will also retrieve instances of "juggling" without the need to use wildcards.

Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries