Frustrated with the performance of the Zend Studio IDE, I started looking around for a replacement IDE in which to code PHP.
A quick Google led me to VS PHP, a plugin for Microsoft Visual Studio produced by Jcx.Software. There is a 30-day trial version, which I’ve been using for about 24 hours now.
I’ll post up my thoughts one of these days….
…is without question the thing I hate the most about web development. The symptoms are inconsistent, the problems are illogical, and the solutions are rarely predictable.
Take the bug I beat my head against this Saturday. I added some custom meta-tags into the product pages on the site for the benefit of the Google Mini. One of the tags embeds the path to the product thumbnail image which is rendered via the XSL transform that is performed upon the XML returned by the Mini.
Earlier this year I wrote some code to do a slick little Javascript trick to display the full-size view of a product image whenever the user mouses over the image. I wrote it to be smart enough to find the best place to display the image so that none of the image fell of the edges of the screen. And I wrote it to be compatible across a bunch of browsers.
I thought.
Turns out that IE was having a problem with the “onload” attribute of the Javascript Image object. The reason escapes me, but IE does not call onload if the image is being loaded from the cache. This presented a small problem because our images are not of a uniform size so I need to load them to determine their dimensions and position them accordingly on the screen.
The solution was to trick IE by appending the microtime to the image source as a query string variable. The code was as follows:
var sSrc=”myimage.jpg” mce_src=”myimage.jpg” ;
var oD = new Date();
var nMs = oD.getMilliseconds();
sSrc += “?” + nMs;
oNewImage.src = sSrc;
oNewImage.onload = PutImageIntoDiv
It works. There is the chance that the user might mouse back over the image at precisely the same millisecond as they did before, but the changes of that aren’t great. Like one in a thousand.
One of the challenges with the Mini has been getting it to return results without being redundant. We are using an ISAPI rewrite to make our URLs search engine friendly.
Rather than:
mysite.com?product_id=365&department_id=2
our URLs look more like
mysite.com/p/365,2_Big-Purple-Widget.html
The rewriter knows that the “365″ the key for the product and that “2″ is a key for a category and the server can then render the page accordingly. The “Big Purple Widget” part is merely a way of introducing keywords into the URL to benefit our positioning in organic search engine results.
The challenge is that the same product can appear under many different categories and can have as many different URLs.
Consider the following URLs:
mysite.com/p/365,11_Big-Purple-Widget.html
mysite.com/p/365,900_Big-Purple-Widget.html
mysite.com/p/365,,_Big-Purple-Widget.html
Each URL displays the same data, with the second numeric sequence (11 or 900) affecting the way that category navigation tree is rendered. The last URL is a direct path to the product.
The Mini sees each of the pages above as different pages and will return each page for any query for big purple widgets. Using the “filter=p” or “filter=1″ option in the URL does not achieve the desired results because those filters respectively screen out duplicate information in the same directory and duplicate snippets. Using the googleoff/googleon comment tags didn’t work either.
The key to solving the issue was to leverage the last URL in the series, the direct path with no category information. I wrote a script to generate a page of links to product pages for the Mini to crawl. Secondly, I instructed the Mini by way of a regular expression to not return results for any pages that had the second set of numerals (the category id).
It works nicely. The only problem is that with over 30,000 unique SKUs and over 6,000 product display groups, the links page is quite large and takes too long to render if pulled from the database. I solved this problem by using a schedule task to create the pages on a nightly basis, splitting them alphabetically to keep their size down (the Mini won’t index an HTML document larger than 2.5 MB).
