Macrotone Blogs

Macrotone blogs upon Joomla, our products and other matters.
Categories
Tags
Archives
Calendar
Categories:   All Categories
Suggested keywords
x

migration

Subscribe to this list via RSS
Geoffrey Chapman

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…..

Tags:
joomla component migration
Geoffrey Chapman

Discussions forum migration to Kunena (Part 3) Images

kunenaThis is the latest (and probably last) post on our migration exercise for moving Discussions forum to Kunena. [Last post is here.]

Our previous posts did not discuss or address the question of images which are contained in forum entries. The two forums basically store images in the file system and then refer to them in the posts, however the way they do this is different which makes an automatic migration difficult.

First the images are located in Discussions in the directory images/discussions/thread id/post id/[large][original][small]  in the three separate directories each one reflecting a different size of the image, the entries in the ‘small’ and ‘large’ directories being is created when the image is stored.  The images details are then stored in the database table #__discussions_messages as extra fields in the table.  When the post is read the images are appended to the message and shown on the web page.

Kunena stores the images in directory media/kunena/attachments/[user_id], where user_id’ is the identifier for the user saving the images, and stores the image details in a separate database table #__kunena_attachments. The actual forum post is modified, within the #__kunena_message_text table, if the image is to be shown within the post, with tags referring to the actual image itself.

To automate this task would require the population of the kunena attachments table with the image details, after the images have been copied to the ‘new’ Kunena location, and also the specific messages in the #__kunena_message_text table would need modification to add the appropriate inclusion tags.

We have analysed the images in our ‘old’ Discussions forum and found less than a dozen images in total, and given the amount of work that would be required to automate this, have decided that it is probably not worth the bother, and that a one off manual task would be far quicker.  It also enabled us to ensure that image sizes are below the bounds specified in the Kunena configuration file.

Note: We do not have any embedded videos to consider so will not investigate this topic at all.

Tags:
components Forum migration Kunena Codingfish Discussions
Geoffrey Chapman

Converting Joomla Discussions Forum to Kunena revisited

kunenaWe previously wrote about converting a Discussions Forum to Kunena and it was now time to revisit the topic as we prepared to perform the task again and this time make the final step to make it live on our site. Since then the Kunena version has moved on to 3.0.3 so we were expecting a few changes.

We must also take the opportunity to state that our Discussions forum did not make use of images/attachments, hence it was not necessary to consider these in the migration. There was also a know opportunity with the Discussions component in that although new user were synchronised between Joomla and the component, when users were removed from teh system for any reason, their details remained within the component. It was thus necessary to run an additional SQL script to clean out these old entries.

The installation of Kunena 2.0.4 and the Importer worked fine, as did the import of the Discussions items (posts and categories). Unfortunately the ‘live update’ to version Kunena 3.0.3 gave us a blank screen, so we resorted to the standard update mechanism which worked fine. (Perhaps the live update implementation needs some work?)

Then we started running our SQL scripts (See previous post for details, which are didn’t require any changes):

  1. Create the  view.
  2. Updated the topics table. We observed the message ‘1364: Field 'params' doesn't have a default value’.
  3. Update categories number of topics count. We saw a number of messages ‘1048: Column 'numTopics' cannot be null’.
  4. Update the last_topic_id, last_post_id and last_post_time fields.  Again we saw a number of ‘1048:Column xxxxx cannot be null’ messages. We were not too worried about these messages as they reflect the empty categories in our original Discussions source tables.
  5. We then updated the category hits.
  6. We then recalculated the statistics within the Kunena Forum Tools.
  7. As mentioned above, we run an additional script to remove 'old' users from our Kunena users table.

delete from #__kunena_users
where userid NOT IN (select id from #__users);

Note: There are several fields such as the number of views of a topic etc. which are not populated because this information is not retained by our source forum and we could not begin to guess what might be appropriate, so better to leave them empty. They will populate themselves over time and we are not too interested in how many people had read them.

Now we can either start configuring the component on our development site, or we can export our tables ready for loading into our live site and after loading configure the forum there. We decided upon the later option.

Inspecting the database tables if was apparent that a number of the tables were empty (since this was effectively a new forum installation) so only a small number needed to be exported and imported on our live site.  The list of tables was as follows:

#__kunena_aliases, #__kunena_categories, #_kunena_configuration, #__kunena_messages, #__kunena_messages_text, #__kunena_topics, #__kunena_user_topics, #__kunena_users, #_kunena_version

On our target (live) site we only need to install the latest Kunena version (3.0.3) and import the data we exported above.

We now disable the use of sh404SEF for the Kunena forum. Basically we have found it more trouble than it is worth, and the Forum entries are fine without the need to use the SEF translations in sh404SEF.

We now enable the Forum menu item, which is the menu link to the Kunena menu item, and after clearing out system cache, we are ready to see how it is looking.

Looking at the front end of the site we can enter our forum and see our posts etc., so all is basically sound.

The next step is to install an anti spam component for the Forum. We have chosen R-Antispam v1.3.0 by Ratmil, which uses a Bayesian algorithm to determine whether the message is spam or not. Being Bayesian it learns over time and becomes more accurate the longer it is used.

Our configuration included adding spam check API keys, changing the default Kunena menu tab, etc.  We also had to change our category headers slightly since Kunena didn’t like html in the category description.

Once done we made the new ‘forum’ available to users and disabled the ‘old’ forum.  Note the ‘disabled’ since we will monitor it over a few days/weeks before we finally ditch it altogether.

Addendum: Have to also change the SEF entries that refer to the 'old' forum entries to redirect to the new forun equivalent. Also search out 'smart search/finder' entries as well.  Note that Kunena does not currently install a 'smart search' plugin even though it is present in the installation file. See Kunena web site forum for the rationale for this.

Tags:
Kunena Codingfish Discussions developers sh404sef Forum joomla migration
Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries