Cartweaver.com

 facebook Facebook
 twitter Twitter

Blog Calendar

S M T W T F S
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28
<<  February  >>
2010

Blog search


Cartweaver.com

Cartweaver.com ColdFusion, PHP, and ASP Shopping carts for Adobe™ Dreamweaver.

 

Adobe Community Pro

 

Bookmark and Share

 

A blog for web developers about all things ecommerce.

IE6 The wicked 6 is dead - Goodbye, and good riddance!

Saturday, February 06, 2010 12:00:00 AM

IE6 is dead. One universal thorn in the side of developers the world over in adopting AJAX, jQuery (and other cool JavaScript frameworks) and more complex CSS, not to mention looking ahead to HTML 5 is the abomination called IE6. This Microsoft non-standards-compliant train wreck of a browser has been the unwelcome guest that has just refused to leave the party.Dumbing down our sites and applications to support for this blemish on the web has been the bain of the web developers/designers existance for far too long.

At last! Let's have a good Ol' Irish wake and party it's passing!

Recently Google announced that it will no longer support or worry about compatibility with IE6. This follows on the heels of Microsoft announcing the same.

The cool thing here is, the biggest block of "hangers on" to IE 6 has been large corperate and government IT departments, and them not allowing users on their networks to update.

NOW with two of the largest players in the market saying "IE6 is dead and we are moving on" the playing field has officially shifted in our favor. With major business and employers being pushed forward there's no reason to not tell users to update as well.

If one of our clients says "my site looks funny" and we find they still have IE6 we can, with authority, tell them they need to update their browser and back this up by saying even Google and Microsoft have abandoned all support for IE6 and for this reason we no longer developed with it in mind. The update is free, there are many choices, just do it. All said with a reassuring head nod and smile of course.

Google's formal announcement

OH YEAH!  What a glorious time this is. All together now...

<Munchkin voice> Ding done the 6 is dead, the wicked 6 is dead!!!</Munchkin voice>

Category tags: General Topics

Dang! My session timed out!

Thursday, February 04, 2010 12:00:00 AM

A Heartbeat script may be the end of your session time-out frustrations.

We have all been there. Updating a web form and after working on it for quite a while the phone rings or somebody need our attention. You go back to you web form and finish it, then submit it only to find that your log in session has expired and you lose all your work!!! (insert explicative here).

"I can hear your heartbeat"

There is a way around this with AJAX / jQuery. There are several variations available of what has become to be known as a "Heartbeat" script. The purpose of this script is to Asynchronously ping or poll the server at given intervals to keep your session on the server alive. Here are a few exasmples:

There are numerous others that you can find by doing a quick Google search on "Heartbeat jQuery Script"

Some of the scripts you will find use the jQuery framework, others do not, but all follow the same idea and that is to simply interact occasionally with the server in the background to let the server know you are still there. This can save a lot of frustration for our clients and ourselves - c'mon admit it... Even though you constantly tell your clients to remember to update frequently to save their work you forget from time to time and get caught by this as well!

The cure-all?

Is this little script the cure-all that we have been looking for? Quite possibly, but as with any JavaScript function you'll need to test it with your application to be certain it doesn't conflict with anything else you have going on. It's pretty easy to implement, and worth the time however, so you might want to give it a try.

Category tags: General Topics, True Life Stories

FWIW - My take on the new Apple iPad

Friday, January 29, 2010 12:00:00 AM

iPadiPad, from a developer's perspective

When I watched Steve Jobs introduce the Apple iPad on Wednesday, my first reaction was, this is cool, but it really didn't move me. Like the MacBook Air, it impressed me as innovative and kind of "wiz-bang" but it doesn't have the horse power to replace my laptop nor does it have the communications ability of my smart phone, it just didn't seem to fit.

"Walk a mile in my shoes."

Then it struck me, I am looking at this from a developer's perspective. Face it were are not a mainstream lot. So I stepped out of my own perspective for a bit and tried to wrap my head around this new device from a run-of-the-mill user's stand point. NOW I get it! For the way the vast majority of my more "normal" family and friends use computers, this device is absolutely brilliant!

For example, my daughter went to Japan for three months and took my old MacBook with her. While this is a pretty easy traveling companion, the iPad would do everything she ever uses the MacBook for, and it would do it lighter, faster, better, and cheaper! I realized that Apple once again "Got It" - maybe even before the rest of us even knew what "it" was. I'd be willing to bet that 60% of the consumer market uses their computers for no more than what the iPad does, and the iPad does it in a new and more human friendly way. I feel a "I've got to have one of these" feelings coming over me!

What about our clients?

Then I took a moment and thought about our clients. So many of our clients have smaller "mom-n-pop" ecommerce sites for whom selling on the web is as much a part of their lives as it is a business. With an inexpensive, easy to use, access to the web anywhere, device like this in their hands, administering their web site, checking orders, adding new products and emailing customers just got a whole lot easier and more portable! And affordable! Our clients could literally be on a beach on Maui, or camping in the mountains of Colorado and with the G3 version of the iPad be connected and able to run their store and keep tabs on their business. For small one or two person businesses this spells freedom.

