13 10, 2011

The Redesign Bug

By | 2016-11-22T18:07:35+00:00 October 13th, 2011|Categories: Web Development, Creative Design|Tags: , , , , , , , |

We recently launched the Beacon site with a new design which included a handful of jQuery animation, many of which had replaced the the previous design’s Flash-intensive content. We have recently come across an issue with the jQuery library with some builds of IE7 and IE8 that resulted in an extensive trail of debugging. We concluded that it was a browser issue (even in different OS environments) that was only fixed by re-installing IE. Here I will outline the issue and the debug trail–and hopefully maybe even think up some potential fixes that weren’t explored when testing was originally performed.

The Issue

In IE7 and IE8 we found that refreshing the homepage would crash IE and sometimes handle restoring the tab, other times not.  Microsoft has acknowledged this error in an KB article.

Error Screenshots

Initial view of most common error displayed.

Error message that would periodically show right before the tab recovers.

Details of error.

Advanced error detail screen.

When tab is not recovered, this screen is shown. Had to repeatedly refresh until this error occurs.

Just-In-Time Debugger error found from a different machine.

The Debug Trail

  • Initial replication of issue in IE 8.0.6012 on one of the test machines using a Windows XP environment.
  • Attempted browser-configuration changes that might’ve caused issues including:
    • Privacy Settings
    • Security Settings
    • PrivateBrowsing
    • Add-Ons disabled
    • Just-In-Time Debugging (picked up from a slightly different error that was sent to me as a screenshot from Mark Dirks — last one on right shown above) Unfortunately not of these seemed to be the culprit.
  • Disabled JavaScript in IE altogether–which of course fixes it but not what we we’re aiming for. This confirms it is a JavaScript/jQuery related issue
  • Attempted using different versions from currently used (1.6.1) to most recently published version from jQuery site (1.6.4) – tried both compressed/uncompressed versions without any success.
  • Checked a  changelog of jQuery since version 1.6.1 onward for IE7/8 errors. *Anything related to these browsers I had checked out scripts for any instances of (CSS background-image in jQuery and other function calls)
  • One Google search led me to a site that reported changing the jQuery file name had corrected their similar mshtml.dll error—-not the case here)
  • Double checked the in-line JavaScript as well as .JS file functions dependent on the jQuery library contained no redirects or any instance of the window.location method Since the IE8 error that comes up sometimes on the test machine says the browser attempted to load more than twice) – the only instance of this I found is a comparison checking if ‘#beacon-video’ is in the URL and if so, it runs a function to scroll the Beacon video into view and sets the tabs display(css) values. The window.location value is never assigned anywhere.
  • Checked that there weren’t multiple instances of window.onload or jQuery(document).ready()
  • Ran the jQuery library file through a beautifier to get a better look at the pin-pointed trouble spot you found and checked for any obvious issues. Justin Klingman found that in the compressed library he could comment out the last half of the code which removed the crash so before ‘beautifying’ the code I had marked this position with a comment and looked in the region after the code was cleaned up.
  • Removed all other scripts from the page to see if those dependencies may have had an impact on the crash, but removing them all (including the JavaScript function calls in the body,) except for the jQuery Library. No difference, same crashing effect.
  • The only change that did successfully fixed the crashing tab to load was removing jQuery from the page, however, when the content of another root level page (the SEM pages) into the root default document, that loads/refreshes fine without crashing. The only difference between interior/homepage in terms of JavaScript is the presence of the homeScripts.js file and the inline function calls on the homepage. After further testing this, removing only homeScripts.js still crashed the tab on the homepage (unless jQuery was also removed) — All internal pages use the same copy of the jQuery Library and they don’t crash, so the exact source of what’s crashing the page/tab is still not clear to me.
17 05, 2011

Zen Cart Cache Overflowing? Here’s a fix…

By | 2016-11-22T18:07:03+00:00 May 17th, 2011|Categories: Web Development|Tags: , , |

A popular CMS system for e-commerce sites, Zen Cart offers advantages in an easy-to-use admin interface (especially for novices) and extensive customization capabilities for developers, either through the out-of-the-box modules or through custom added code added directly to the server.

However, one issue I have found with extensive customization is that some changes may have the unintended consequence of causing the cache folder – typically located on the server at /site/cache/ – to slowly (but without warning) build to an extremely large size that could crash the website.  This occurs because certain changes may trigger a debugging file to kick in and write error reports to the cache folder every minute.  This could lead to over a gig of information, or twice that if you are also running a test site, being generated by the site in a matter of weeks.

These files are generated by a debugging file that should be located at /site/includes/extra_configures/enable_error_logging.php.

Most of the recommendations I encountered for dealing with this issue involved just removing the enable_error_logging file altogether.  However, while this did stop writing files to the cache folder and preventing the folder from overflowing, it actually led to a queer circumstance where the errors were still written…only directly to the site itself, leading to some very strange display situations on select browsers.

As such, I recommend not deleting this file.  The best fix I was able to manage was to leave the file in existence, but alter its functionality.  This was accomplished by the following steps:

1) Open /site/includes/extra_configures/enable_error_logging.php.  Save a copy locally or with a different file extension within the same folder.  You will still want the code contained to be in existence should you ever want to debug select customizations or module installations using this file.

2) Look at the section that includes the snippets stated $pages_to_debug[] .  Delete all but one of these items (leaving one snippet that states $pages_to_debug[] = ‘ ‘;).  This should be in the vicinity of lines 18-20.

3)From here, delete all lines between the aforementioned line of code and the comment that states ///// DO NOT EDIT BELOW THIS LINE /////.  This should be located between lines 35 & 40.

That’s it!  Enough of the file is still in existence to prevent any errors from crashing your site, but the writing functionality to the cache folder has been removed, preventing any worries of unwanted gigs of data being accumulated.  Should you need to debug the site at a future date, simply go to the copied folder and replace the removed lines.  When you are done, delete the lines again as indicated.

– EW

Follow me on twitter: @ejwestksu