Macrotone Blogs

Macrotone blogs upon Joomla, our products and other matters.

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.

 

Kunena – Administrator post delete clarification

kunenaOne observation we have made since using Kunena is that one is presented with an ‘Access Denied’ message if an attempt is made to reference a non-existent Forum topic/message. We wanted to investigate this further since we wanted  to get a 404 redirection defined such that the URL could be redirected either to a full ‘404’ page or an alternative Forum post.

We started out creating a new forum post which we then wanted to ‘delete’.  This led us to a different puzzle since our Forum administrator was unable to ‘delete’ the post.

Being a little puzzled about why our Kunena administrator couldn’t see an option to delete a post I have delved a little deeper to understand what was going on with specific checking on the ability to ‘delete’ posts.

Continue reading

Discussions forum migration to Kunena (Part 4) SEF links

kunenaWe anticipated our last post being our last on this topic, but we have enough information for an additional post.

First we discovered that the first topic id had not been correctly set up.  Not quite sure what went wrong here, but the topic title had the wrong name and pointed to a non-existing category, even though the topic text (message) was our submitted text.  We edited the the table entry directly to correct the category and title and this seems to have resolved the problem.

Much more of a concern has been the relentless number of ‘invalid URL addresses’ we have encountered that have required redirection since we moved forums.  These links seem to have a number of variations as follows:

  • index.php/link_name/cat id/thread id
  • index.php/components/discussions/cat id/thread id

In addition sometimes the category id is expressed a numeric values, sometimes as a text string and sometimes both are included.  Likewise the thread id is similarly expressed is a variety of forms although usually the thread id and title text are provided, separated by a hyphen.

Sometimes the menu id is provided (we changed our menu title from ‘Macrotone Forums’ to ‘Forum’), sometimes the language string ‘lang=en’ is also in the link.

Sometimes the link seems to have the index.php missing completely and consists only of a cat id/thread id.

Most do not have any ‘calling’ URL to check. Look with a tool such as Google web tools for a registered website sometimes show calling web links, and often the referring links are ‘unpublished’ or invalid.

This is despite us removing all ‘old’ existing SEF entries on our site.

We had expected a few since it can take a while for ‘robots’ from the likes of Google etc. to get up to date, but some six weeks after we moved, they are still being found on a regular basis, often > 10 a day.

We have created ‘redirect’ links within Joomla but the wide variety is something that we had not expected, and are sure we are not alone in this.  When could one safety remove these ‘temporary’ redirection links, since one would have expected at the most a few weeks.

We ourselves have a ‘modest’ number of forum entries, but for a large site constantly creating redirection links would become a major headache. Yes one could modify the ‘.htaccess’ file to place a 301 redirection pattern, but the number of patterns required seems to be more than an odd one or two, and is not something I have ever seen described in detail.

Definitely something to be aware of for others migrating from one forum to another, not just for the Discussions forum.

Whilst on the subject of SEF, there doesn’t seem to be a definite solution or suggestion as to how one should really deal with items such as ‘old’ articles.  If the ‘article’ is ‘unpublished’ then any existing links immediately become invalid. How long should one wait (or expect) to see these invalid URLs?  Should the articles be ‘archived’ instead and would this be a better approach? Any item whether it be a web article, a forum entry or whatever has a useful life, so what is the best way to handle their expiry?

Perhaps this is the suggestion for a new definite work on the topic.  It definitely seems to be one of the ‘black arts’.

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.

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.

Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries