Well, I haven't had as much time to spend on development as I might have hoped these past few days - but the time I have spent on the component and in particular on the plugin (mambot) has proved particularly fruitful.

In the last few days a couple of issues arose that at first I initially thought weren't significant - but there is often more to these things than meets the eye. A little digging can turn up some remarkable shortcomings in Joomla and in PHP, not to mention in my programming.

mosAPF and Products From Multiple Locales (Countries) 

I was asked on the Joomla forums whether the mosAPF mambot could show products from multiple locales. Of course it can I told myself and off I went to build a page to prove the point. Everything worked fine - straight out of the box, can't argue with that I thought. 

New Beta (test) Version of MrRat's APF 

So later that day I decided to test drive the latest version of MrRat's fabulous Amazon Products Feed script - you know the one that does all the hard work and that makes my 'bridging component' look so good.

I hooked up the latest version of the script and looked at my multiple locales on one page plugin test page. One of the locales wasn't showing up - instead there was a nice big Server 500 error where the German products should be. I checked the curl log file to see if I could see any obvious reason for the error. It turns out that when multiple mosAPF mambot tags are present on a page  the query string for each  request was being added to all that went before -  this  is quite wasteful and I am sure sooner or later a maximum length would be reached and an error would result.

I squashed the bug rather speedily. It was actually in the main component, which was first built with the assumption it would only call one page on each request. One quick edit and we had that solved.

Unfortunately that didn't solve my problem - but hey - I helped identify a slight glitch in MrRat's beta release so some good came of it.

Double Encoded HTML Entities 

Next I received a Personal Message from 'Rin' who drew my attention to an issue with title tags and the component.

Some special characters are given special meaning within HTML. Angled brackets (mathematical 'less than' and 'greater than' symbols) for example are used to identify HTML tags so can not be used in actual content. Obviously there are occassions when we want to be able to show these characters to the reader - so we use a special code 'an entity' which tells the browser to show the the special character. Examples:
< is used to display <
> is used to display >

Even though these entities are supposed to be invisible to site visitors (who sees the real character) HTML entities were being displayed in the browsers 'title bar' the area that tells you the name of the site and page you are on followed by the name of your browser - on the same line as the maximise and minimise buttons up at the top of the screen there.

I had actually observed this myself ages ago and dismissed it as a browser thing. I assumed that html entities placed in the title tag were just being displayed as is - not converted to their correct character for display

In particular titles with &#39; and &#40; embedded in them were particularly obvious. I viewed the source and noticed that the title actually contained &39; and &40; and the & html entity was correctly being converted to & for display - the problem was that these should have not been & in the first place - some other extended character was being converted to a html entity and such as &#39;  - special code for a left bracket - and then the & was again being encoded as & .

Problem Limited To APF Bridge and Not Present In MrRat's Script 

Now MrRat's script when viewed externally (not in Joomla) didn't do this - so something in my coding - or within the Joomla framework was doing this. Well I grab the title with a regular expression and just pump it into the Joomla function $mainframe->setPageTitle() - this was where a standard html entity was being double encoded. I set about trying to convert the html entities in the title to standard characters so that when the setPageTitle() function then converts them they would display correctly.

PHP and the Entity Decode Function 

PHP offers a function html_entity_decode that sounds like it should do what I needed - this would quite happily convert < or > character entities to their correct characters < and >. BUT it turns out it doesn't decode &#0030; numeric entities. That took a little bit of working out - I tried four different ways to make this work.

The Solution - unhtmlentities

Fortunately I found this function unhtmlentities($string) on this page  'http://uk.php.net/manual/en/function.html-entity-decode.php

This isn't a built in php function - but it worked like a charm - so now we can correctly display the product titles as Amazon provide them in our pages. This is also applicable to meta tags such as description and keywords.

I am actually quite wary of making 'unplanned' changes to the APF Bridge component in this manner - there is always the chance that I will introduce more bugs into the script when I don't plan these things in advance. Consequently whilst I hope the script is getting better - I actually increase the likelihood of releasing an error filled version - such is life.

The Moral of the Story 

If you do spot something not working 'ideally' don't be afraid to mention it. Even if I am initially dismissive make sure I have at least looked into the issue - you never know I may be missing an opportunity to greatly increase the scripts quality. I am quite hopeful that these tweaks will increase the search engine results of users of the script. Previous title tags - it can be argued - were malformed.

Hopefully this next upgrade will result in higher search engine rankings and more sales for all of us - when it does please remember your friends.