Macrotone Blogs

Macrotone blogs upon Joomla, our products and other matters.

Hints and Tips on Joomla and its usage.

Making a component truly Multilingual (3)

Following on from our earlier post about item associations. we next turn our attention to look at the front end.  This tends to be more complex since it is here that we are actually using the associations to impact the front end displays.  To expand upon this, when a user chooses to display the categories in for example ‘German’ it is the ‘de-DE’ categories that should be displayed, along with the appropriate ‘de-DE’ translated text.  Likewise if they then choose to display ‘English’ the ‘en-GB’ categories are displayed along with the English text.  It is also reasonable to expect that any categories that are marked as ‘All’ languages would also be displayed in each case.

The specific ‘category items’ to be displayed for a chosen language would be the ‘specific’ language items, together with the items marked as ‘All’' languages’. The question of what about the un-translated items which are not associated with a ‘specific language version has also to be considered.  This is best explained by considering a specific situation.  Assume that we have our ‘Rialto’ component available with a English (en-GB) and a German (de-DE) translation.  All of the categories are established with the correct associations, however they may well be a number of different ‘entries’ that are present in only one specific language, which would not then have any associational entries in the other language.  In our Rialto example, the entries are ‘classified advertisements’, it is not unreasonable to assume that an advert for an item to buy/sell in German, may not be of interest to an English person, and that might therefore not be a translated version of the advert created. The question is then does one display the ‘German’ item to an English viewer?

We are assuming here that the ‘English’ viewer is displaying the site in the English language, and that a ‘German’ viewer is displaying the site in the ‘German’ language.

Taking this one stage further, assume that we wish to determine the total number of entries in a specific category. On the surface this sounds simple, but once we are multilingual we have  a few additional complications. First we have the number of entries for which there is a single language specified (or all) for each of the different associated categories. This means that all the un-associated de-DE German entries in a category are counted together with the number of un-associated entries in the equivalent en-GB category are to be counted. Then we have the entries where we have an entry associated, in this case we only wish to count the entry once, even though there may be a de-DE and a en-GB translation they are effectively the same entry for counting purposes. This makes getting the total number of entries complex in terms of the SQL statement that is required, especially given the underlying table structure, involving sub-queries ( or numerous joins).

The approach we have taken is that we would only, by default display specific items in the selected ‘viewing’ language (plus items marked as being ‘all languages’).  Switching the site language to one of the other possibilities would (probably) display different entries. i.e. This marked as ‘all’ and those available in the current selected language whether associated or not).

This might seem complex but should provide the site visitor with the entries in the chosen site language and those marked as visible for ‘all’ languages.

There is also the question of which entries are displayed in the ‘module’ which displays the latest ‘n’ (where ‘n’ is the number) of entries recently opened/created.  The entries displayed are interpreted as being those created/opened in the displayed site language and those created/opened as being ‘all’ languages.

Similar to the changes for the back end we have to modify some of our code but the changes are different, mainly because it is only really the actual items created/maintained upon the front end that need the most work.  We require changes to any ‘drop down’ selection boxes so that the displayed options are in the chosen site display language, which means changes to the ‘helper’ files. Other changes relate to the displays which are themselves more involved than for the back end, since we can create entries on the front end and (presumably) also need to probably create entry associations as well. This last task is something that, from our study code reading is not something that Joomla com_content does currently so may well be something that we ourselves put on the back burner, leaving the back end to create the associations between entries. Not ideal perhaps but it seems to be something that Joomla multilingual sites are currently having to wrestle with already, so will be familiar to them.

To be continued…

Making a component truly Multilingual (2)

In an earlier post we mentioned the topic of associations. In Joomla terms associations are effectively links between equivalent items that are in different languages. In our component we also wish to allow associations so there are a few changes we need to implement for this as well. There are no table changes required since we will be making use of the supplied Joomla associations table.  This table is composed of three columns, the first being an id column that is the value of the specific item being referenced. In our case it is the id of the category or entry. It is worth mentioning that within the Joomla associations table the id column is NOT a primary key. The second column is a context value, which is typically composed of the name of the component followed by the specific component type separated by a full stop. i.e. ‘com_rialto.category’ or ‘com_rialto.entry’.  The third and final column is a hash (md5) key. This key is what is used to ‘associate’ the various parts together. So as an example two categories associated together would have the same ‘hash key’.

