update iconJust recently we've noticed somethig odd when using the update streams from the Akeeba Release System for our new released extensions.
Somehow our new extension do not return any update information in the Joomla! backend environment when a new release is available? First I thought it was just some typo in the FoolLog component update so I started the bug journey from there.
First I've checked the XML manifest for the correct update server link and it's extension ID. To make sure everything is set correctly I compared it with other XML manifest files from our extensions. I concluded that link was correct and copying the link in the browser showed me the correct update stream XML data - a new version could be found in the XML data. For the next step I went to the Update Sites Manager in Joomla! to check all is setup correctly and nothing for the FoolLog component is disabled. All looks fine too.

A bit stunned I decided to install an older version of our BreadCrumbs Advanced module in a test environment which I was certain off the update function was setup correctly. Installed the module, checked if it was installed succesfully and after that started to search for any updates using the Extension Update Manager. The result? Nothing. Just no updates what-so-ever?!
Allright than let's get online to our website and see what's going in the Akeeba Releas System update streams. First check the module update stream - which worked perfectly for months - and see what is set in there. Let's click the XML that should be generated... hmmm.... seems fine too - it is generated as it should and contains all the necessary data to correctly update.

Still not fully convinced the update stream settings were correct I decided to adjust some settings; changing the Element naming, changing the Site area, changing the Package naming pattern but no results. The updated version was not found for the module.
Thinking I could have misted something in an update for the Akeeba Releas System I started reading the online documentation (once more) for ARS. As I had already expected all settings for the update streams are set correctly according the ARS manual.

Whatever setting I would change no update is shown for the module - and I am one hundred percent sure the update is available! So, let's start some debugging and try to read some values from the core Akeeba Release System update function. And I do not want to bore you as a blog reader so I'll skip the code I've used to debug - but some strange thing popped up. The XML update streams data is read when checking for updates but the environment version compare returns 3.x every time. Is it even possible to check a such result as a number (integer)?
The environment?  The working environment..... The Joomla! version? Wait a second! The ARS control panel has an Environments button which can be set for each downloadable item and it is also check upon an update request.
After renaming the XML update stream platform for the selected Joomla! enviroment (set in the ARS Environments) from joomla/3.x to joomla/3.8, I clicked the Find Updates button once more and I've got the result I was looking for this entire day! An update version to download!

After checking every Enviroment type in the ARS and renaming when needed all update streams work as they should; just perfectly!

We're using the great Akeeba Ticket System to give our customers support for our products. It's a great tool with a lot of flexible configuration possibilities. To use it correctly we needed to configure the system and set all the security for folder access, uploads of images and other kind of attachments to make things secure.

The Ticket system seemed to work correctly after testing. Creating a ticket, reply to a ticket, upload images or other attachments, all worked well. Let's go live! Great!
Testing is the first step but going live is the real test; in the first days a few little things we're noticed by our users and it was just a matter of fine-tuning some settings. After a few days reports of users started getting in about not being able to upload image attachments.
That's weird and ofcourse I've tried uploading some myself. Hmmm, all seems to work fine - could it be an issue with the user rights? After comparing the user rights and all looked fine I created a new user, created a ticket (as that user) including an image attachment and it does get uploaded correctly?!? I'm fallbergasted...

Back to the drawingboard: check the upload file extensions in the Joomla! Media Manager, because that's responsible for the uploads. The image file extensions like jpg, png and more are present so that should be correct - which I already knew because uploading did work. Well, than it must be some configuration setting in the Akeeba Tickets Syflabbergstem and maybe the Support of Akeeba already has some issues described like this. But, no, the Support from the Akeeba site points to all the configuration settings in the Media Manager, Akeeba Tickets System and the .htaccess file I've already checked ánd double checked! All should work fine so why isn't it?

Just one more test but now I'll use some other pictures (png/jpg) just to see what happends. First attachment file "image01.jpg" was uploaded correctly but than the second file "image02.PNG" returned an upload error: "The file extensions is not allowed!". Do you spot the difference between the two file names? Right! The name of the file extensions, that's true but the other difference? The CAPITAL writing of the file extension!

I went back to the configuration settings of the Media Manager; added the 'PNG' (in uppercase) at the end of the line and tested it. BINGO! The upload with the "image02.PNG" works perfectly.
Now I've added all file extensions in lower- ánd uppercase to the Media Manager configuration so that shouldn't be a problem anymore.

Never thought this would be an issue when using a sophisticated CMS like Joomla! - maybe it can be implemented in the next update so we don't have to add file extensions twice in the Media Manager configuration and prevent brainteasers like this :-)

logo ajaxSo, I want to implement a simple like/dislike plugin on our website for this new blog section. Just to get some idea if people follow and like (or dislike) individual blog-articles.

And before I start to reinvent a plugin I searched the Joomla! Extension Directory for some easy-to-use plugins. And there it is; the Egolt Like plugin from Soheil Novinfard. Although the plugin isn't worked on or supported anymore, it should do the 'trick'. At least, that was what I thought.

First I started testing in our local web-environment (ofcourse) and had to made some layout adjustments to the included CSS sets/icons to let the plugin better integrate with our website. After this some jQuery code was put in to move the like/dislike buttons in the "Created date" description list (<dl>).
So after a few hours editting, changing, coloring and adding code everything seems to work well. The buttons can be clicked, a nice animated loader is shown and the counter works perfectly. Time to put everything online!

To be sure everything looked good I've created a test blog category and article to be viewed by administrators only. The article loaded fine, the buttons are shown at the correct place and with the correct selected theme. Let's click the "Like  button, the animated loader is shown and ... eh... and... eh... what is going on? The animated loader is still showing ... but it should disappear after a few seconds to show the increased Liked counter.

Well, a few things must be checked: test the plugin again in our local web-environment: check! All works fine. Check the plugin parameters on our live site: check! They are exactly the same as in our test site. Let me just reinstall the plugin once more: check! That should do the trick. Sadly, no, that wasn't it. No matter what I do the loader image keeps rotating in the button and no counter is refreshed :-(
Wait! Let's compare the plugin files from our live site and the test site; maybe the installation package (XML manifest)  isn't working correctly. Hmmm, no luck either.htaccess

Think, think, think (pulling my hair out), what am I missing here? I checked every file, every setting and finally it hit me! In the test web-environment we have one file renamed, the .htaccess file, to disable it's functionality. Let's rename it back and see what happends.
Bingo! Now our local environment shows the same issue and then the solution sinks in: the Egolt Like plugin uses an AJAX call when hitting the Like/Dislike buttons. Clicking a button should show the animated loader, adds +1 to the already known votes and shows the sum of the votes without refreshing the webpage (that's what AJAX will do). But the .htaccess is blocking direct access to this file so the AJAX call is never run.

The solution to this AJAX struggle is simple; I've added the file from the plugin folder - which is responsible for the AJAX calls - to the .htaccess file so it can be accessed directly by the site. And now all works fine! Wanna try? Click the Like button at the right corner of this blog article :-)

UWiX circle(75x81)First of all, let me introduce myself. My name is Nikolai and I'm a PHP programmer for UWiX. Ofcourse my knowledge reaches a bit further than PHP only. I'm also familiar with HTML, CSS and some other programming languages like Pascal/Delphi.

That said, let me explain what you can expect from me in the programmers blog. I want to write down my experiences during programming for Joomla! (and other types of programming) and show you methods I use while developing. I secretly hope that I will be able to make it a bit easier for other programmers to develop code. :-)

When developing plugins I've ran into the problem of debugging them correctly. Most of the time I want to debug some variable or output results. The print_r function seems to do the trick most of the time but the disadvantage of the print_r function is that it can screw up the page layout when testing. Well, not for a string variable but when outputting an array it can result in a lot of scrolling on the Joomla! page.

And what about methods that work in the background and do not produce any page output? In that case the print_r function is useless and logging to a file would be much easier! Sure, I can use the JLog function but takes several steps and switches before I can implement it in my source code. And sometimes I just want to view the written log data quickly.

To keep it simple I've created a small function (method) to include in the PHP file I'm working on.. Just a copy and paste will do and from within the PHP file I'll write values to a log file by using one line of code. Let me show you the function:

function writeLog( $varToPrint = '', $includeRequestVars = false, $appendToLog = true)
    $logFileName = "C:\\xampp\\htdocs\\debug_triggers.log";
    // Create the log strings
    $logStr  = 'Called from : ' . basename(__FILE__) . "\n";
    $logStr .= '$varToPrint: ' . "\n";
    $logStr .= print_r($varToPrint, true) . "\n";
    // Include $_REQUEST (form submit)?
    if ($includeRequestVars)
    	$logStr .= '$_REQUEST variables: ' . "\n";
	    $logStr .= print_r($_REQUEST, true). "\n";

    // Append to log or overwrite?
    $append = ($appendToLog) ? FILE_APPEND : 0;
    if (file_put_contents($logFileName, $logStr, $append))
        // Write succes message to Joomla!
        \JFactory::getApplication()->enqueueMessage( "Succesfully logged to " . $logFileName, 'notice' );
        // Write error message to Joomla!
        \JFactory::getApplication()->enqueueMessage( 'Cannot write to logfile: ' . $logFileName, 'error' );


 How do you use it? Simply add this line in the function where logging is needed:

$this->writeLog( $variableToDebug );

 Do make sure you adjust $logFileName to a path on your own system.


If you want to know what is submitted by Joomla! when debugging you add 'TRUE' as the second parameter for the _writeLog function so all _REQUEST variables are written to the log file too.

$this->writeLog( $variableToDebug, true );


Last option for this function if the parameter to append your logging to the log file or just overwrite it. When using FALSE as third parameter each new _writeLog call will overwrite the current log file.

$this->writeLog( $variableToDebug, true, false );


When the logging is succesfully completed a nice message will appear at the top of your Joomla! page stating the file is succesfully written. If something went wrong writing to the log file this will also be shown. That way you can always check if the log file is updated or just not written.

Have fun with this function and keep on 'happy coding'!