Macrotone Blogs

Macrotone blogs upon Joomla, our products and other matters.

MariaDB and Joomla ?

MariaDBWe were looking at the possibilities of upgrading the version of MySQL we are using on out NAS system and were reminded of the existence of the MariaDB database as a possible alternative. Alternative because our NAS does not easily permit the upgrade of the MYSQL part of the system mainly because it is so tightly tied into the other features.

What is MariaDB one might ask. Well there is probably no better explanation that that upon the MariaDB web 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

Problems with a SEF component

We are currently trying to track down a strange problem with an installed SEF component.  The problem fortunately only occurs on our Development site but it has some very strange symptoms.

First we created our development site with a backup of our live environment.  Everything in the back end works fine but in the front end some pages display completely blank, with no tags what so ever.   Fine one would say, there must be a PHP error, (although why this should only occur on a restored system rather than the live site is another question), so we turn on ‘Site Error’ reporting to Maximum (or Development) and it makes no difference to the front end displays they still shown blank pages.

Perhaps a cache problem, but no, clearing all the caches, in the system, browser etc., still makes no difference.  Nothing is reported in system or error logs what so ever.

Then a break though, we disable our SEF component and the pages display OK. So if must be something with the SEF component!  We reinstall an older version of the SEF component and it all works perfectly.  Re-install the current version of the SEF component and the blank pages re-occur.  Re-install the ‘older’ version and the pages are fine.

At this point we report the problem to the component author’s support forum.

Now frustration starts to kick in.  The support from the vendor says that there isn’t a problem, since there is no PHP error, and it doesn’t occur on our live site!  Exactly what sort of support is it they are offering? And this is a component for which we pay for support!  I will withhold the name of the vendor for the moment, perhaps they will improve, and it might be a problem at my end, although it is not looking likely.

I am starting to hate SEF with a vengeance, and this is just another straw that is ‘starting to break the camels back’.

At least we have a mechanism to enable us to continue testing our components for a forth coming release, but we really need to resolve this at some time, so it will be revisited when we have some more time.  Watch this space.

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.

Web Site Security

b2ap3 icon joomlaJust read a short article in the December issue of the Joomla Community Magazine titled ‘Ten Arguments That Threaten the Security of Your Website’ that is well worth reading.  It applies equally well to any web site but obviously the emphasis is upon Joomla.

The point about always keeping your website up to date with the latest patches in particular is one that I usually have to use every week, when looking at reported problems our component users are experiencing.   Usually the Joomla version is several if not many versions behind current.  Perhaps one might miss or not have time to always be upon the latest release but there is really no valid reason for being, in some cases over a year behind.  It is just asking for trouble.

I recommend it for a worth while read, it is reasonably short, but quite concise, and unfortunately so true in many respects.

Problems with ReCaptcha display

ReCaptchaWe have been seeing a strange problem on our site where the ‘ReCaptcha’ challenge was not always being displayed when it should have been. Most notably this is/was seen on the site registration page, but was not just restricted to that page. A complete page refresh often resolves the problem and shows the Captcha block.

We today saw that a change is proposed for the next Joomla update. It is mentioned in this post from OSTraining, which in turn refers to the fix itself which is extracted from this doc.

The basic problem seems to be that Google changed the URL’s of the Recaptcha API location, which doesn’t completely explain what we are/were seeing, but implementing the fix cannot do any harm and may even resolve the problem.

We will watch it for a while and see whether it completely solves the problem, but recommend it is implemented on your sites if you are experiencing ReCaptcha problems.  It does require FTP or SSH/Telnet access to change the plugin code.

Update 29/11/2013: Doesn't solve the display problem, so still investigating.

Go To Top

The Macrotone Consulting Web site would like to use cookies to store information on your computer, to improve our website. Cookies used for the essential operation of the site have already been set. To find out more about the cookies we use and how to delete them, see our Privacy Policy.

I accept cookies from this site.