Associations – Back End

The setting up of associations is something that seems to be restricted mainly to the back end so it is these changes that we will look at first.

The following changes are required:

  • Modify the views such that if associations are enabled they are displayed as required.
  • Modify the model save method so that upon the item being saved the existing associations are removed and ‘new’ associations created.
  • Modify the model ‘delete’ method so that when a item is deleted any existing associations are removed. If the component is making use of the ‘trash’, i.e. when an item is deleted it is not actually removed, just relocated to a ‘trash’ status for removed when the ‘trash is emptied’ this also has to be allowed for in our code.   [Note that we found a problem in this area, in that the code we were following for the Joomla content component, there was no appropriate code to remove associations in the delete method. We think this is a definite Joomla bug, unless we have missed something we do not understand.]
  • Modify the model ‘get’ methods so that the associations for the specific item are picked up correctly. 

The change for the views is slightly more complex than it might initially seem, since there has to be incorporated a means for the selection of ‘other’ items for the associations to be made. This is achieved by making use of slightly modified modal views which are displayed to enable the selection to be made.  We say ‘modified’ since for a selection criteria one does not necessarily need to display all of the item details, only sufficient to enable a clear distinction to be made to enable the correct item selection to be made.  The ‘code’ we were following/studying also permitted editing of the item from these modal views, however we question the logic as to why one would wish or want to provide additional editing at this point. The coding is not difficult but just, to our mind, seems unnecessary.

This does effectively complete all of the back end changes with very little pain being encountered on the way.

The question of how the ‘entries’ are displayed using the associations is something that is more specific to the front end. In the back end we tend to concentrate upon the maintenance aspect of the various associations so the coding in the models is virtually unchanged as we wish to see ‘all’ of the entries and categories, irrespective of what ever language they may be written in. This is something we will consider in the next post in the series as there are a number of situations to the covered.

To be continued…..

Tags:

Making a component truly Multilingual (1)

One of the first requests we received for our Issue Tracker component after its initial release was to make if ‘Multilingual’.  At the time we were rather busy but recorded the request with the intent to implement it later when circumstances permitted.. We recently decided to look at the changes involved in more detail but decided to look at our Rialto component, which is not so complex and would (should) be easier to modify.

It is important to clarify exactly what is meant by a component being ‘Multilingual’.  It is one thing to have language translations available for a component that can be loaded upon a site to permit the component to display the inbuilt ‘text strings;’ in the native language of the site, but this does not in itself make the component ‘Multilingual’.  Perhaps the best definition is that a site can be considered ‘Multilingual’ if it is possible to support more than one language such that one can switch from one to another via a single mouse click.  Items like site categories, menu items, and articles etc. would at the same time change to be in the selected language. A component would be ‘Multilingual’ if it can itself support such transitions. The classic Joomla component that does this is of course the ‘com_content’ component.

There is one other aspect that needs to be mentioned and this is the matter of ‘Associations’.  Joomla permits an article, or a category (amongst other things) to have an assigned language.  If one were to translate an article into another language then the site would have two (or more) identical articles each the same apart from the specific language. Joomla then permits one to ‘associate’ the one article with the other, such that the ‘seamless’ change on changing the language in use is switched is achieved.

Of course one does not necessarily have to translate all articles, and it is possible to define a default language (indicated by a ‘*’) which is display which ever site language is in use.

Our Rialto component, which is a Classified Advertisement component, is a situation where it is expected that a ‘Multilingual’ site would possibly have categories in different languages, which are probably ‘associated’ but that the specific adverts themselves (known as entries) are unlikely to be present in anything other than the one language. This does not mean that advert entries might not be in multiple languages just that the situation is not likely to be so common.

We shall describe some of the changes that were required to achieve what we desired, but given the number of changes required will split it into several parts. We will endeavour to avoid ‘too’ much specific code, and instead concentrate on the areas where we made our changes. We will also describe a few ‘opportunities’ for enhancement that we discovered whilst implementing the changes.

Just before we start into the detail it is worth mentioning that there is a component name ‘JAMultiLingual’ from Joomla Arts that can be used to set up a Joomla site for ‘Multilingual’ and certainly aids in getting started into Joomla Multilingual. It is not the only possibility but one which we have used and found very well constructed.

Language Field

The first step is to add the additional ‘language’ field to the database tables that we wish to have language contained within.

ALTER TABLE `#__rialto_categories` ADD `language` CHAR(7) NOT NULL COMMENT 'Language code';

Obviously we require the same column present upon all tables not just the one indicated. We also have to consider whether to apply a default language setting, possibly ‘All’ (*) for any existing entries that may be present in the database.

Having made the table change we then have to make the following code changes:

  • Change the component list and single item views so that the field is displayed.
  • Modify the Model ‘getItem’ (getItems) methods to return the additional language field to the views
  • Modify the Model Item ‘Save’ method so that the language field is updated when an item is updated or created. Ensure that a suitable default is applied if required
  • Note that one has to allow for the option that the component is being used upon non-multilingual sites and thus ensure that all situations are allowed for.  There are some standard Joomla language routines that enable one to test whether languages are installed (Method JLanguageMultilang::isEnabled() ), which aid in the coding.

These changes are ‘required’ for the back end, but may also be required in the front end if appropriate. It is not common to permit the creation (or editing) of Joomla categories in the front end, but it one permits the creation of ‘entries’ (articles)  in the front end, which is true for the Rialto component then we have to modify these as well. It is reasonable to assume that in the front end of the site, if a person is creating a new ‘entry’ that the language currently displayed on the site is the one in which they are entering the entry details. Otherwise one has to provide the user with the option of specifying the language they are using. 

These changes are required for all tables.

To be continued…..

Displaced anchor links when used with a fixed page header

We recently introduced a couple of new articles upon our site which made use of internal referenced anchor points to make navigation a little easier. We immediately saw a small problem, in that although the anchors worked and directed the viewer to the relevant part of the article, the positioning was below the required anchor point, so that the header and part of the text was obscured. This was caused by our using a fixed header on each page.

We pondered on the problem for a while and then found this interesting article on the web which described a virtually identical problem and a possible solution.

For those who only want the solution and in case the original article is ever removed, we reproduce our modified version of the solution below.

First, I moved the id’s of each h3 section to a new element: (a span in this case)

<span class="anchor" id="section1">span>
<h3>Section1h3>

The new elements were added right above each header section and would serve as the new anchor point. Whilst empty elements on a page are not perhaps the best solution, in this situation is certainly solves the issue.

Once the new elements were in place, a bit of CSS was added to the template custom css:

.anchor{
  display: block;
  height: 90px; /*same height as header*/
  margin-top: -90px; /*same height as header*/
  visibility: hidden;
}

It also works well with the responsive template and changing browser window sizing.

Tags:

Farewell to XMAP, Hello OSMAP

We have used the XMAP component for some time and were a little surprised when we discovered that this excellent component was no longer being supported, but not totally surprised since the last update was quite a while ago, but it performed well and did what it was intended to.  We had noticed that it had ceased working with EasyBlog but this was not a major concern (for us at least.)

We were therefore please when we discovered that OS Training (Alledia) were assuming the task of enhancing it.  We duly downloaded the 'new' OSMAP component and installed it and it worked flawlessly almost straight away.  A minor change to the Google Web Site and we were soon working again.

What was nice was that the EasyBlog XMAP plugin worked perfectly with the new version.  The only problem we discovered was when we tried to add the Kunena entries to our site map.  The entries were added to the site map but unfortunately when one clicked upon them the forum entries gave an 'access prohibited' message. The cause was because appended to each entry was '/list'.  Removal of the erroneous string and the link worked perfectly.  Fortunately we found this post in the Kunena forum which provided an alternative plugin which when installed resolved the link problem.

 

