Macrotone Blogs

Macrotone blogs upon Joomla, our products and other matters.

Experiences with JQuery and Dialog boxes

jqueryWe recently started work on a plugin enhancement that was intended to add a ‘button’ to an existing form programmatically which when pressed would open a ‘popup’ window where the user could review a generated ‘parameter value’ and either accept it or regenerate the value until an acceptable value was obtained, before returning to the calling screen, where the value is inserted into an existing form field.

With the design intent decided upon, the fun part of making the change started.  Firstly the existing form is an already existing Joomla form which for obviously reasons we do not want to modify, other than programmatically.  We looked at using Mootools  initially, but this is gradually being replaced by the use of JQuery, so it seemed sensible to start using JQuery.  An additional consideration is that the JQuery UI tools, specifically the Dialog boxes look very useful.

After much testing and frustration we discovered that there are some specific ‘id’ specifiers that JQuery does not like using. For example we could place the ‘button’ using the id field on the JForm label tag, but not on the JForm input tag.  No error messages were ever seen, just that the instruction was silently annoyed.  This seems to be related to the specific ‘append’ function we are using. There is the possibility to use ‘append’, ‘prepend’, ‘after’ and before (ignoring ‘appendto’ which is the same thing only with the arguments transposed). The input tag does not accept the use of append (or prepend). Very strange.  Investigation isn’t helped by the fact that viewing the web page, doesn’t show ‘our’ added button etc in the HTML code, presumably since this is not the ‘source’ web page but one we have modified. Not sure, or indeed found a solution to this particular problem yet.

Since we were using an existing (base form) we not only had to add the button to the form but also add a place holder for the JQuery UI Dialog box, otherwise the dialog box is never displayed.

Another challenge is the CSS involved with the additional strings. To get the popup box, one has to have  the CSS included in the page usually with one of the JQuery Template CSS types such as smoothness. Unfortunately this also changes the CSS of the newly inserted button used to call the popup. This is not really desirable since we want the calling page to ‘look’ like the existing form page with the exception of our added button. [Note this applies even if instead of a button, we use a simple anchor link to the popup, so is not specific to the use of a button.] So it is necessary to also include code to remove the CSS from the button that we had inserted to call our ‘Dialog box’.

Creating the generated popup window contents was relatively easy, as was also inserting the generated values back into the main form once the user has accepted them.

Since we want also to pass in certain parameters to the generated ‘parameter’ creation  code behind the ‘Dialog box’ we decided to add the Java via a PHP routine call. In this way we could also ensure that the appropriate language strings were also passed in, thus ensuring that the plugin was ‘multi-lingual’.

We do not consider ourselves Java experts by any means, but have little difficulty in generally getting what we want working.  We still a little bit of tweaking to perform on the java code itself, but we are pleased to say that it is working very much as intended so will be included in the next release of out Password Control plugin.

It was ‘fun’ although somewhat complicated by the apparent inconsistences of getting the initial button placement working in the desired position, and the need to modify the CSS on our original form for our newly placed button. The jury is still out on whether it is better than Mootools, but since Joomla is heading towards greater use of JQuery and phasing out Mootools it is a route that more and more will have to follow.

Strange PHP error on live web site.

Noticed late yesterday a strange error occurring on our website when a specific article was accessed.

image

 

The error is :  DateTime::__construct(): Failed to parse time string (about 5 months ago) at position 0 (a): The timezone could not be found in the database

 

Nothing had been changed on the page for some time so I think this is some form of PHP bug.  [Currently running 5.4.11].

To resolve it I had to copy the offending article and then just point the menu items to the copy.  This indicates that it wasn’t anything specific about the article itself that was wrong.

Since the error is not specifically related to something that I/we have done, it is obviously something to report to the hosting company.

Not reproducible on any of our test instances, and of course it had to occur on the ‘live site’.  Isn’t that always the way. Smile

Tags:

Joomla Development hints and tips

Whilst working on some Joomla component developments I encountered a few problems which, whilst I had encountered them, before didn’t stop me wasting time resolving them again.  So I have decided to post them to the blog in case others have the same sort of problems and it might save them some time.


1.  In a component item list view, the message ‘ Notice: Undefined property: stdClass::$editor in ~administrator/components/com_xxxxx/views/yyyylist/tmpl/default.php on line zzz’ was encountered.  This message was coming from the template file and related to the check of whether the item was checked out or not.   The item is returned directly from the database table but there was no ‘editor’ field in the table.  

What was required is a simple select over the table with the Joomla users table as follows.

        // Join over the users for the checked out user.
        $query->select('uc.name AS editor');
        $query->join('LEFT', '#__users AS uc ON uc.id=a.checked_out');

Where I was wasting time, was thinking that the ‘editor’ was the actual physical editor being used on the item, rather than the ‘person’ who was the ‘editor’ of the item.


2.  In an item view the JToolBarHelper buttons did not appear to be doing anything other than appending a ‘#’ to the end of the URL.    This one had me a little puzzled since the parameters to JToolBarHelper were perfectly correct.    The problem eventually turned out to be related to some coding in a java script incorporated in the default template.   The error was not generating any messages and it was only by a process of elimination that I tracked it down.

So the moral is to check for Javascript errors before assuming a php coding error !!


3.  The third opportunity was to discover why the use of an Editor (such as JCE) persisted in stripping out HTML code from the input.   I found an article on the JCE web site that explains about changing the text filtering options:

(Joomla! 2.5)

    In the Joomla! Global Configuration, click on the Text Filters tab.
    For the Super Users group, or any other trusted user group, set Filter Type to No Filtering. Make sure that you only set this option for user groups that can be trusted as setting the Filter Type to No Filtering will essentially allow the user to include any html in an article.

However checking my settings showed that I already had them set but I was still getting the HTML codes stripped out.

Investigation into the possible filters that can be applied to the editor field in the XML file for the object revealed a solution.    The possible filters that can be applied (which I discovered from code inspection) are as follows:

 

Filter Type Description
RULES A defined rules array
UNSET Do nothing.
RAW No Filter.
SAFEHTML Filter safe HTML
SERVER_UTC Convert a date to UTC based on the server timezone offset.
USER_UTC Convert a date to UTC based on the user timezone offset.
default Checks for a callback filter using either using the callback method or using the callback function.

 

        
   The solution I wanted was to set the filter to ‘RAW’.         

Use of ampersand or not

I have recently been looking at the use of ‘Strict Standards’ and the impact upon any Macrotone written extensions.  One thing that has struck me is the use of the ampersand when making calls to JFactory (and other similar functions).

A lot of the examples on the Joomla documentation site show the call with the ampersand present, but it then generates a warning message if ‘Strict Standards’ reporting is turned on.

i.e.  Is it:

1.   uinfo = JFactory::getUser($user_id);

or

2. uinfo = & JFactory::getUser($user_id);

My understanding is that the ampersand after the equals sign is not required.  It was necessary to let PHP4 know that we wanted to assign a reference of the object to the variable instead of a copy. In PHP4 if the ampersand was not supplied it created another copy of the requested user information.   The default behaviour in PHP 5 is to assign by reference and using the ampersand produces a notice.  Joomla! 2.5  only runs on PHP 5, so the ampersand is not only redundant, it also throws a  strict notice.   I suspect that in PHP5 that if any extra instances are created by the use of the ampersand that they will be closed by the garbage cleaning when the containing function or class is closed, so apart from the Strict Standards warning message it is not really a problem at all.

Tags:

Technical Article links

The following are interesting articles that are generally informative and may prove useful to someone in the future.

Scaling a PHP MySQL Web Application, Part 1

Scaling a PHP MySQL Web Application, Part 2

The DBA’s Guide to Setting Up Oracle RAC One Node and Oracle Data Guard

The DBA’s Guide to Setting Up Oracle RAC One Node and Oracle Data Guard, Part 2 (Advanced)

MySQL and Oracle Goldengate

Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries