oscMax as an alternative to osCommerce and CRE Loaded.

I downloaded oscMax 2.5beta3 today as I am experimenting with osCommerce & CRELoaded without the success I wanted. oscMax retains the appropriate open source policy that CRELoaded seems to lose within its own conflicting interest of selling the ‘fully featured’ version. While the original osCommerce still languishes behind Harald’s dominance of the code and lengthy periods of apparent inactivity.

Why am I looking? Because I recently discovered that my old version of oscommerce had succumbed to hacking. I dont need to publish the details but suffice to say that while I have cleaned up the mess, I am skittish about it happening again and I want to bolt it down as much as possible. To do so I want a current stable platform without needing to manually edit / install a small mountain of add-ons.

CRELoaded has been a great alternative over the years but the above mentioned conflict as they try to make a sale-able product along-side a cut-down version as a loss-leader just does not work for me.

Enter oscMax. Yes, it has been around in various forms for a number of years, but I have only just tried it in it’s latest version.

Verdict? The case has only just started, but it’s osCommerce, pre-loaded with most of what I need, and fully open source. So at this stage I am working on a trial system and tweaking what I need to make it work.

oscMax Admin page reports configure.php as writeable when it is not

My first modification to oscMax while I test it for use on my store.

The admin screen on first login will advise if the includes/configure.php file is writeable. This message will persist regardless of the settings of the includes/configure.php

The issue is that the admin/includes/configure.php settings are referenced with the same error message settings as the catalog configure.php.

An option to fix this is to rename the constant in admin/includes/languages/english/index.php at line 115, but given that both the catalog and admin files should be checked as a rule, I’ve added a new constant for the admin file and made another alteration to test both files.

This will help new users when first setting up oscMax as I think the admin screen is commonly the starting point and to highlight the permissions issue for the catalog in admin as well would be helpful.

The required changes to support this are:

admin/includes/languages/english/index.php
modify the setting at line 115

[php]define(‘WARNING_CONFIG_FILE_WRITEABLE’, ‘Error: I am able to write to the catalog configuration file: ‘ . (DIR_FS_CATALOG) . ‘includes/configure.php. This is a potential security risk – please set the right user permissions on this file.’);[/php]
:: only change is to add the word ‘catalog’ in the text.

Then add a new constant setting at line 116
[php]define(‘WARNING_ADMIN_CONFIG_FILE_WRITEABLE’, ‘Error: I am able to write to the admin configuration file: ‘ . (DIR_FS_ADMIN) . ‘includes/configure.php. This is a potential security risk – please set the right user permissions on this file.’);[/php]
:: the main changes here highlight that its the admin configure file that is the issue.

Then update the system.php file that calls the above messages:
:: the main changes are copying the config check to test the catalog configure, the nesting of the dirname function to get the parent directory for the catalog, and the change to the code comments to differentiate between the two checks.

admin/includes/modules/dashboard/system.php
at around line 117 to modify the existing admin file check to use the new constant above and to copy/modify this section of code to check the catalog at the same time.

This should result in the admin home screen presenting two different warnings if either (or both) of the configure.php files are writeable.

If you copy and past from the above you should paste it to an editor that will check syntax as the formatting 0f the ‘ characters is incorrect. The comments are also doing something funny and I had to edit them.  I’ll try to update this post with working copy and paste at some stage.

rsync windows failed: Invalid argument (22)

Rsync from linux server to a Windows server as a redundant backup using cwrsync but getting an error for the chown command on the directories being backed up.

The issue was simple enough, stop telling rsync to change the owner as the linux command is invalid on the windows server.

[php]rsync -atv /directorytobackup/ windowsserver::cwshare
[/php]
changed to
[php]rsync -rtv /directorytobackup/ windowsserver::cwshare
[/php]
and all is now quiet from an error message perspective.

Thanks to Marcin and Linux Questions Forum for the solution.

Kayako HelpDesk email settings and Ticket Post Reply Slow

I have used Kayako HelpDesk for around 3 years and had pretty much forgotten how it was setup originally. Over the past 6 – 12 months the process for posting a reply has been taking a long time, i.e. 40 seconds or more from the moment you click ‘Send’ to respond to a ticket and the application returning the user to the ticket listing ready to select another task. It was odd, but as it was still working, and was possibly just an issue with size of db, or similar, we(I) ignored it.

I was making a change the other day and noted that our setting in the Admin -> General -> CPU & Server settings for the SMTP server was not correct.

[php]
SMTP Server: mailserver.forexternal.relay
SMTP Port: 25
[/php]

Now I knew that our exchange server for the external email was not using port 25 as under Exchange 2007 and Server 2008 the preferred config around preventing open relays is to vary the SMTP port. The hostname itself was correct, so I changed the port to the ‘correct’ port and saved the settings. I then finished the other change and logged out.

A while later I was completed a ticket response and was stunned to see a 2 sec response time. WTF?

I experimented for a while and found that the response time for a Post Reply was consistently working the way it should have and if I changed the SMTP server port back to 25 it was back to 45 sec.

Sounds like it was a server setting issue and all should be fabulous with the fast response time. That about wrapped up that day but…..

The next morning we noted that there were no HelpDesk ticket emails being sent.

After some more investigation it turns out that the Kayako HelpDesk although it asks for the SMTP server it will actually still forward via the local host. The localhost was not using the modified SMTP port and the combination of trying to use the remote server hostname with its correct port was failing to allow any email.

The solution was to simply set the SMTP Server to ‘localhost’ and the default port ’25’.

Email now flows correctly and the timeout issue on the Post Reply page is still good.

I still do not understand why the system managed to work, albeit with a long delay, previously. I think that Kayako / PHP might have been trying to connect to the remote server on the incorrect port first and waiting for a time-out before reverting to the local host. My best guess is that when I changed it to the correct remote port, it was no longer timing out, it was getting a rejection and therefore not trying again. Setting it to use localhost directly works fine with email going immediately and no timeout, but the emails used to get the actual staff / team member responding to the ticket as the sender, whereas we are now getting just the label ‘helpdesk’. But that is for another day.