Speeding up site loading

Came across this small post about improving the speed of a web site which I thought might be of interest to some.

It mentions the compression of JavaScript files using gzip by entering the following command in the .htaccess file.

AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-javascript application/javascript text/javascript

This doesn’t apply to our particular site since we already make use of the feature which is automatically inserted into the .htaccess file by Akeeba Admin Tools Pro by turning on "Automatically compress static resources" in the .htaccess maker

Creating a category on component install.

We were looking at an easy way in which to create a default category for a Joomla component which we are developing. The problem is that a common insert directly into the table is not sufficient since the ‘#__categories’ table is actually a ‘nested’ table, and it would be necessary to rebuild the table entries after an insert anyway, otherwise the table could/would be corrupted.

We searched around for a possible solution and eventually found a method which we could adapt for our usage.  We present our resultant function below:

Continue reading

Image and text wrapping in a responsive template

We recently turned our attention to a small problem we had noticed on our site.  We display a few famous quotes as a module on the site, and since moving to a responsive site template, noticed that the various quotes did not display nicely when various screen sizes were in use.

As displayed the quotes were composed of an image tag followed by the specific quote text, and then by the author details.  A typical quote quote would thus look similar to the following:  (Lines split for convenience.)

Continue reading

MySQL 1071 and associated errors.

mysqlOur users have reported a few MySQL errors over the years but one of the most common appears to be the

ERROR 1071 (42000): Specified key was too long; max key length is xxx bytes

Where xxx is some specified value often, but not always, a value of 767.

For that reason we decided that we would make this blog entry to try and explain the situation.

We are concerned here mainly with InnoDB tables since that is what we tend to use in our extensions.

Continue reading

Newsfeeds display – solution to an enigma

b2ap3 icon joomlaWe have always displayed a few relevant newsfeeds upon our web site, but it has never, to be honest been very high on the visitor list, or upon our own priority list. We long ago noticed that the default display for the ‘Newsfeeds Categories’ in the front end of our site comprised merely of two lines, one for each of the two newsfeed categories we use, which also acted as a link to the underlying newsfeeds in the respective category.  There was no page header, no display of the breadcrumb information, and no details of the category descriptions.  In short  a very barren page.

Originally it was suspected that it might be a template or CSS type problem.  Attempts to change the menu settings, resaving module specifications etc.,  all proved fruitless.  It didn’t matter what the menu settings were, they were silently ignored.  One is tempted to say it was a cache type problem, but bearing in mind that this has been the situation for several months, if not longer  and the various caches’ had been manually cleared several times during that period, it was obvious that something else was amiss.

With the change to a new site template, the situation remained unresolved and it was starting to get a little bit annoying.   So given a hour or so spare we decided to investigate further.  Inspection of the PHP code underlying the display revealed no clues, and despite retrying all our previous steps we were no further forward.

Searching the web for similar reported problems drew a complete blank, apart from a link to a very strange problem we had ourselves encountered with the display of breadcrumbs on a previous occasion.  Looking back we found out previous blog entry. [So keeping a blog can prove useful.]  We thus decided to clear all URL entries from the sh404SEF component for the com_newsfeeds component.  Low and behold on refreshing our web page the correctly formatted page was shown, complete with headers, breadcrumbs, descriptive text etc.

We realise that sh404SEF keeps track of URL links, but why this should impact the page display is currently a bit of a mystery.  It doesn’t itself cache pages, but must somehow also keep track of which modules and what the ‘previous’ settings were for a page ,for which it is keeping a record of the link.  I am sure that I have never read anything of this sort in the component documentation.

What we learnt gain from this is that sh404SEF seems to have some strange characteristics which impact what is displayed upon a screen, far and above just converting non SEF URLs to a SEF format.  So it you are ever seeing a similar type of problem and every thing else seems to failing to resolve it, it might, if your site is using sh404SEF be worth clearing your entries and seeing if it resolves the problem.  Certainly stranger things have happened.

Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries