Macrotone Blogs

Macrotone blogs upon Joomla, our products and other matters.

Rialto a new classified ads component for Joomla

rialtoWe are pleased to announce a Classified Ads component for Joomla named Rialto.

This component runs on Joomla 3.4 (and above) only.  Wikipedia defines Classified advertising as a form of advertising which is particularly common in newspapers, online and other periodicals, which may be sold or distributed free of charge. Advertisements in a newspaper are typically short, as they are charged for by the line, and one newspaper column wide. An advertisement as seen in a newspaper, magazine, or the like is generally dealing with offers or requests for jobs, houses, apartments, used cars, and the like. The Joomla component permits a site to accept such advertisements from its registered members and acts as a conduit between purchaser and seller.

The name is derived from a historic market district of Venice, Italy, named the Rialto, located close to the Grand Canal and to the 16th-century Rialto Bridge. It became the business centre of medieval and renaissance Venice. Since that time the word has come to have a few other meanings such as 'agora', 'forum', 'marketplace', 'shopping place' etc.

Creating a category on component install.

We were looking at an easy way in which to create a default category for a Joomla component which we are developing. The problem is that a common insert directly into the table is not sufficient since the ‘#__categories’ table is actually a ‘nested’ table, and it would be necessary to rebuild the table entries after an insert anyway, otherwise the table could/would be corrupted.

We searched around for a possible solution and eventually found a method which we could adapt for our usage.  We present our resultant function below:

Continue reading

Newsfeeds display – solution to an enigma

b2ap3 icon joomlaWe have always displayed a few relevant newsfeeds upon our web site, but it has never, to be honest been very high on the visitor list, or upon our own priority list. We long ago noticed that the default display for the ‘Newsfeeds Categories’ in the front end of our site comprised merely of two lines, one for each of the two newsfeed categories we use, which also acted as a link to the underlying newsfeeds in the respective category.  There was no page header, no display of the breadcrumb information, and no details of the category descriptions.  In short  a very barren page.

Originally it was suspected that it might be a template or CSS type problem.  Attempts to change the menu settings, resaving module specifications etc.,  all proved fruitless.  It didn’t matter what the menu settings were, they were silently ignored.  One is tempted to say it was a cache type problem, but bearing in mind that this has been the situation for several months, if not longer  and the various caches’ had been manually cleared several times during that period, it was obvious that something else was amiss.

With the change to a new site template, the situation remained unresolved and it was starting to get a little bit annoying.   So given a hour or so spare we decided to investigate further.  Inspection of the PHP code underlying the display revealed no clues, and despite retrying all our previous steps we were no further forward.

Searching the web for similar reported problems drew a complete blank, apart from a link to a very strange problem we had ourselves encountered with the display of breadcrumbs on a previous occasion.  Looking back we found out previous blog entry. [So keeping a blog can prove useful.]  We thus decided to clear all URL entries from the sh404SEF component for the com_newsfeeds component.  Low and behold on refreshing our web page the correctly formatted page was shown, complete with headers, breadcrumbs, descriptive text etc.

We realise that sh404SEF keeps track of URL links, but why this should impact the page display is currently a bit of a mystery.  It doesn’t itself cache pages, but must somehow also keep track of which modules and what the ‘previous’ settings were for a page ,for which it is keeping a record of the link.  I am sure that I have never read anything of this sort in the component documentation.

What we learnt gain from this is that sh404SEF seems to have some strange characteristics which impact what is displayed upon a screen, far and above just converting non SEF URLs to a SEF format.  So it you are ever seeing a similar type of problem and every thing else seems to failing to resolve it, it might, if your site is using sh404SEF be worth clearing your entries and seeing if it resolves the problem.  Certainly stranger things have happened.

Issue Tracker Template Overrides

b2ap3 icon joomlaWe have recently been ‘playing’ with a new ‘Bootstrap v3’ template for the front end of our site.  This involved use creating a set of template overrides for our Issue Tracker component and we decided to share the details with our users.

Joomla has long had the ability to create Template Overrides, which are modifications to the Joomla components or modules. This permits changes to be made upon a ‘local site’ basis without the need to change or hack the supplied code.

We are primarily concerned with the Issue Tracker component and we have tried hard to produce front end displays of Individual Issues and of the Issue Entry form that would be usable in the majority of installations. However the differences between the various template used on sites are many and vast, and it is almost inevitable that they will not be suitable for everyone. This was indeed the situation we discovered ourselves when using a BootStrap template for the site.

Continue reading

Discussions forum migration to Kunena (Part 3) Images

kunenaThis is the latest (and probably last) post on our migration exercise for moving Discussions forum to Kunena. [Last post is here.]

Our previous posts did not discuss or address the question of images which are contained in forum entries. The two forums basically store images in the file system and then refer to them in the posts, however the way they do this is different which makes an automatic migration difficult.

First the images are located in Discussions in the directory images/discussions/thread id/post id/[large][original][small]  in the three separate directories each one reflecting a different size of the image, the entries in the ‘small’ and ‘large’ directories being is created when the image is stored.  The images details are then stored in the database table #__discussions_messages as extra fields in the table.  When the post is read the images are appended to the message and shown on the web page.

Kunena stores the images in directory media/kunena/attachments/[user_id], where user_id’ is the identifier for the user saving the images, and stores the image details in a separate database table #__kunena_attachments. The actual forum post is modified, within the #__kunena_message_text table, if the image is to be shown within the post, with tags referring to the actual image itself.

To automate this task would require the population of the kunena attachments table with the image details, after the images have been copied to the ‘new’ Kunena location, and also the specific messages in the #__kunena_message_text table would need modification to add the appropriate inclusion tags.

We have analysed the images in our ‘old’ Discussions forum and found less than a dozen images in total, and given the amount of work that would be required to automate this, have decided that it is probably not worth the bother, and that a one off manual task would be far quicker.  It also enabled us to ensure that image sizes are below the bounds specified in the Kunena configuration file.

Note: We do not have any embedded videos to consider so will not investigate this topic at all.

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.

Design Criteria for processing emailed issues

We have been busy with a forthcoming feature for our Issue Tracker, which is the ability to receive emails with details of new issues or emails containing updates to previously raised issues.

After much thought and consideration the following design criteria are  deemed necessary in the email issues functionality. They are included in no specific order of

Continue reading

Problems installing a Joomla component

joomlaWe met a very strange problem when we had to re-install a third party Joomla component.  We will not go into the details of why we had to do a fresh re-install, sufficient to say it was to try and fix an ‘opportunity for improvement’.  We couldn’t uninstall using the standard Joomla mechanism because we wanted to retain all the underlying database tables used by the component so did a manual uninstall instead.

The component was quite large but we extracted all the files and placed them in the tmp directory, so it was easy to reinstall until we determined the cause of the problem.  [We encountered a few MySQL Error 2006 – DB Server has gone away’ messages, but apart from being annoying were not really causing a problem.]

The component ‘spun’ its icon and then presented us with the following messages:

"Component Install: DB function reports no errors"
"Error installing component"

In addition an entry was make in the #__extensions table but no files are ever installed.  It is impossible to remove it via the Joomla ‘Manage’ feature and all one can do is remove the entries from the table via phpadmin (or similar).

Attempts to re-install again, are repeatable and every time a new entry was inserted into #__extensions.  If one tried several times, several rows were created.

Then we found this problem report, which had all the symptoms we were seeing.  It was raised against Joomla 1.6 but was still very useful. The clue was the mention of the #__assets table and sure enough we found a single line entry in the #__assets table which we could then remove and the next attempt to reinstall worked perfectly.

Running scheduled (cron) tasks with Joomla

joomlaWe have recently developed a feature with one of our components to make use of a scheduled task to perform a repetitive action, which avoids the need for us to enter the site and manually click upon various icon(s) which in turn cause the required action(s) to occur. Such a requirement is reasonably common and includes things such as sending scheduled emails etc. We were expecting it to be difficult to implement but as it turned out was pleasantly easy to achieve.

Upon UNIX based systems ‘Cron’ is a daemon that provides a time-based job scheduler that runs in the  background on UNIX systems that executes commands at specified intervals. These commands are called "cron jobs."  Windows servers use a Scheduled Task to  execute commands. Typically a task requiring repetitive actions  to be carried out on a regular (pre-determined) basis would be ideal candidates for using ‘cron’.

There are basically a few methods that can be used to provide a  scheduled task within Joomla. The preferred method will depend upon the specific web hosting supplier and the facilities they supply. [For our implementation it was necessary to supply both mechanisms, since some of our users’ systems may not have one or the other.]

Continue reading

A new Audit tool for Joomla

auditAbout a week ago we released a new component for Joomla named JAudit.

Running upon Joomla 2.5 and Joomla 3.x this is a comprehensive auditing component that makes use of the underlying database to log changes made to the Joomla tables. It does not require any changes to Joomla core code and should work without impacting any Joomla functionality. The component requires that the system has been granted the appropriate database privilege to create database triggers.

We have long believed that if you are using a fully featured database upon your Joomla site it seems ‘silly’ to not make use of the features that the database provides.  Databases these days are very feature rich and it is only necessary to look at the possibilities of these features to realise just how much one is missing out upon. One analogy that brings this home, might be ‘Would you pay for a Ferrari and only drive it around in first gear?’

Continue reading
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.