Social media on steroids.

Now that Social Media is becoming such a significant element in how we communicate and promote our business, the iPad's larger interface, compared to smart phones, will open things up and make staying current and connected much more friendly and therefore easier than in the cramped confines of even the best iPhone or Blackberry Storm or Droid. As we all know, when you make something you should be doing easier, you're more likely to actually do it.

A new category of computing & communications.

Like the iPod, and the iPhone, I think Apple has done it again. They managed to see just a little further over the horizon that the rest of us and identified a huge, primed and ready market, and got their first!

There's two things I'm resolved to buy now... an iPad, and more Apple stock. I'm 100% confident that these will both be expenditures that I'll be very pleased with.

Category tags: General Topics

Don't go public with your site before you're ready!

Tuesday, January 19, 2010 12:00:00 AM

Clients like to see what we are up to, right?

As web developers we need share our progress with our clients as we wok on their new sites, but we only want to share our work with them or a select group users.

That being said you'd be amazed how often the ever busy Google bots crawl their way to one of these staging sites and then, as they were designed to do, index it and then share it with the world!

What brought this thought to mind was, I have a Google Alert set up for the term "Cartweaver" as well as several eCommerce related search terms and frequently I'll get an alert that directs me to a site that is obviously the basic, initial install of Cartweaver.
What is no doubt happening here is a developer is putting this up as a test case for themselves or a client so see - I seriously doubt that they intended for Google to find and index their site at this time however.

So, how do you share your progress with your clients, yet protect it from Google and other uninvited "guests"?

The best solution here is to set the folder on the server that contains your site to be protected and to require a username and password to allow access. If you have a dedicated server this is no problem, and some hosts will set this up for you... but not all. So what do you do if you want to test things on your host server, and allow you client to check progress, but keep the site private and block access for everyone else until you are ready to go live?

A simple User Authentication Method with a "Security Index Page"

Here's a simple set up you can use. You can create a placeholder / log in page and name it as your index page. This page will serve to as you temporary home page. This page will force users to log in to view the rest of the site. During development of your site, just name your home page "home.cfm" (or PHP or ASP) - When you are ready to go live you can eliminate the "security" index page and rename your "home" page to "index". If you do this in Dreamweaver's file view Dreamweaver will even update the links to the home file to index for you so you won't have to worry about doing this manually.

Now what you do is add a log in form to the security index page that will allow users to log in. If the log in is correct they will be automatically taken to the home page and be allowed to browse the site, if not the will be bounced back to the security index page.

What if they are not logged in and manually enter a url for one of the interior pages? Won't they be abe to see the site then?

We can prevent this with a simple validation / relocation script.

We will set a default log in session variable and if a log in is correct this default will be replaced by expected "logged in" value. To prevent access to any pages other than the security index page for anyone not properly logged in we will place code that checks the logged in variable value. If the user is correctly logged in we do nothing and allow access to the requested page, if the value is incorrect we will automatically redirect the user back to the security index page. For ColdFusion we would include this code in the Application.cfm or Application.cfc file, depending on which you are using. For PHP or ASP you will need to include this code at the very top of each page on your site.

Doing this will effectively hide your site-in-progress from prying eyes or Google bots, until you are ready for them to see it, but makes your work in progress easy to see for your clients.

Download the example files here:

Once the site is ready to go live, we delete the index page and rename the home page to index, as mentioned above. Then we delete the included checking code from the site. For Coldfusion, you select the include from you Application file, for PHP you can do a quick search and replace to eliminate the include code.

A note to remember:
It is better if you can secure the site on the server at the folder permissions level, but if this option is not reasonably available to you, this method will do the trick!

Hope you find this helpful!

Category tags: ASP, ColdFusion, General Topics, PHP, True Life Stories

Continuing participation in Adobe Community Professionals

Monday, January 18, 2010 12:00:00 AM

I'm very pleased to have been selected to continue my participation in the Adobe Community Professionals program!

This program affords me the opportunity to give back to a community that has been such a large part of my career! It also gives me a chance to stay on the inside track of where Adobe and the web development industry as a whole is headed.

A BIG thank you to Adobe for asking me back - it's an honor and a privilege to be part of such a dynamic community! Find the list of ACPs here - http://tinyurl.com/yh47gp8

Category tags: General Topics

Mystery of the missing order...

Tuesday, December 22, 2009 12:00:00 AM

I received a tech support email the other day that raised a topic I thought would be worth covering here. The email, stated that there was a transaction that was showing on the users payment gateway, but not in the store database... How could this happen?

First let's look at what happens in a normal purchase transaction.

When the customer clicks the final checkout button the credit card and customer data is passed off via SSL encryption to the payment gateway (note, we are only discussing real-time gateways here like Authorize Net, Link Point or the like) The gateway verifies the information and validates the transaction, or not, depending on the response from the card issuing bank, then reports the results, either success or failed, back to the cart application. The cart then processes the transaction based upon the gateway response.

  • Success - the order is added to the database and a confirmation page is displayed.
  • Failed - a "Transaction failed" page is displayed and the customer is given the option to try again.

Simple enough, but what would cause a successful transaction to be recorded at the gateway, but not in the store database?

What can cause this is something interrupting the response from the gateway, a glitch in the connection or a dropped packet transfer.

What can you do?

Unfortunately there is nothing in the code or the app that can prevent a connection glitch on the web. As long as you are reaching out to a remote service, and then requiring a response back from that remote service, there's always a chance that something will prevent the return response from getting through. Fortunately this is a very rare occurrence, but it does happen... Things are better now than they were a few or a couple of years ago, by a long shot! But still not perfect, and this can happen.

Now what if it's happening frequently? Well the first thing to keep in mind - it is not the code or the application. The app works the same way for every transaction. It sends the data off, receives the return data, and acts accordingly based on the response. So the missing order issue is happening to you frequently then you need to see what the possible cause that may be within your control could be. First thing to look at is your host's system. If you are on a host with overloaded servers or with internal connection issues, this could definitely cause this problem. You see, when browsing from page to page on a web site, if the hosts system is a little glitchy or over stressed, drops in page requests can go pretty much unnoticed, but if this "drop" occurs mid transaction, then you have problems! There's no way to reinitiate the entire transaction - the app has already transferred the data to the gateway, all it can do now is wait for the response. There are a number of things that can cause this - many of them are beyond your control since they happen out on the web - but you do have control, or influence at least on what happens on your server - either by working with your host or seeking out a more reliable host.

The main thing to remember here is this problem is a connection / communication issue, not an application code issue. This can happen every once in a while, simply because the web is not a perfect network. But if it's happening with any frequency, you need to see what you can do to assure more reliable connections between your site and your gateway.

I hope this conversation will help clear the fog around this issue for you and help you make your system as reliable as present web technology will allow.

Category tags: Cartweaver, eCommerce, True Life Stories

True Life Story - Lazy SKUs

Sunday, December 13, 2009 12:00:00 AM

Sometimes as web developers we run into situations where we must do our level best to save the client from themselves. This happens often enough where I thought it would be a good idea to share some of out tech support experiences. I believe what we share will be helpful to many developers in their day to day dealings with clients.
 
Case in point.   A feature of Cartweaver and many shopping cart applications is to track product the same way a physical store would, by Products and SKUs. Products being the manufacturers item such as a "Nike Polo Shirt" the the SKUs are id numbers assigned to all the individual variations of that item such as "Blue, XL" or Red, Small" and so forth. It is the SKU that caries the price and is counted for inventory.
 
Ok, pretty basic stuff for a merchant that runs a bricks and mortar store. But you would be amazed at how many merchants setting up an online store think that they can just skip this and do it an easier way. Admittedly entering all those individual SKUs can be daunting if you have a hundred products with ten to fifteen SKUs each! But doing it right is vital. Physical store merchants understand this, but those new to online sales can be pretty insistent on wanting to go for the short cut.
 
Here's a transcript of a support thread on the topic...
 
=========================
Q-post:
I am trying to avoid using multiple skus for one product with multiple options.
 
A-Post
Hi, sounds like you are wanting to bypass the functionality of skus and replace it with that exact same functionality... why not use the skus and options as they are?
 
Q-post
Yeah that's what I am doing. My client is trying to keep it simple with one sku and multiple options w/ pricing (simple for them)
Thanks.
 
A-post
A point to talk over with your client is that they should look at inventory and sales online exactly like they would in a bricks and mortar store,  When they reorder from their suppliers they order by the SKU.  They don't call a supplier and just say I want a mix of various shirts and just charge me the same for all of them and don't worry about having an actual count of each or have any way of looking back and see which ones sold and which ones didn't.  You know it just sounds silly when it's put that way, but many new to ecommerce will dive into this sort of mistake because they think they are making things easier, that is until a year from now they want to do some sort of record checking... Then it's that stupid web developer screwed this all up... Why didn't we get a developer that knew what he was doing!
 
This is one of those areas the we must help save the client from themselves.  It's well worth it in the long run.
 
======================  End post
 
I feel this developer's pain. We all know that clients can get a thought into their head and once they are convinced it's a good idea that are many times really ready to go toe to toe over it.
It's a tough one, bus as I stated in my response, giving in may be just delaying the battle. Doing all you can, up front to do it right will ultimately pay off. The important thing is to think these situations out in advance, so when the client tries to run down one of these rat holes, you have sound reasonable explanations ready to save them from themselves.
 
Hope this helps!

Category tags: eCommerce, General Topics, True Life Stories

Check out my article on Practical Ecommerce

Tuesday, November 24, 2009 12:00:00 AM

I just finished an article for PracticalEcommerce.com about taking the initial steps toward having a social media strategy to promote your ecommerce site.

One of the points I make is to respect the community etiquette and don’t jump in and start selling. Doing this will make you about as welcome as an Amway salesman at a family reunion! Social media is a powerful direct -to-consumer communications tool but their are boundaries you should respect.

Take a look at the article and listen to the interview and let me know what you think.

 

Category tags: Cartweaver, eCommerce, General Topics

Before posting comments or trackbacks, please read the posting policy.

Full Blog Calendar