brettbrewer.com

If you're a web developer that had the misfortune to replace your old IE developer toolbar with a newer version, you may have seen some brand new javascript errors appearing in your sites only in IE. You may see a Just-In-Time Debugging window that looks like this . If you debug the javascript error in MS Script Editor it will break at a remote procedure call:

[540] C:\Program Files\Internet Explorer\iexplore.exe

...and if you continue debugging from there you'll get the following error message from Visual Studio:

Microsoft JScript runtime error: Object doesn't support this property or method.

Tracing the code reveals this incredibly sloppy function:

function ParseDoc(doc)
{
     var aRules = GatherRulesFromDoc(doc);
     collSelectors = parser.Parse(aRules);

     // Set quirks mode if necessary
     if("BackCompat" == doc.compatMode)
      {
          for(var i = 0; i < collSelectors.Count; i++)
           {
                 collSelectors.item(i).SetQuirksMode(true);            
            }
     }
}

The red line above is what causes the error in IE6&7. Seasoned javascript developers will notice the complete lack of error handling here. I'd expect this from something I'd written myself, but not from an offical Microsoft product targeted towards developers who are likely to have strong opinions on poorly written code. It blows my mind that this problem has been around for many months, has an easy fix and MSft just hasn't bothered to release a fix. A single try/catch statement wrapped around the offending code is all that is required...literally 1 line if elementary javascript. Of course, since MSFT products are not open-source, the people who know the solution are not allowed to release a patched binary of the toolbar, so to fix this problem, you'll need to get a resource editor and follow the instructions from this nice hacker at NanoAnt. Of course, disabling the toolbar entirely and doing all your development in Firefox is another popular option. 

I've spent countless hours, weeks actually, trying to set up some older versions of php/mysql on Linux for testing purposes. Sadly, there's still a real need for PHP4/MySQL4 development for legacy applications and NO good ways to manage multiple versions on one machine. In particular, many people running the Xcart 4.0 branch are running on PHP4 and MySQL 4.1. Trying to run these sites on MySQL5 or PHP5 is impossible without serious modifications to the source code. So I decided to set up a test server in or two in VMWare and get the versions I needed installed. I wanted to be able to switch versions of php and mysql at will. This proved to be impossible with every flavor of Fedora that I tried and hours of searching revealed no better solutions for other Linux distros. Rather than detail my incredible waste of time trying to install everything from source, I will tell you my final solution, which is to use XAMPP for Linux to install your preferred combination of php/mysql for testing. It's not a perfect solution, but the XAMPP package will let you run various flavors of PHP/MySQL and lets you switch between php4 and php5 at will when you start your servers. You are stuck with the versions of php4/php5/mysql included in whichever XAMPP distro you choose, but if you browse the XAMPP archives, you can find a version with most combinations of php/mysql that you will need to test on. If you click the "release notes" icons next to each distro at SourceForge you can see what versions of PHP/MySQL are included. In particular, XAMPP version 1.4.16 includes PHP 4.4.0, PHP 5.0.x and MySQL 4.1.14. So it's a great combination for people working on transitional PHP/MySQL apps. After MySQL 4.1.x the SQL interpreter was changed to comply with strict SQL standards and it broke some JOINs in x-cart and many other PHP apps. If you have a client that can't or won't upgrade their apps to be compatible with the newer versions of PHP/MySQL, you almost have no choice but to run your own test server with older versions of PHP/MySQL and XAMPP has made this a super-simple task. The only problem I've found is that the instructions are non-existent. I did find this how-to , but that's about it. They don't tell you that all you need to do is untar the XAMPP distro and drop the"lampp" folder into your Linux "/opt/" directory. That's the big trick, it needs to be in the /opt/ directory. Then cd into the /opt/lampp directory and type "./lampp start". That's it! Everything resides in subfolders in the /opt/lampp/ directory, so you can tweak your configuration. If you have problems not being able to start XAMPP properly due to existing services not being uninstalled, you'll need to stop your existing services first and then preferably uninstall all your existing copies of php, mysql, httpd etc. If you installed your previous copies from source, you can simply go to their source directories and type "make uninistall", otherwise you can use yum or rpm, which is a whole other story. You may also need to search for existing processes from your old mysql or httpd servers and kill them. I had to manually kill my previous mysql process by searching for "mysql.pid", then opening the "mysql.pid" file to find out the actual pid I needed to kill. Once you know the pid simply type "kill xxxx" where xxxx is the pid. Also, you may get an error with phpMyAdmin and other apps complaining they can't connect to "localhost.localdomain". To fix, this, simply add the following line before any other lines to /etc/hosts:

127.0.0.1     localhost

That was the only major problem I had to fix to get it XAMPP working on my test machine running Fedora Core 4. I just can't believe I wasted over a week messing with source files before I stumbled onto this. I know there's got to be a better way than using XAMPP because I saw someone do a demo at a PHP conference where they ran a test script through 8 different versions of PHP from the commandline. It seems like there should be a nice GUI for Linux that will just let you install a bunch of versions of PHP and MySQL and arbitrarily switch between them. If anyone out there knows of such a thing please use my contact form to let me know. 

Recently I ran into a very frustrating character encoding problem when trying to add a Wordpress feed display to X-Cart. I was using PHP's SimpleXML object to parse and display the feed in the home.tpl file in x-cart. The database and feed were in UTF-8 format and all the apostrophes and some other character codes were being converted into garbage when they were displayed in X-Cart's templates, but nowhere else. They looked fine in my feed readers and in the Wordpress templates. I initially blamed PHP's SimpleXML object, then LibXML, then decided it was Apache's fault or that the web host had misconfigured the server to force the character encoding to ISO-8859-1. After much troubleshooting and ranting, I finally realized that X-Cart's language settings were overriding the character encoding meta tag defined in the page template and forcing the browser to use ISO-8859-1 encoding. Apparently x-cart injects a character-encoding header into the output before it renders the Smarty templates, so even if you define the character set in your home.tpl file, or meta.tpl file, x-cart will still inject the character encoding defined for your default language into the HTTP headers via PHP's header() function. This isn't necessarily a bad thing, but it was extremely infuriating to track down and I think most template designers probably expect to be able to insert the character encoding into their templates manually and have it work. So to get my UTF-8 blog feed to display properly in X-Cart required going into the "Language" menu of the X-Cart admin area and changing the encoding setting for English to UTF-8. After years of using and modding X-Cart I've never needed to change this setting until today, but it's an important one to know about if you value your sanity.

People are always asking me what the best free antivirus solution is for Windows. I'm happy to say there's a variety of solutions out there, including free web-based scanners from various commercial software companies, but web based scanners don't really solve the problem of permanent full-time protection for your email and files. Fortunately, there's two products for Windows that work great alone or together.

The first is Avast Home Edition . It's a commercial antivirus solution that is free for home users. You can download the installer from www.avast.com and use it for a while without registering. If you like it and want to use it for more than 60 days (and you probably will), you simply fill out the registration form and they will give you a free serial number good for 1 year. You have to download a new serial number every year, but there is no cost. If you don't want to give them your real email address to receive the serial number, simply use a temporary address at mailinator.com . I've used Avast for at least 4 years now and it does a pretty good job of catching most viruses. If you do a lot of downloading of files from suspect sources then you might want a second layer of protection, but it should suit most PC users. If you do want a second layer of protection, you can install my second favorite free antivirus solution for Windows, called ClamWin.

ClamWin is the windows-friendly release of the open-source (GPL) ClamAV project for UNIX. I cannot really comment on the quality of the ClamAV engine in its thoroughness, but ClamWin is definitely resource-friendly and doesn't slow my computer down in the slightest. If it's like most other open-source software I've come to rely on, it is probably as good or better than any commercial releases. It integrates with MS Outlook to scan attachments and email and downloads virus database updates automatically just like all the nice commercial stuff. In terms of having a small unobtrusive footprint it blows away any commercial offering I've ever used. It does seem to pop up virus update promts frequently while I'm trying to watch videos, but other than that I have no complaints. It even gets along great with other antivirus programs, so if you've already got another antivirus program installed and just want some added protection,  it probably won't hurt to install it. With both Avast Home Edition and ClamWin installed, your email, files and operating system should all be well protected.

