Macrotone Blogs

Macrotone blogs upon Joomla, our products and other matters.

An IT professional with a wide experience of IT systems, specialising in Database Management and Security.

Trouble Shooting Flow Chart

In a similar vein to our last Humorous post I also recall the proverbial Trouble Shooting Flow chart, a couple of which I show suitably bowlerized below.

This diagram and others that are similar are said to have circulated on the internet before it was the known as the ‘internet’ but is nonetheless certainly a distant iteration of the original.

Continue reading
Tags:

Rush Job Calendar

Sometimes the ‘old’ jokes are the best and we were reminded of this the other day when we were asked if we could add some new features to one of our extensions.

There are a few variations of this around but they all basically ‘resolve’ the same problem.

Mirday Friday Friday Friday Thursday Wednesday Tuesday
8 7 6 5 4 3 2
16 14 13 12 11 10 9
23 22 21 20 19 18 17
32 29 28 27 26 25 24
39 38 37 36 35 34 33

 

  1. This is a special calendar for handling rush jobs. All rush jobs are wanted yesterday. With this calendar a job can be ordered on the 7th and delivered on the 3rd.
  2. Most jobs are required by Friday, so there are three Fridays in every week.
  3. There are eight new days added to each month to allow for end-of-the-month panic jobs.
  4. There is no 1st of the month – thus avoiding late delivery of the previous month’s last-minute panic jobs.
  5. Monday morning hangovers are abolished together with non-productive Saturdays and Sundays.
  6. With no 15th, 30th or 31st, no 'time-off" is necessary for cashing salary cheques or paying bills.
  7. A new day – Mirday’ (sometimes called Negotiation Day) – has been introduced keeping the other days free for uninterrupted panic and for making excuses.
Tags:

Joomla date/time displays and Database vales.

b2ap3 icon joomlaHave been looking at an interesting problem of the display of date/time values on Joomla screens.

First it is apparent from looking at the database stored values that Joomla stores all of the date/time values (calendar) in the database as UTC values, which means that all of the stored values are consistent.

However when these are displayed upon a form or in a tabular form, care has to be taken that the format of the values is consistent.  For example if the displayed value is shown as a ‘text’ field, the values stored in the database (UTC) is displayed, which is not necessarily the ‘local’ time.  We are in the London area and currently are using DST (Daylight saving time) which is an hour ahead of UTC (GMT – Greenwich Mean Time) .  One has to make consistent use of the ‘calendar’ type and if necessary make it read-only, thus ensuring the correct value, suitably converted is displayed.

Another complication that we have not yet worked out the cause of is that if using JForm with the calendar type and using the default of ‘NOW’ which should display the local time (according to the documentation),  it displays a time value 8 hours ahead of the local time.  Where is gets that from I am not sure.  i.e.  If local time is 11:30m, the ‘now’ value as determined by the JForm default shows as 19:30.  Go figure!  It was necessary therefore for us to specify the default value as empty and assign a default value in the view based upon the local time so that the form value is correct.

We have therefore decided that to avoid confusion all date/time values should be displayed using local time.

CSS: Text wrapping in a table cell. Part 2

CSS logoWe previously made an entry about long text strings overlapping table cells.  It was time to relook at the problem again after we saw a few more instances on our site.

The problem is quite common and has been mentioned in various articles upon the web for many years.  Solutions have ranged from the use of code to add extra spaces into the text fields, sometimes using ‘hidden’ characters, to various suggested CSS additions, many of which have browser dependencies.

This article on Stackoverflow summaries the suggestions quite adequately, but unfortunately didn’t provide a suitable solution.

Finally I discovered an article which describes the problem perfectly with examples. It is quite old (2007) but still holds true even today, with many revisions of browsers later.

In our case the final table cell was overlapping the right hand side menu and module displays, with the modules on top obscuring the table cell contents. We resolved it by using the suggestion in the article by changing to a fixed width table. Now the word-break could work.  It does mean that some of the other columns are slightly larger but it does produce a more professional output on the site.

This change will be implemented in latter releases of the Issue Tracker component.

Template Override

Whilst investigating this problem we had forgotten that we had implemented a CSS table override for the component so it is perhaps worth mentioning that here as well.  The CSS override is created by creating a file in the templates directory under template_name/media/com_issuetracker/css/ named issuetracker.css.  A copy of the distributed CSS file would serve as a starting point.  When changes are made to this file they take effect and override those in the media/com_issuetracker/css/issuetracker.css file.  This means that any changes you make would still apply even when/if the component is upgraded.  It is a convenient place to test out small CSS changes.

Bootstrap templates width of 'Text Area' boxes.

b2ap3 icon joomlaWe have been looking at the size of the 'Text Area' boxes displayed within the Isis back end template and the Protostar front end template and wondering how to increase the width so that it maximises the available space as opposed to being restricted to the small (approx 200px) size.

Attempts to specify the number of rows and columns made no difference and searching the web didn't reveal any solution.

So we are sharing the 'fix' for the 'width' text area boxes which achieves what we were trying to achieve.

In the form definition XML file navigate to the appropriate 'textarea' field, and then modify the 'class' entry (or add one if it doesn't have one) to the following:

class="inputbox textarea-span"

The important bit is the 'textarea-span' after the inputbox.  We have tried specify specific span sizes after the 'span' but these do not make any difference.  i.e. span6, span8 etc.

Once the from is refreshed then the boxes will occupy what ever width is available.  This works with Isis and Protostar templates, so should work with any Bootstrap based templates.

Strange 1604 errors with upgraded Joomla 3.1.5

b2ap3 icon joomlaWe today tried an upgrade of a copy of our Joomla 2.5.14 site to Joomla 3.1.5 as a test to see just how much we would have to change and the work involved.

The upgrade seemed to complete successfully and then we started to look further.

There are some obvious component that do not have Joomla 3.1 versions and we found that there was a need to upgrade some plugins which were causing front end site errors of various types but mainly relating to Mootools. Nothing too difficult to resolve.

On the front end we then started noticing a few page errors 1604 with messages similar to the following:

You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FROM WHERE ='index.php?option=com_xxxxxxxx&view=yyyyyy' AND ='1' LIMIT 1' at line 1 SQL=SELECT FROM WHERE ='index.php?option=com_xxxxxxxx&view=yyyyyy' AND ='1' LIMIT 1

It is very evident as to what is wrong with the SQL statement but the question is why and where is the statement coming from.  It certainly doesn’t look like a statement in any specific module as far as we can see.  The particular components (and modules)  in question work perfectly fine upon a fresh install of Joomla 3.1.5 so I think we can eliminate the component/module from being at fault.  It is not restricted to one component either.

Disabling module(s) sometimes indicates a specific module at fault but as I said earlier the module(s) works fine on a ‘fresh 3.1.5’ install.

We have also seen ‘404’ errors reported when trying to install/upgrade an existing component to the latest version to run on Joomla 3.1.5.  Again the components install fine on a fresh ‘3.1.5’ install.

Of course it could be that the various components do not upgrade correctly on Joomla 3.1.5 but this seems unlikely especially as one can update the component successfully on a ‘fresh 3.1.5 install’.

Our conclusion is that it is probably the ‘Joomla’ upgrade itself that is at fault. Even ‘reinstall’ of the Joomla update doesn’t resolve the problems. Inspection doesn’t provide any clear ideas at present as to what could be at fault, so it is probably fair to not even contemplate thinking about updating our ‘live’ site just yet until a few of the remaining ‘issues’ are resolved.  There is a need to ‘preserve’ our existing data and an export/import approach doesn’t really bear thinking about.

One to revisit later possibly once 3.2 has stabilised.

Tags:

Implementing Joomla 3.1 Tags feature

J3.1-Transparent-bgWe originally implemented the Joomla 3.1 tags feature within our Issue Tracker component. This was done using the documentation[1] by Elin Waring the originator of the feature.  This worked fine until Joomla 3.1.4 was released when it changed to use the JObserver classes.

The basic change (as we understand it) is that the tag fields were originally stored within the ‘metadata’ field where as using the (new) JObserver class removes this requirement and the tag is not required to be saved with the item at all. Both methods were intended to be supported but the implementation is broken, but may well be fixed in a later update.

We found another document[2] describing the modified configuration/setup. The problem was we couldn’t get it to work as it was described.

We eventually found a solution which is as follows.

1) In the components table class we added the following line:

JTableObserverTags::createObserver($this, array('typeAlias' => 'com_xxxxxxxxxx.yyyyyy'));

Where the component is xxxxxxxxxx and yyyyyy is the tag type.  (The differs from the suggestion in the documentation[2] which we couldn’t get working.)

2) Double check the field mappings which get placed in the #__content_types table.  The configuration document[2] shows square braces in the string but these are not required or necessary.  It is also important that the field mappings accurately match the fields within the referenced table.  A small mistype or wrong name will result in an error being generated when the tab is saved.  It doesn’t help that the error message only tells one that an error has occurred not what the actual error is.  We found out through trial and error. [We note that there are a few other fields in the #__ucm_content table that can also be populated, notably the created_by_alias.]

3) We also found that we required the following in the getItem method of the model (despite the documentation[2] saying otherwise).

$item->tags = new JHelperTags;
$item->tags->getTagIds($item->id, 'com_xxxxxxxxxx.yyyyyy');
// $item->metadata['tags'] = $item->tags;

The last line we have commented out since we do not observe any impact of it being present.

4) In one of our tag types we were using the table class method called directly, calling the various bind, check and table store methods. This meant that some code that is required to handle the tags did not get called.  The easiest way we resolved this was to instead call the parent:save  routine. This was achieved by slightly restructuring the model save method and also meant that we didn’t have to add additional code and also enabled us to simplified our code.

5) The other change we made was to the 'Hathor' template view overrides to display the tags. Again the suggestion in the documentation[2] didn't work for use and we resorted to the standard display mechanism.

Updating Transifex Source files

transifexWe were in the situation of releasing a new version of one of our Joomla extensions and needed to update the source language files on Transifex. Originally we had loaded them via the web  to place them upon Transifex so immediately looked to do the same with the updates. Alas it didn’t seem to be possible, so we were forced to make use of the ‘tx’ client.

Fortunately the transjoomla site provided clear details of how to set up the client.  We then had to edit the created ‘config’ file so that it reflected our source files.  Then we used a command to update a single resource file as follows (again the example form transjoomla):

tx.exe push -r virtuemart.admin-plg_vmpayment_klarna_sys -s

(as in: sending the admin file "en-GB.plg_vmpayment_klarna.sys.ini" to "virtuemart" project)

We immediately hit a problem with a 401 Authentication error.  We looked at the ".transifexrc" file in our user-folder and sure enough the correct password was present, so it wasn’t a credentials problem.    After searching we discovered that our project ‘config’ file  was misconfigured for a different resource from the one we were updating. Once we had corrected that the upload of our changed resource file proceeded smoothly.

Only thing we are now unsure of is whether our translators are automatically informed of the change or not?

Another PC puzzle

windows7It must be the week for PC problems, since I was given another one to try and puzzle out the other day.

The machine was running slowly, and seemed to have difficultly in logging off users, shutting down, and even performing any long term tasks. Also noted that Windows Update would loop forever ‘Searching for updates’.   Even trying to run a virus scan kept hanging on files which I am reasonably sure were virus clean.  The machine wouldn’t ‘hibernate’ or ‘sleep’ and the user was forced to depress the power button to close down the machine.  To add insult to injury even the ‘task window’ was behaving erratically making diagnosis night on impossible, but when it did work the machine was showing less than 3% usage.

I have never seen a machine behave quite like this and immediately suspected a virus infection of some form. Norton and McAfee kept 'sticking' on various files when running and wouldn't run in safe mode for some obscure reason.  Even the McAfee program was refusing to use 'Real Time checking' and would periodically say it needed updating, even when at other times it was 'up to date'. Managed to run a virus scan using the excellent McAfee Stinger program in safe mode, which revealed that the machine was virus free, which whilst satisfying still got one no nearer to knwing what was going on.  Next various attempts were made to resolve individual symptoms with mixed success. Never could get Windows Update to work reliably though.  Even resorting to system restore and using the oldest restore from a month earlier, exhibited the same symptoms.

After wasting several hours trying to pin down the source of the problem the final step was just to bite the bullet and perform a factory reset, having ensured that I had copies of all the users files (documents, music etc.).   The restore worked perfectly and then comes the task of updating it with all of the latest Microsoft updates, which is no small task.  It is at times like this that you realise just how many fixes Microsoft release for their operating system. Several hours later it is still finding more fixes. Once you have run an update, running it again shows even more fixes are found.  It took six, yes six separate update checks to get up to date and that is just for the operating system itself, not for the Microsoft applications (Office). 

Next to load the user applications and copy back the users files.  In all over 24 hours have been spent dedicated to just getting the machine back to a usable state and I still have no distinct idea of what was causing the problem in the first place.  No viruses appeared to be present with all virus software fully up to date, and the program installation history indicated nothing new had been installed for several months.  Obviously a few program updates may have been made to things like browsers, but the problems were present even with no browsers active (but background processes were of course still present).

I suspect I may never really know what was the cause of the problem and searching the web doesn’t throw up any similar reported situations. One to put down to ‘unknown’ I guess. Never had to resort to a Factory reset before, but it proves the worth of the manufacturers (in this case HP) supplying them in a reserved disk partition.

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.

Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries