The rumors are true, Cartweaver 4 is on its way! We are very pleased that we can now begin to share the details of what we have been up to, and what Cartweaver 4 is all about!

First, we have listened to your requests for features in the next version of Cartweaver, and we are excited to share what we have done in response to your feedback. We are also very pleased to say that Cartweaver 4 takes advantage of modern web standards and capabilities, with full support of CSS layout and formatting, and dynamic UI features made possible by the jQuery framework. Cartweaver 4 is not just an update to Cartweaver 3 – It is a complete rewrite from the database up!

Cartweaver 4 will be available in PHP and ColdFusion. The ColdFusion version also supports Railo, the open source CFML server.

For Adobe Dreamweaver users, we have completely rewritten the Dreamweaver extension. The installation of Cartweaver 4 into your Dreamweaver site is now easier than ANY other shopping cart solution... period!

For code developers using text based editors or standalone IDEs, Cartweaver 4 is amazingly easy to add to your site manually, in a matter of minutes. Cartweaver 4 is not tied to Dreamweaver or the Dreamweaver Extension. You can work directly with the Cartweaver code, which has been completely reworked and simplified into a reusable library of functions and components.

We are looking forward to sharing much more information with you in coming days, and are confident that you’ll love what we have done with Cartweaver 4.  Not only is version 4 the best Cartweaver there has ever been, but we are sure it will raise the bar for ALL shopping cart applications. You will find you can have it both ways - easy and powerful tools for both designers and developers can and do exist in the same package!

The new Cartweaver.com website and a presales event will be available very soon. If you would like to take a look at some of the new features, you will find live demos of a basic store installation, the free Cartweaver 4 template, and the online administration area at http://www.YourCartweaverStore.com

For more demonstrations and a look at some of the new features in Cartweaver 4, visit our

YouTube channel: http://www.YouTube.com/CartweaverTV
(We already have a lot of videos there now, with more on the way!)

If you have any questions, please join the discussion on the

Cartweaver user forums: http://forums.cartweaver.com or on our

Facebook page http://www.Facebook.com/Cartweaver

or on Twitter: http://www.Twitter.com/Cartweaver

We look forward to sharing more with you very soon!

Thank you,
Cartweaver Development Team

So, we tightened up security even more and "Sand boxed" the web sites, restored a clean backup and updated CF9 server to the latest release 9.0.1 and all seemed good. Until an order came in... We received an order verification from our Gateway - Authorize Net - but order transaction didn't show in the database! The customer's record was there, but not the order. Fortunately the customer contacted me right away and was very helpful in explaining what happened. Once he had clicked the buy button, what is supposed to happen is the transaction is sent to Authorize Net, then Auth Net returns the transaction results so the purchase can be recorded and confirmation given. What happened is the transaction was sent off to Auth Net and then the customer saw a white screen... No error, no broken page, nothing, just a white screen. After doing a test transaction and getting the same results I worked with the host support to see if the problem could be identified.

Since we had restored all the original code we were sure there wasn't any hacker "foot prints" laying around, so what could it be? We back traced our updates and it turned out the culprit was the CF 9.0.1 update. Although no error was displayed on the screen and my auto error email was never sent to me as it should have been the host did see an error in the CF logs, as follows...

"Error","jrpp-3","12/31/10","08:44:26","CartweaverDotComThreeOh","coldfusion.runtime.CfJspPage._mergeToLocal(Ljava/util/Map;Ljava/util/Map;)V The specific sequence of files included or processed is: C:\ActualFileStructureChanged\page.cfm, line: 312 "
"Error","jrpp-0","12/31/10","08:53:33","CartweaverDotComThreeOh","coldfusion.runtime.CfJspPage._mergeToLocal(Ljava/util/Map;Ljava/util/Map;)V The specific sequence of files included or processed is: C:\C:\ActualFileStructureChanged\page.cfm.cfm, line: 312 "

In doing a Google search on this "White Screen" problem we found a mention of it in Ray Camden's blog post on the release of CF 9.0.1 where someone commenting on the blog post mentioned the same problem and had to roll back to 9.0.

Well I'm pleased to say, with the help of my buddy Dan Short - CFr extraordinaire - we found what the problem was. For whatever reason CF 9.0.1 was having a conflict with us explicitly declaring a local variable. The error showed, for lack of a better term, that CF was trying to re-declare the variable again as a local variable and was choking on it in the process. Once we no longer explicitly declared it and just let CF assume it was a local variable CF was happy and all was back to normal. This is really odd because we explicitly declare local variables all over the application and no other instance causes this problem, just this spot.

So, what's the use of all this? I'm hoping by sharing this that if any of you get the same "White Screen" problem when updating to ColdFusion 9.0.1 that this post will help you identify the problem.

We are documenting as much of this as we can and sending it along to the CF development team at Adobe, hopefully we can help them find and kill this troublesome bug.

Just as a side note, the code we use in the Cartweaver site is very modified and this issue does not affect the standard Cartweaver CF code. It works just fine under CF 9.0.1
Thought I'd mention that to avoid an undue panic :-)

Here's yet another reason why this statement is so true..

I had a CW user email me in an absolute panic! He had used Dreamweaver's Synchronize function to update his site and inadvertently overwritten the Access database file on the server with the test one he had locally! Six months of orders GONE! I told him to contact his host immediately and see if they had a backup of his site, which thankfully they did and he ended up only losing a couple of orders that he could re enter based on the sale notification emails he had.

Think of it, one click of a button and you could destroy years worth of data. Having your database data stored in one little file is just too risky! Besides all the load and traffic vulnerabilities Access presents, the danger of having your data stored in this little corruptible file is just to big of a gamble.

If you are using Access, the first thing you should do is use Dreamweaver's "Cloak" feature to protect the folder your database is in so this synchronize mistake will never happen.

The next thing you should do is move to a server type database. I highly recommend MySQL. It's fast, stable, robust, and since version 4 is fully relational. It's a lot of database and pretty much every host out there offers it for free, as part of their hosting packages. If you add Navicat - in my opinion the best MySQL admin tool out there - to the mix, you'll actually find MySQL easier to work with than Access.

Moving your database to a serious platform, especially for ecommerce where your income depends on it,is just the right and responsible thing to do.

My personal preference for a CMS is a hybrid of custom database/cms and Adobe Contribute.  Things that are repetitive such as a shopping cart (obviously I'm partial to Cartweaver for this) or things like photo galleries, news pages, calendars and the like I use little apps, with simple web based admins that I've developed and then reuse all the time.  For the rest of the site, pages that are for the most part static, but you still want the client to be able to update them I use Adobe Contribute, because it's easy enough to use that even the most computer fearful client can pick it up in pretty short order.

This approach has worked very well for me and I can jump in and make any modifications the client wants.   Is this THE right way to do it?  Nope. It is for me, but if I had spent the time and the effort to become an absolute wizard at Joomla, then it would be the right choice, again for me.
Mind you, I'm pretty proficient in Joomla, WordPress and Mura - but I'm not as able to deliver complex custom solutions in these as I am in my method, so I do what I do best and call on a roster of for-real experts in these other solutions that work with me when a client needs work done in these.

The one thing that I feel is important is that the solution be portable.  There are a lot of available as a hosted solution and personally I just can't bring myself to recommend these to my clients. CMS provider XYZ may be great, afford-ably priced, and offer the latest in what's cool... for now, but things change. If a service or a provider/host goes bad or decides to change their service or jack their pricing and you are tied into their proprietary system, you are screwed. Don't sacrifice your clients long term welfare for short term easy.

So to sum it up, decide what you want to use based on what "clicks" best for you, then be committed to become totally proficient in it. Don't choose any solution as a way of avoiding the need to "learn code" . That approach will eventually only lead to grief, both for you and your clients. Instead be committed to learn all you can and truly master your platform of choice. Taking that approach will pay off very well... for both you and your clients.

First of all, go to http://www.pcicomplianceguide .org/ and become more familiar with what PCI is and what you can do to better secure your online business. Next, if you have a Cartweaver site or any shopping cart site for that matter, what should you do? Let's take a look at what is required to have a "PCI secure site" and briefly discuss what can be done to see if your site measures up.

The following requirements are taken directly from http://www.pcicomplianceguide.org/pci-basics.html -- let's look at these one at a time and see how Cartweaver addresses the issues it can, and what steps you need should take to better secure your online store.
..................................
Build and Maintain a Secure Network
Requirement 1: Install and maintain a firewall configuration to protect cardholder data

• This is in your court as a developer. If using an Access database, make sure that it is stored in a safe non-brows-able folder, if you are using a SQL Server or MySQL database; be sure your host has it properly secured.

Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

• Yes! By all means change all default usernames and passwords and be sure you use something that is sufficient to ward off hack attempts. A good mix of numeric and alphanumeric characters and at least 8 to ten characters in length will be good and change them occasionally to be sure they don't get compromised.

Protect Cardholder Data
Requirement 3: Protect stored cardholder data

• Cartweaver NEVER stores this data -- it is handed off to the payment gateway and then promptly "forgotten". No matter what your client may say, never be persuaded to alter your site to store the credit card type, number, expiration date, or security code... Ever! Just don't go there. Truthfully, in a shared host environment there is no way to store this data securely. Treat it like the hot potato it is and hand it off as quickly as possible and be free of it.

Requirement 4: Encrypt transmission of cardholder data across open, public networks

• Yes -- by all means get an SSL Certificate and have it properly installed in the root directory of your site. Resist the temptation to use the host's shared SSL if they offer one, get your own 124 bit encryption certificate and have it installed before your first transaction.

Maintain a Vulnerability Management Program
Requirement 5: Use and regularly update anti-virus software
Requirement 6: Develop and maintain secure systems and applications

• This would be the responsibility of your host. Have in-depth, frank discussions with your host to 1. Know what steps they take in this regard and 2. Make sure they continually monitor and maintain security. If they don't provide clear and detailed information about this issue, or get annoyed with your insistence of getting this information... change hosts!

Implement Strong Access Control Measures
Requirement 7: Restrict access to cardholder data by business need-to-know

• Again, Cartweaver does not store this data.

Requirement 8: Assign a unique ID to each person with computer access

• Cartweaver does this by allowing you to create individual admin accounts. Be sure your host does the same. Again risk is greatly minimized by the fact that credit card data is not stored. The with the exception of the email address, the data in your Cartweaver customer database is no more than what is freely accessible in the local telephone directory.

Requirement 9: Restrict physical access to cardholder data

• Once again -- this is not stored. If you choose a reputable payment gateway this data is secure. Neither you the developer, your employees, the merchant, nor their employees have any access to this data. You can't steal or tamper with something you don't have.

Regularly Monitor and Test Networks
Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes

• The credit card data is not stored in any way shape pr form, and with the SSL encryption it is securely transferred to your payment gateway -- that takes care of it from the application and your standpoint... Just be sure to use a qualified, reputable payment gateway and host.

Maintain an Information Security Policy
Requirement 12: Maintain a policy that addresses information security

• Be proactive! Your application (Cartweaver) is secure provided your database is adequately secured and you have SSL in place and your usernames and passwords properly set. Beyond that, talk frankly with your host and payment gateway provider to be sure their end is taken care of.

Being able to do business on line safely and securely is the right of every person that chooses to spend their hard earned money online. Internet shoppers are showing a lot a trust when they make a purchase online. It is the responsibility of every online merchant, web application developer, web site developer and designer to do all they can to fulfill that trust by providing a safe, secure "place" to do business. I encourage you to take the time out from your day to day activities and focus on making sure your site meets the PCI standards. You and your customers will be glad you did.

What most do is of course sell any tangibles such a organization logo clothing and the sort from Cartweaver, and since Cartweaver tracks inventory and can remove sold out items from the web many use Cartweaver to sell donated items as well.

For taking cash donations you can add a Cash Donations “Product” then the the SKUs for the product are amount increments the contributor can select. This works very well, the contributor can simply select the dollar amount they want to donate and then go through the checkout process.  These amounts can go up to a reasonable amount, then what most do is included in the “product” description a statement that if the contributor wishes to make a large donation they should contact you directly.

Another way to handle this is to create a "product" with only one SKU and give the SKU the price of one dollar, then in your description for this product explain that the contributor can simply add a quantity to designate how many dollars they would like to donate. Either method can be quite effective.

Using Cartweaver in this way provides a very effective and flexible donations platform.

Yes you can run PHP and CF on the same system,
I do it all the time. In fact for an easy way to set up both I often tell developers to download and install the free CF9 Developer's Edition from Adobe and install it, then download XAMPP (Windows and Mac) which has everything you'll need for a PHP development environment, and install it.

This is an easy way to have both up and running in no time and will provide everything you need to develop in both platforms. The nice thing about this is that you will have MySQL running and available to both platforms. While the CF version of Cartweaver can use and includes an MS Access version of the database, it is highly recommended that you use MySQL which is a far more robust, stable and secure database system. Since the Mac doesn't support Access, setting up MySQL is something Mac users will need to do anyway, and installing both XAMPP and ColdFusion 9 is an easy way to get this done. Unless your system is seriously depleted in resources you should notice no impact at all on your system to be running both.

The only thing to look for is, when you install ColdFusion it by default uses port 8500, so to access your local ColdFusion sites you would go to

http://localhost:8500/YourSiteFolder

Now, if you have installed PHP before ColdFusion and it by chance it is using port 8500, ColdFusion will use the next available port. So when you install ColdFusion 9 and you get to the part where it takes you to the browser based admin to finish the set up, look at the address bar and see which port ColdFusion is using, it may be :8510 or the like. Make a note of this because this is the port you will use to browse to your local ColdFusion sites.

tags and so on - Make sure the content, dynamic or static, is intelligently written to focus on key words and search terms for your business or product category - Just be sure all the tweaking is done.

Then create a Google Sitemap for the site and register the site with Google Sitemaps, next set up a Google Analytics account for the site and place the code on your site and get that all validated. Even if you use your host's site stats and maybe don't think you'll actually use Analytics, set it up anyway.

All this gets your site on Google's radar and indexed promptly, and re-indexed more often.

Try creating a new user for your local MySQL database in whatever MySQL admin you are using (I really like Navicat) - I like to create the user with the exact same user name and password that the database on the live server will eventually be using - this way you don't have to modify any code when you upload your site.  Now give this user access to only the one database you'll be connecting to for the particular site you'll be working on and then give this use full permissions to this database, and save the user. Then create your site data source with the same data source name you'll be using on the server, thus creating, as far as you code is concerned, a mirror setup.

This should get you connected and it will also streamline the process when you start uploading and testing on the server.

First, of to be clear, what is meant by Search Engine Friendly Links? In a dynamic web site, like a shopping cart, a blog, or the like, data and page content are delivered based on variables passed in the URL, for example:

www.cartweaver.com/demos/cfm/basic/Results.cfm?category=6

The part of the URL after the question mark is the variable being passed so the server knows to serve up the products associated with the category with the ID of "6" which in this example let’s say is "boots". In times past a URL that ended in something other than a recognized page extension such as .htm, .php, or .cfm would leave search engines scratching their virtual heads. So clever developers of the time came up with programming tricks that would convert these variables to something more legible to the human eye, such as;

.../Basic/results/boots

Behind the sense you had specially coded functions at work translating the URLs from and to a form that the humans and search engines could read and one the server could make sense of. There are some developers that still doggedly cling to the perceived need for this, but it’s time has passed. Web technology moves on. Case in point, when is the last time you worried about the "web safe color pallet" or spent time wishing you could reliabley format your page using CSS, or wishing browsers recognized .png files? The market forces change! The masses wanted these things so the industry moved to meet the demand.

The is also true of search engine technology. Not long ago Yahoo! Was THE search engine powerhouse, then came along this upstart Google. The market force that Google understood and grabbed on to is that that Yahoo was not a true search engine, it was an index, powered by people sitting at computer screens reviewing and adding sites to its database. As fast as the web was moving, there was no way on God’s green earth this could keep up. Google understood this and developed a search technology that moved at the speed of the web, in the process blew right by Yahoo! and the others. When’s the last time you even heard of Lycos or AltaVista?

This same market force is at work when it comes to effectively indexing dynamic web sites. The search engines simply can not site back and dictate to the web development community that they have to jump through programming hoops and waist time bowing to the inadequacies of their technology. They are fully aware of the fact that the one that indexes the web the fastest and easiest, for the development community and consumers alike will win... Every time! Search engines have caught up! Google does an outstanding job of following and indexing dynamic links, and it continues to get better. They are even spending billions on figuring out how to index the contents of images by reading their binary code, and indexing Flash and mpg files.

So am I saying that there is absolutely no benefit to be gained from having so called Search Engine Friendly links in your site? No, there is still a little to be gained, but the little remaining advantage is dwindling more and more all the time.

Your efforts are far better spent making sure your site content is well written and provides rich relevant information in your key subject areas. You should also spend time making sure you head tags are very well written and targeted, along with a good use of the H1 through H3 or H4 tags. Be sure all your image alt tags are populated and relevant. Finally spend the time to have both a complete HTML and XML site map and register it with Google sitemaps. Doing this detail work will net you FAR better, and longer lasting results that trying to implement a system of search engine friendly links.

To sum it up, search engines are far more focused on what’s IN the site, your content; than they are in how you link to that content. They have gotten smart enough to follow dynamic links... They have had to; the whole web is becoming dynamic! Static web sites and URLs are going the way of the Web Safe Color Pallet... R.O.P.

Good Sales!

This storm cloud may have passed. I'm waiting for the official word from my Authorize Net sources but things are looking up for now.

I can't say more than this for now, and this being as fluid a situation as it is, things could "cloud up" again, but it's looking good. I'll post more as soon as I can!

Authorize Net, one of the web's largest online payment gateways sent out an email to all their merchants that as of May 1 2010 Master Card and Discover were going to go live with a new processing rule that would require virtually ALL merchants to allow partial payments and multiple payment transactions. (There are a some exceptions, but few fit the profile) Yes you read that date right. This notice went out right about the time the rule was to go into effect, and the rule states that if the merchant was found to not be in compliance they would be hit with a penalty!

The first thought that jumped to mind was "What the !$#!@$!@!" - Fortunately even MasterCard realized you can't announce a new rule that will fundamentally change the way EVERY shopping cart website on the web processes credit cards and realistically expect this quick of a response. So Authorize Net got an extension for their merchants that pushes the deadline out to June 30th 2011. It appears that other gateway provides are getting such extensions as well. Best check with your gateway provider to see what they say on this.

So what does it mean?
A quick Google search on the topic brings up a lot of hits, but clicking on the results just takes you to a lot sites and blogs that just regurgitate the word for word content of the email notice which can be read here. Not a lot of helpful "what do I do" content to be found.

What's it really mean?
I'm not going to go into detail repeating the same thing that is available in the email or on on the Auth Net site, that can be found here:

• New MasterCard/Discover Processing Requirements
• MasterCard/Discover Partial Authorization FAQs
• http://www.authorize.net/support/AIM_apiupdates.pdf.

I'd recommend reading over these thoroughly!

Fortunately over the years we have developed a very good relationship with Authorize Net, we refer a lot of business their way, So I had a direct line to call. Talking to my contact at Authorize Net led to two conclusions;

1. They were on it and trying to be as responsive as they could
2. And that they had almost as many questions as I did

So we arranged a conference call with one of the lead techs working on the updates to their API to discuss what all this really meant from a technical standpoint. The call cleared up a lot of questions, but it also raised a number of concerns that still needed to be addressed. My contact at Authorize Net called me back the next day to ask if I would be involved in another conference call, this time with ten or twelve other eCommerce community leaders and if prior to the call I would email my primary concerns and questions so they could be covered during the call. So we had a "LiveMeeting" presentation and conference call with lead Authorize Net API techs and a number of eCommerce developers around the country.

So the big question: How's this impact my eCommerce web site?

It's is pretty simple to visualize. Assuming you are using Authorize Net or a similar real-time payment gateway, the way your web site works now is like this

Current Process

The payment is submitted to the payment gateway, if there's sufficient funds available on the card the payment is competed and the transaction is complete. If there are insufficient funds the transaction is terminated. In other words a single payment attempt is made and it will pass or fail. If it fails due to insufficient funds the user must start over.

New Payment Process

If the card submitted has funds available, but not enough to complete the full transaction, the available funds will be captured and the cart must allow the customer try with another card to pay the balance due.

• Merchants must accept multiple payments for individual orders
• Number of payments not known in advance
• Payment software must recognize multiple payments

While this is easy to visualize it's not an easy technical change! As you can see, this is a fundamental shift in he way virtually EVERY shopping cart site on the web will have to behave! This is going to take some pretty extensive programing to adapt the flow of the cart checkout process to allow for multiple attempts, and to clean up the mess of partial payments if a user decides to bail out in the middle of the process.

So, can we just opt out and do things the way we are now?

Well from a technical standpoint, yes. To prevent sites all over the web from breaking, "non compliant" sites will continue to work just as they do now.

Good, no problem then right? Wrong!

MasterCard will penalize merchants whose sites are found to be non compliant! How much is the penalty? No body is telling! Everyone just points to someone else. But some of the figures being passed around range from significant to bloody outrageous! To the point where the immediate reaction is "how can that even be legal!" I'm still digging to see if I can get somebody to give me a straight answer and will report as soon as I do, but suffice it to say that MasterCard & Discover are serious about this and they aren't going to make it easy to ignore. They are going to force you into one of three choices. Comply, No longer accept Discover or MasterCard, or shut down.

What about just not taking MasterCard or Discover anymore? Well some may choose to do this, but the hand writing is on the wall! Even though they are not being required to do so Authorize Net is preemptively building this functionality into their system for Visa and AmEx as well. They are pretty much expecting them to follow suit.

Why don't we hear more from all the gateway providers about this? Don't worry, you will. PayPal is already hard at this and making information available to developers. All other gateways will fall into line. Many of them are likely waiting to see what Authorize Net does, since many of them offer Auth Net emulation and their APIs work pretty much the same.

So, what next?

Fortunately we have some time. We are working closely with Authorize Net and will be releasing updates to users of current the version of Cartweaver for Authorize Net, and depending on what paths some of the other gateways take, we will release other updates as we can. We will stay on top of the changes and keep you informed.

To stay updated on how this progresses check back here or follow us on Facebook and Twitter. We will release up to the minute information there.

If you are currently using an older version of Dreamweaver, especially anything pre CS3 you should definitely download the CS5 trial and give it a good looking over. If you've been holing off upgrading CS5 will make you glad you did. This is the upgrade you've been looking for - and no, this is not an Adobe advertisement - I'm just pretty jazzed about the improvements in this version and don't mind giving credit where credit is due.

This may cause new users some confusion because these databases are not a file that you can upload. Usually your host creates the database for you but it's empty. Now what?

To demonstrate how to add your Cartweaver database tables and fields to your database, we will use MySQL as the our example since it is the most common database for many and the only one supported by the Mac and Cartweaver PHP. The process is similar for SQL Server.

• First go to the Cartweaver customers page and log in. This will give you access to the Customer's Free Downloads page. Once there, download the MySQL database creation script.
  
  
• Once you have it downloaded un-zip it and look for Cartweaver3_MySQL-Creator.sql
  
  
• Open this file in a text editor such as note pad - Do Not use Word as it will add characters that will corrupt the script. Use only a simple text editor.
  
  
• Now that you have your script ready, open your MySQL database in your MySQL administrator, in this example we will use phpMyAdmin since this is the one many hosts provide.

Now that you are here - just follow the example in this video.

Yes it is THAT simple.

The process may vary depending on what admin you are using, and whether you are using MySQL or SQL Server, but the principle and the basic steps are the same.

As an add note: I highly recommend Navicat (the commercial version) as your MySQL Administration tool. It is far and away the best, easiest MySQL admin out there and well worth the money! - No I'm not affiliated with Navicat in any way nor do I get any kind of commission. I recommend it so highly because I've tried a LOT of admin tools and haven't found any better. Definitely worth a look.

Mirroring your database / data source set up

Although Cartweaver CF supports Access database, it is always our recommendation that you move to a true database server such as MySQL or SQL Server. The advantages of speed, security, and stability are undeniable and well worth the additional set up and learning curve if you are not yet familiar with a these DBS'. Since both the ColdFusion and PHP versions of Cartweaver support MySQL I'll use it as the example here, although the principle apples equally to SQL Server.

Same user, both places.

It's a pretty simple procedure that will save you a lot of headaches. I was surprised to find that many developers will keep different sets of data source files, one for local work and one for the server. The reason for this is they have different log on and permissions locally. This can really lead to confusion and potentially an emergency if the local files are unintentionally uploaded to the server thus overwriting the server settings and breaking your site.

So here's a simple tip.

Using your Database admin - I'll use Navicat (my absolute favorite database admin tool) in this example - set up your local development database. Give this database the exact same name as you or your host used when setting up your database on the server.

Then in the user admin, create a new user and assign the exact same username and password you will be using on your host server. Finally when you set up your data source name (DSN) use the exact same DSN you have on the server... When I say exact, this includes CASE as well, due to the fact that many hosted MySQL servers are on Unix / Linux boxes and are therefore case sensitive. For ease of set up, go ahead and give the local user full permissions to the database for this application, the permissions don't have to mirror the server exactly.

Now, when setting up your local data source direct your DSN to this database using the username and password you just created. Now when moving files back and forth between your host server and your local development environment you wont have to worry about maintaining two data source set ups, since they are both identical it wont matter where the files are.

If you haven't been using this set up already, by all means start today, I hope you find this as big of a time saver as I did when I first discovered it.

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>

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:

• http://www.jasons-toolbox.com/JHeartbeat/
• http://www.ajtrichards.co.uk/jquery-hearbeat/
• http://www.ajaxpatterns.org/Heartbeat
  

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.

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.

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:

• ColdFusion
• PHP
• ASP

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!

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

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.

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.

The following modification for the ColdFusion version will remove items from the cart that are no longer available, and show the customer a message that an item has been removed from the cart because it is no longer available.

Now, in CWIncFunctions.cfm, add the following section of code at line 399, right after this line:

Add the following code:

  
  SELECT c.cart_sku_ID, c.cart_sku_qty, s.SKU_Stock, c.cart_Line_ID
  FROM tbl_cart c
  INNER JOIN tbl_skus s
  ON c.cart_sku_ID = s.SKU_ID
  WHERE c.cart_custcart_ID =
  AND s.SKU_Stock < c.cart_sku_qty
  
  
  
  
    
      
      DELETE FROM tbl_cart
      WHERE cart_Line_ID =
      
    
      
      UPDATE tbl_cart SET cart_sku_qty =
      WHERE cart_Line_ID =
      
    
  
  

Now, when a user comes back to view his cart, any items that are no longer available are removed from the cart and a message is displayed to the customer, and items that have smaller quantities available than were available at the time of the cart creation have their values adjusted. This only affects carts where Allow Backorders is unchecked in the Cartweaver admin.

Update: 10/4/2009 Thanks to Alex in the CW support newsgroup for pointing out that the method does not consider quantities in the cart greater than available quantities. It was written for one situation, but I have now adjusted the code to work with all situations where a quantity is no longer available for a given item

The following modification for the PHP version will remove items from the cart that are no longer available, and show the customer a message that an item has been removed from the cart because it is no longer available.

In CWIncFunctions.php, add the following section of code at line 470, right after this line:

$Cart["Products"] = array();

Add the following code:

if(!$cartweaver->settings->allowBackOrders) {
  $query_rsCWCheckStock = sprintf("SELECT
  s.SKU_Stock,
  c.cart_Line_ID
  FROM tbl_cart c
  INNER JOIN tbl_skus s
  ON c.cart_sku_ID = s.SKU_ID
  WHERE c.cart_custcart_ID = '%s'
  AND s.SKU_Stock < c.cart_sku_qty",$cartID);
  $rsCWCheckStock = $cartweaver->db->executeQuery($query_rsCWCheckStock, "rsCWCheckStock");
  $rsCWCheckStock_recordCount = $cartweaver->db->recordCount;
  $row_rsCWCheckStock = $cartweaver->db->db_fetch_assoc($rsCWCheckStock);
  if($rsCWCheckStock_recordCount > 0) {
    $cartweaver->setCWError("Item Sold", "An item or items in your cart are no longer available or had quantities adjusted");
    do {
      if($row_rsCWCheckStock["SKU_Stock"] <= "0") {
        $query_rsCW = sprintf("DELETE FROM tbl_cart
        WHERE cart_Line_ID = %d",$row_rsCWCheckStock["cart_Line_ID"]);
        $rsCW = $cartweaver->db->executeQuery($query_rsCW, "rsCW");
      } else {
        $query_rsCW = sprintf("UPDATE tbl_cart SET cart_sku_qty = %d
        WHERE cart_Line_ID = %d",$row_rsCWCheckStock["SKU_Stock"], $row_rsCWCheckStock["cart_Line_ID"]);
        $rsCW = $cartweaver->db->executeQuery($query_rsCW, "rsCW");
      }
    } while ($row_rsCWCheckStock = $cartweaver->db->db_fetch_assoc($rsCWCheckStock));
  }
}

Now, when a user comes back to view his cart, any items that are no longer available are removed from the cart and a message is displayed to the customer. This only affects carts where Allow Backorders is unchecked in the Cartweaver admin.

Update: 10/4/2009 Thanks to Alex in the CW support newsgroup for pointing out that the method does not consider quantities in the cart greater than available quantities. It was written for one situation for a customer, but I have now adjusted the code to work with all situations where a quantity is no longer available for a given item.]]> http://blog.cartweaver.com/index.cfm?newsid=77 http://blog.cartweaver.com/index.cfm?newsid=77 Sat, 03 Oct 2009 14:13:18 GMT
These steps aim top give a basic workflow for those of you that don't know where to get started when facing a blank screen.

I usually use a simple 3 step approach to all my projects:

Step 1: Plan
Step 2: Develop
Step 3: Test, test, TEST !

(note: this is just *my* method. I am quite sure each reader has their own set of "rules".

General overview:

Step 1: Plan

A lot of developers neglect to give this step the proper importance. I' think it is the most important part of the entire project.
Not having a good initial plan will add a lot of extra work to any project in the long run.

Why is it so important ?  Becuase the plan, will guide you in *what*  you need to develop, and will force you to know the exact details before you start the actual coding work.
Attempting to develop a shopping cart without previous planning is like attempting to build a house without a blueprint.

A few good reasons why you should plan ahead:

i. It is a lot easier changing things around on a paper than it is to actually change code.
ii. By having all the details before hand it is a lot less probable that you get stumped whilst developing your cat.
iii. Any problems/questions can be solved at the very beginning, instead of having to interrupt development.
iv. By getting your client's approval on your plan, you ensure that you won't have any unpleasant "surprise" features whilst finishing your project.

A very important aspect of planning, is making sure you have all your tools ready, and, that you have a local development environment setup.



Step 2: Develop

If you have done a good job in the initial planning stage, the development part should be a lot easier to handle.

Your plan will act as a map, helping you focus on the actual development, without having to worry about possible setbacks.
Whilst developing, I recommend you do daily backups of your entire work folder. By doing this you can rest assured you don't loose any work, or accidentally overwrite any files. There is no such thing as "too many backups" !

A lot more can be said about the actual development. In future entries, I will be focusing in detail in the actual development process.



Step 3: Test, test, TEST !

Once you have finished your project, be sure to test it thoroughly. You can't trust it to just work because it's supposed to.
You should try all existing site functions to make sure each works as expected.

Never assume the user won't click somewhere!  If there is something not working, chances are, users will try just that.

Sometimes, I find it quite hard to test my own sites, since I know how to use it. I usually ask someone else with basic knowledge to try it.  A lot of times, I just ask my mom; she's 60, and has no advanced knowledge of any kind. She knows the basics of sending email, browsing the web, and using Word.  Having a "non-tech" person test your site is an excellent way of making sure your site is user friendly.

A lot of times, we feel we have so much work to do, we don't take the proper time to test our work. I regret each of those occasions. Even if on a tight schedule, I test all of it.
This doesn't mean that all I do is bug free. But, at least i know that if there is a bug, it won't be an obvious one.


Over the next few weeks, I'll be focusing in detail in each of these steps, and giving some extra tips for advanced users.  Next week, you'll get an in-depth guide on how to tackle Step 1, and how to setup your local staging server.

Please, do post your opinions !

The full list of release notes can be found at http://us2.php.net/migration53.

The main reason for the updated code is the fact that the following functions are now all deprecated in PHP and will throw E_DEPRECATED error messages when used (E_DEPRECATED is a new error message level). The functions are removed in PHP 6:

Deprecated functions:

call_user_method() (use call_user_func() instead)
call_user_method_array() (use call_user_func_array() instead)
define_syslog_variables()
dl()
ereg() (use preg_match() instead)
ereg_replace() (use preg_replace() instead)
eregi() (use preg_match() with the 'i' modifier instead)
eregi_replace() (use preg_replace() with the 'i' modifier instead)
set_magic_quotes_runtime() and its alias, magic_quotes_runtime()
session_register() (use the $_SESSION superglobal instead)
session_unregister() (use the $_SESSION superglobal instead)
session_is_registered() (use the $_SESSION superglobal instead)
set_socket_blocking() (use stream_set_blocking() instead)
split() (use preg_split() instead)
spliti() (use preg_split() with the 'i' modifier instead)
sql_regcase()
mysql_db_query() (use mysql_select_db() and mysql_query() instead)
mysql_escape_string() (use mysql_real_escape_string() instead)
Passing locale category names as strings is now deprecated. Use the LC_* family of constants instead.
The is_dst parameter to mktime(). Use the new timezone handling functions instead.

The functions previously used by Cartweaver are ereg(), ereg_replace(), session_unregister(), and split().

There is also a new PHP site devoted to Windows installations at http://windows.php.net/

If anyone has a Cartweaver version pre-3.1.16, you will want to download the latest version and apply the fixes/changes. To download Cartweaver, go to http://www.cartweaver.com/customers and login as a customer. You should see your downloads. If you have not updated a Cartweaver installation, the easiest way is to simply replace the files in the /cw3 folder. If you have made changes to any of the files in your site, the UpdateNotesCW3PHP.htm file details each change to each file showing line numbers and code before/after. I've found Beyond Compare (http://www.scootersoftware.com/) to be a valuable tool for making line-by-line file changes, or comparing directories.

Update: 2009-09-08 6:47pm One thing I noticed on the PHP site is that the Windows ISAPI version of PHP is not supported any more. Hopefully the bugs have been addressed in the CGI versions, as previous versions of PHP were crash-prone when using the old CGI version. Supposedly the new FastCGI version is better.

 Keep an eye on my this blog as I will post anything new or cool we hear about at the conference.

Also, be sure to follow me on twitter and.or Facebook. I'll be posting there frequently.

http://twitter.com/LawrenceCramer
http://www.facebook.com/home.php?ref=logo#/lawrence.cramer?ref=name

 I hope to see as many of you there as possible, if you are there be sure to attend my session on "Real World eCommerce"  at 2:00 on Tuesday 

Cheers!

Some very good videos on Adobe Labs
Ben Forta's Article
Simon Horwith's Blog

Finally, a bit more in-depth take a look at Adobe's Live Docs

One of really interesting aspects of the new betas is CF Builder (formally code named Bolt) For the first time since the Allaire days, pre Macromedia/Adobe ColdFusion will have a dedicated development environment for the hard core coder. This will open up some doors to serious development that were hard to get through using the hodgepodge of Open Source tools or Dreamweaver which is admittedly tilted more toward the visual designer/developer.

So all in all, the next generation of CF is a big leap and there's no doubt that it will have a big impact on the way many of us do things. I would highly recommend all CF developers, or those wanting to learn more about ColdFusion go to Adobe Labs and download the beta and give it a try!

You should also give CF Builder a try as well... A word of caution here, CF Builder is built on the Eclipse platform, which means if follows a significantly different workflow that Dreamweaver and there is a fairly significant learning curve involved to get your head around the way "Projects" - This is how CF Builder refers to "sites" as Dreamweaver calls them. Is it worth the effort? This is actually a fairly easy question to answer. If you develop ColdFusion based web sites, but most of your time is spent in Dreamweaver's design view, probably not. It you spend the majority of your time working with ColdFusion in Dreamweaver's code view, the most definitely yes. So depending how you currently work CF Builder may be the greatest thing to happen to the way you work in a long time, or a non issue. It'll be up to each individual to decide.