AbleCommerce IE10 and Windows 8 problems

by Joe Payne 27. November 2012 11:35

IMPORTANT UPDATE from AbleCommerce

Microsoft has confirmed that there are known issues when using the latest IE10 browser and certain code that might be in Asp.Net 2.0 or Asp.Net 4.0 sites. All AbleCommerce 7.0.x stores are affected by these issues, so you should carefully read the available options and take corrective action.

!. Javascript disabled in IE10 due to outdated browser definitions file

2. ImageButtons do not work in IE10 when using .net 4.0 and older

Microsoft has made an official patch available for one of the issues. It is unknown, at this time, if Microsoft plans to release another patch for the second issue. As such, AbleCommerce is providing a work-around that can be applied to your AbleCommerce store.

You should fix both issues by following the instructions found on the AbleCommerce help site.

http://help.ablecommerce.com/index.htm#upgrades/ac7_aspnet/tech_bulletins/asp.net_2.0_and_4.0_with_ie_10.htm

Tags: , , ,

General News | Tech Support | AC7 Articles

ABCPdf Unable to load DLL 'ABCpdf8-64.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

by Joe Payne 31. Augustus 2012 16:28

I use the ABCPdf .Net module quite a bit in projects.  It’s perfect for generating and manipulating PDF files in server-side ASP.Net code.  But more than once, I’ve encountered this error and can’t remember the solution. 

Finally I remembered the cause of the error.  You have to enable 32-bit applications in the IIS application pool here.

Go into IIS Manager and choose Application Pools. Find the app pool assigned to the site running ABCPdf.   Select the App Pool on the left, then click 'Advanced Settings’ on the right side. Now change the Enable 32-bit Applications setting to True and apply.

image

When you’re done, stop and restart your app pool.  Now try your page again.  Hopefully that’ll fix it for you like it did me.

ABCPdf is available at www.websupergoo.com if you have need to stellar PDF manipulation in .Net.

Tags: , ,

Tech Support | Personal

Slick little GeoIP feature for the AbleCommerce Order Manager

by Joe Payne 28. Augustus 2012 21:20

Came up with an awesome mod for the Order Manager screen tonight.  It highlights orders that are placed from non-US IP addresses.  This makes it incredibly easy to identify potential fraud orders in your storefront.

This mod works with a local GeoIP database too, so there’s no lookup limits or bandwidth spikes to worry about.

Geographic IP lookups are a dime a dozen on the internet.  But the vast majority of these lookup sites will throttle the number of requests.  This creates a slow and often frustrating limit on the usefulness in a production environment.

By leveraging a local database, it becomes far more efficient (and less costly) to implement GeoIP lookups in your AbleCommerce website.

Tags: , ,

General News | AC7 Articles

Changing kit product to regular product breaks checkout

by Joe Payne 20. Julie 2012 21:41

Found an obscure bug this week in AC7.  If you have an existing product configured as a kit, changing it to a regular product (removing all kit components) could break your checkout.  Here’s why:

When Able writes a kit product to the basket, it also writes a value to the KitList field on the basket line item record.  This value tells Able to expect the basket line item to be a Kit product.  Same thing when an item is written to a wishlist.

However, when removing components from a kit product in the catalog, Able doesn’t update any existing basket items for the same ProductId.  So any abandoned baskets still have the a value in the KitList field.

If a shopper adds the product (when it was a kit) to their basket and then returns to purchase it AFTER the ProductId is changed to a regular product, Checkout doesn’t know how to handle this.  the KitList field still has a value, but the original product no longer has any components.  Checkout blows up.

A second way to make this happen is the Reorder button.  Often a shopper will log into their My Account page, view their previous order and click the Reorder button.  However, Able code doesn’t validate the previous order products against the current catalog.  It just assumes if the ProductId still exists, it must be configured the same as it was on the previous order.

So the shopper again winds up with a basket item having a KitList value for a product that no longer has components.  Checkout crashes and shoppers cannot complete the purchase.

The solution for the client was two-fold.  First, we had to clear all records from the ac_BasketItems table.  Second, we had to modify the Reorder button to simply redirect to the store catalog instead of repopulating the basket with items.

Tags: , ,

AC7 Articles | Personal

ASP.Net postback problem with ViewState in Safari on Windows 7

by Joe Payne 20. Julie 2012 21:27

Wow what a challenging issue to troubleshoot this week.  Here was the scenario:

AbleCommerce 7 client was reporting certain shoppers could not complete checkout.  The catch was, it was only happening on Safari and IE8 users.  But mostly Safari.  You’d get an error after entering the credit card information and couldn’t proceed to the receipt page.

The shoppers using Safari could reach checkout.  They could hit the 2nd page of checkout.  But after clicking the Pay with Credit Card button, nothing happened.  Scrolling to the top of the page reveals a new message on the page stating the basket contents had changed.  Repeated clicks resulted in the same.

We had done some recent enhancements to the checkout page.  But they were purely visual.  There weren’t any changes to the functionality of the page, just added images to the basketgrid and some improved CSS.  We certainly weren’t manipulating basket contents during checkout (Big NO NO), so we were baffled as to the cause.

We walked back through the version-control repository looking for every change in the last 6 months.  Nothing affecting the basket was found.

We crawled through the rendered page source looking for anything out of the ordinary.  Nothing stood out.  We couldn’t even reproduce the issue on our local developer copies of the site.

Finally, after reloading Safari on my Windows 7 64-bit PC, I got the issue to happen.  Bingo!  Now I can light up the issue through the debugger and see what the heck is going on.

In the checkout code, the message only renders if the basket contents in the previous postback are different from the current postback basket contents.  Able accomplishes this by generating a hash value of the basket and storing it in the page ViewState.

While walking through the code, I noticed the ShipmethodId on the the basket shipments was getting reset to 0.  Having a ShipMethodId of 0 means no shipping method assigned.  But in the initial page_load(), able sets a default shipping method to each shipment.  So how was this possible?

After walking a bunch of code with the visual studio debugger, I finally notice something totally bizarre.  After clicking the Continue button on Page 1 of checkout, Page.IsPostback() was reporting FALSE.  Do what??  How can it be false??  It’s the same page???

A breakpoint on the Page_Load() routine gave me the answer.  I could actually see Page_Load() getting hit twice in the same single postback.  The first time, Page.IsPostBack() reported True as it should.  But the second hit in Page_Load() reported False, like it was a brand new hit to the whole page!

So Safari was firing it’s own postback after the initial postback from the Continue button.  And this postback did not include ViewState.  Without ViewState, Page.IsPostback() reports false and thinks it’s a first-time load of the page.  A first time load of the page causes Able to reset the ShipMethodId on the basket shipments.  Thus the error on Page 2 of checkout about the basket changing…..

About the same time, I just happened to notice something odd about Page 2 of checkout.  The basket summary didn’t have any images.  I had paused the code in Page_Load() during the rogue postback.  Everything else on the page was rendered, but the images were missing.  We had indeed modified that basket summary to render images.  But it was simple change – just an evaluation expression calling a code-behind return that returns an image URL for the Container.DataItem.  no biggie right?

I commented out the <asp:Image> object in the basket summary, and suddenly the rogue postback stopped firing.  The checkout page started working exactly as it should.

Now I know the cause.  But I don’t know the reason.  So I did a little digging and learned something.

ASP.Net stores the viewstate in a HTML Hidden Field tag embedded in the HTML response.  Apparently, in certain circumstances, Safari has a size limit to hidden fields.  My guess is, somehow adding the images to the page caused the viewstate to grow beyond this hidden field size limit imposed by Safari.

I wish I knew more about it.  But what a crazy amount of time it took to troubleshoot this issue.  At least we got it figured out and the client website is back to working normal again.

Tags: , , , ,

AC7 Articles | Personal

Month List