Macrotone Blogs

Macrotone blogs upon Joomla, our products and other matters.

Hints and Tips on Joomla and its usage.

ReCaptcha disappeared from User Registration.

ReCaptchaWe were recently informed of a problem on our site where the ReCaptcha image was not being displayed.  This was puzzling since we hadn’t changed anything and the image was showing in other locations upon the site, such as adding article comments etc.

We were aware of a few changes a year or so ago by Google but are not aware of any recent changes.  After some searching we found this article which described our problem and provided a solution that appears to work well.

We had already checked that Method 1 in the article didn’t resolve the problem so we used Method 2 which we reproduce below.

This overrides the Core Joomla code for ReCaptcha:
1. Open the file: /plugins/captcha/recaptcha/recaptcha.php
2. Find the following string in the OnDisplay function:

return '<div id="dynamic_recaptcha_1"></div>'; 

3. and replace with:

   1:  // Replace YOUR_KEY with your public key 
   2:   
   3:   return '<div id="dynamic_recaptcha_1"> 
   4:   <script type="text/javascript" src="http://www.google.com/recaptcha/api/challenge?k=YOUR_KEY"></script> 
   5:   <noscript><iframe src="http://www.google.com/recaptcha/api/noscript?k=YOUR_KEY" height="300" width="500" frameborder="0"></iframe><br> 
   6:   <textarea name="recaptcha_challenge_field" rows="3" cols="40"></textarea> 
   7:   <input type="hidden" name="recaptcha_response_field" value="manual_challenge"></noscript> 
   8:   <script type="text/javascript"> 
   9:   window.onload = function() { 
  10:   Recaptcha.focus_response_field(); 
  11:   } 
  12:   </script> 
  13:   </div>'; 

 

 

We have tested using Firefox, Chrome and IE and in all cases we now see the ReCaptcha image, where as previously we were not.

The following additional comments were present in the original article and also apply in our situation.

Additional

  • This applies to a case where the code WAS working and without any changes to the server (no updates), and the recaptcha simply stopped displaying.
  • Public Key and Private Key have been setup in the Joomla Core Plugin.
  • Set to display in both User Registration and Global Configuration.
  • K2 is NOT installed.

Note Well:

This change would have to be reapplied if the plugin is updated by any future update from Joomla, but at least the site user registration is working correctly!

Test email in foreign languages

We have been working with the emailing of problem reports to our Issue Tracker component recently in particular with the specific problem of languages using ISO-8859-2 character sets.

Having made some code changes to handle this, we were thinking of how it might be possible to test out other languages, with other character sets such as Chinese, Korean etc.

The little grey cells starting thinking about the various translation sites upon the web, and whether there might be any that could not only perform a translation of some specific text but also complete the task by emailing the translation to a specific address.

After some searching it seems that this is not an unusual requirement and we found several that could possibly do what we required. A lot only handled the translation part of the requirement, but the sending of the email was not that common. It was important that the email was sent from the third party since if we used a local email client the details in the message header and body did not accurately reflect the correct character set in use, and this was the one thing we wanted to test.

A number of sites imposed limitations such as the number of characters in the message, the number of messages that could be sent etc., which is generally reasonable since they are endeavouring to make a living from providing a service and would prefer to charge.  However these limitations were not of a major concern to us, especially as the text content could be anything at all, as long as the character sets were represented.

We obviously will not list all of the sites we investigated but the one which we found suitable for our needs was WorldLingo and though it insisted in creating accounts for both our sender and receiver of the generated emails, this was something we could easily live with. There is a vast range of possible languages to choose from, certainly more than we will ever use or test I suspect, and the machine translations were more than adequate for our purposes.

Our requirements were not all that unusual at all, and I suspect others might have the same sort of need, in which case hopefully this may act as a pointer.

Update: One interesting side effect we noticed was that, when we sent the email (via WorldLingo) it was 'processed' by our component and automatically send a reply acknowleging receipt. Since the emails from WorldLingo are all sent out with individual identifers in the email address the reply was sent to the named worldlingo address which then forwarded it to use (the sender). The interesting aspect was that the text was 'translated' on the reply and didn't quite match what was the 'original' text in English. One of the interesting aspects of translating in this case from English->Japanese->English. Not a concern to use but just goes to show how things can get confusing in translation.

Issue Tracker Template Overrides

b2ap3 icon joomlaWe have recently been ‘playing’ with a new ‘Bootstrap v3’ template for the front end of our site.  This involved use creating a set of template overrides for our Issue Tracker component and we decided to share the details with our users.

Joomla has long had the ability to create Template Overrides, which are modifications to the Joomla components or modules. This permits changes to be made upon a ‘local site’ basis without the need to change or hack the supplied code.

We are primarily concerned with the Issue Tracker component and we have tried hard to produce front end displays of Individual Issues and of the Issue Entry form that would be usable in the majority of installations. However the differences between the various template used on sites are many and vast, and it is almost inevitable that they will not be suitable for everyone. This was indeed the situation we discovered ourselves when using a BootStrap template for the site.

Continue reading

Handling Googlebot URL detected errors.

GoogleWe tend to use Google Webmaster Tools to monitor our main site and in particular the Crawl Errors that it detects.  Sometimes we are a little confused as to where the errors are coming from since the 'source' URL is sometimes the self same page indicated as in error, and others indicate pages where we fail to find the link referenced as in error.

That said it has proved generally useful and mostly they are trivial to fix.  What it has been difficult to discover, is a good reference guide to the topic of Search Engine Friendly URLs known as SEF. Whilst acknowledging that the subject of SEF can be quite involved, our searches have yet to reveal a good comprehensive article upon the best design and implementation mechanisms. It is even more difficult to discover a good guide to resolving problems. Having found nothing suitable we decided to create this post as a record of our investigations and perhaps act as a guide for others.

Continue reading

MySQL and JSON data structures

mysqlHaving been working with JSON data structures recently our thoughts turned to how this could reasonably be handled by SQL queries in the production of items such as reports etc.  Leaving aside the question of how one would ‘know’ and handle the various constituents in the specific JSON object on a generic basis, we looked specifically at what was currently available.

Coming from a strong Oracle background we were familiar with the use of Java within the Oracle database and indeed have made use of it ourselves in the past, but our specific interest this time was MySQL and its use by Joomla, and we were not aware of any feature implementing Java with the MySQL database.

Continue reading

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

Install IIS, PHP, MySQL & Joomla on Windows 7

iisWe had cause to investigate a problem with a Joomla component installed upon an IIS platform.  We usually use Apache as our web server, so were not totally familiar with the use of IIS, so this blog covers the installation, configuration and the basic options of IIS, PHP, MySQL and Joomla.

There is no intent to make use of such a setup upon a regular basis, and would anticipate only having to perform the task infrequently, hence the decision to document the steps.  We encountered a number of problems as we performed the set up, and we searched on the web in many placed before achieved our goal. For this reason this is somewhat long, but the benefit being that we have all the details in one location.

The installation is assuming the use of a local installation upon a single workstation.

Continue reading

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