It may seem a strange title for a blog, but we have been looking at a small ‘opportunity’ in converting one of our components to Joomla 3.x.
First a brief explanation is required. The module in question is a PHP module which calls some Javascript code which in turn then calls a separate PHP routine. The error we were trying to resolve involved this ‘second’ PHP routine. The module was designed to display a Google map and the first PHP module sets up the display, the Javascript code builds up the required map and it is in turn, populated with data obtained from the database and formatted by the second PHP routine.
This ‘inner’ PHP routine was working perfectly on Joomla 2.5 but on Joomla 3.1 only the map itself was displayed, not the 'map points’. It was apparent therefore that there must be ‘code’ that was not Joomla 3.x compatible but how to find it. Code inspection did not reveal any apparent cause. The changes to remove JRequest and replace it with JInput were working fine, and attempts to use print, dump, enqueueMessage, etc. statements were accepted but would never display any information which one could see. [This might possibly be due to our trying to display text ‘after’ the ‘error point’, but am not totally convinced yet.] Inspection of error logs also were not informative, mainly it is suspected due to the Javascript ignoring the errors and proceeding to execute even after receiving a error from the PHP routine.
Two possible means of tracking the cause occurred to us. The first would involve creating a logging routine whereby we could write messages to a log file from the inner PHP routine or alternatively making use of the JLog class.
The second involved us inspecting the Javascript and using the console.log routine, which we thought might be a quicker way to find the cause of the problem..
For those not familiar with the console object, it provides access to the browser's debugging console. The specifics of how it works vary from browser to browser, but there is a de facto set of features that are typically provided. The most frequently-used feature of the console is logging of text and other data. There are four categories of output you can generate, using the console.log(), console.info(), console.warn(), and console.error() methods. Each of these results in output that's styled differently in the log, and one can use the filtering controls provided by the browser to only view the kinds of output that are of interest. There is a web page here that describes it in general with a slight emphasis to Mozilla(Firefox).
We have used the second mechanism but even here we met a few ‘opportunities’. Inserting console.log statements around the relevant calls to the inner PHP routine wouldn’t display anything in the Firefox Java console. This was puzzling because we could plainly see other Java errors in the log from other un-associated script errors. So we turned to using the Chrome browser and here we could immediately see the statements we were tracking.
By judicious placement of out console.log statements we soon found the error message which was a call to a $config->getValue statement. We noted reference to the JRegistry object in the error message to the call to the JFactory::getConfig method. We were aware of the deprecation of the getValue method for JRegister so could make our code change.
Changing this to a simple $config->get immediately resolved the problem.
Not all that difficult to resolve but unless one is completely conversant with all of the deprecated features very easy to miss, and even more difficult in our case to track down the cause.
We still do not know why the Firefox Java console wouldn’t display our ‘console.log’ statements. It may be related to out ‘Web Developer plugin’ but we have not investigated this any further. Certainly the Firebug add-on should work with console.log.