If you already have an infection from a virus, worm or trojan, you may need to bring out some bigger guns. Specialty software such as Safer-Networking.org's SpyBot Search & Destroy , LavaSoft AdAware (free version) and TrendMicro's free HijackThis are valueable tools to have in your arsenal. You can run SpyBot Search & Destroy and AdAware to take care of most annoying browser hijack tricks, and if all else fails, run HijackThis and give the report to an expert on one of the free forums such as spywareinfoforum.com where they offer free help to people with really bad computer virus infections.  You'll want to read the forum rules before posting any requests there though, but once you know how to submit your questions to them with the necessarry info from your HijackThis reports, you can solve all but the most insidious computer virus problems. 

If you've ever seen the following warning when starting Apache, you no doubt had trouble figuring out the proper fix:

 _default_ VirtualHost overlap on port 443, the first has precedence

If you're anything like me, you probably diligently followed the Apache documentation and ended up creating multiple IP addresses simply to serve multiple web sites via SSL. Well, contrary to popular opinion and the official Apache docs (which are confusing or misleading on this topic), you CAN in fact use name-based hosting with SSL. You probably already have your main httpd.conf file set up properly, but need to tweak your SSL configuration. The problem is this: you are trying to use name based virtual hosting, but failed to specify name based vhosts for your SSL config. Basically, you need to add the following line somewhere immediately BEFORE the first vhost entry in you SSL config:

NameVirtualHost *:443

On Fedora Core 6 running Apache 2 you will find your config files in the following locations:

/etc/httpd/conf/httpd.conf

/etc/httpd/conf.d/ssl.conf

Basically, Apache2 on Fedora Core 6 puts all your non-standard config options in the "conf.d" subfolder so they are easier to organize...which I happen to love compared to the old way of cramming everything into the httpd.conf file. Anyway, if you are using named based hosting, you should have the following line somewhere in your httpd.conf file before the applicable vhost entries:

NameVirtualHost *:80

This will work if you are just using wildcards for the IP addresses for all your vhosts, otherwise make sure you have the specific ip address specified. Basically the "NameVirtualHost" address must exactly match the address specified in the individual vhost entries and it must come before them.

The trick to getting SSL working with multiple vhosts it to open your /etc/httpd/conf.d/ssl.conf file and find the opening tag of the default vhost entry. Before it just add the same NameVirtualHost you have in your main httpd.conf file, but change the port to your SSL port, which is usually 443:

 NameVirtualHost *:443

Be sure to put this directive BEFORE the first <virtualHost> container tag in your ssl.conf file or you will get errors. Also, if your ssl host entry looks like this:

<VirtualHost __default__:443>

you might want to change it to this

<VirtualHost *:443>

but only if the __default__:443 doesn't work. I don't know if it matters, but I've got mine set up with * instead of __default__. 

 Once you've added the NameVirtualHost directive you should be able to add <virtualHost> entries on port 443 to your ssl.conf file that correspond to the entries in your httpd.conf file and then your sites will work over both http and https and Apache will stop complaining about the hosts overlapping. Well, maybe not completely...I was scanning my apache logs and noticed some continued complaining by Apache, but the erros don't show up when starting Apache and the sites all seem to work, so YAY! I don't know why this isn't listed somewhere in the Apache docs because it seems like everyone setting up their own testing/development server eventually runs into this problem. Perhaps it's not the best way to do it for a live site, but it seems to work fine in my local test environment. I hope this info saves you the hours it took me to figure out. 

If you just want to know how to load the DBG module with IONCUBE loader, skip to the bottom of this post. 

I hate encoded PHP files. I mean I REEEEEEAAAAALY hate them. Not only does it make it infinitely harder to modify an application that relies on obfuscated PHP files, but it also tends to make it impossible to debug the non-encoded parts of your site, so you end up having to do ridiculous things like diabling all your encoded scripts so you can run a debugger on your own files. What a tragedy for PHP programmers everywhere who have to deal with this BS! Every time I do a project that requires me to work around encoded PHP files, it literally adds hours upon hours to the development time...so much so that I could often have rewritten the encoded funtionality myself from scratch faster than I can code around it (I will actually probably start releasing my own free drop-in replacements for some very popular x-cart mods soon if I can't get the authors to release the source).  My advice as a PHP developer is, steer clear of encoded files whenever possible. If you must use them, put pressure on the developers to release unencoded versions, possibly for an additional fee, or ask them to at least document all the internal functions so you know what the heck is happening inside scripts that your own scripts will need to coexist and sometimes interact with.