I ran into a perplexing problem with my dedicated server this week. First of all it was hacked! That was not fun. Fortunately I got an instant flood of emails letting me know it was hacked and was able to immediately work with my host to resolve the issue. The hack wasn't anything terrible, just a malicious prank that ended up routing requests for any of the sites to an obnoxious "You've been hacked" screen. Don't these people have anything better to do?

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 :-)

A few words of advice if you are new to developing shopping cart web sites. Just because you found an affordable ecommerce app that is easy to integrate - such as Cartweaver - doesn't mean you should be doing shopping cart sites for cheap! Sure Cartweaver provides a real leg up and makes things so much quicker and easier, but a fully dynamic, database driven, ecommerce site still has complexities and many times unforeseen complications, that have nothing to do with Cartweaver itself. There can be host issues. Issues with the payment Gateways. Merchant accounts, you know, all the elements involved in an dynamic, professional, ecommerce site. Then there's the client who springs that infamous "could you just...[ fill in blank here ]" feature request or change orders on you. The point is, when you are creating an ecommerce site for a client you are stepping into a more complex role than just a web designer. You also end up being a consultant. Be sure you charge accordingly! The end result is both you and your clients will take your job more seriously, and you'll make more money. Both of those are good things!

Hope you find this helpful.

Cartweaver CF supports MS Access, but should you use Access?  (note the PHP version doesn't - It uses MySQL by default) Cartweaver supports Access because some users insist on it and we'd likely lose sales if we didn't, so the market sort of forces us to do so. But we don't have to like it. My advice to anyone is to move, right from the start to a database server such as MySQL or MS SQL Server. (Cartweaver ColdFusion also supports MS SQL Server and Cartweaver ColdFusion also Supports MySQL)

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.

I find that those who use CMS like Druple or Joomla, Mura, or even WordPress in some cases in hopes of avoiding the need to know code end up with sites and site admins that their end users ultimately find frustrating and confining.  Does this mean the the CMS is bad?  No. It means the developer is - well maybe not bad, but lazy.  I've seen all of the apps mentioned above do amazing things, in the hands of developers who really dig in and learn the framework and how to adapt it to all the inevitable tweaks and customizing they are bound to be asked for by their clients. No "as-downloaded" pre-done app is going to fill every need, and the more they try to the more complex, bloated and cumbersome they become.  So the burden still rests with the developer to dig in, learn code, be it PHP, CF, the framework of their chosen CMS or combination thereof.

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.

It's no secret that identity theft and customer information security has become a huge concern for anyone doing business on the web. Unfortunately there are far too many careless online merchants who improperly handle sensitive consumer data and countless unscrupulous individuals eager to take advantage of the situation. The industry is trying to do something about it, but it's extremely difficult when you are dealing with a rapidly moving target like the internet. One of the efforts to increase the security of online commerce is the movement toward PCI Data Security Standards. Will this be the solution? The magic bullet to kill identity theft and bring security to the web... Who knows, time will tell. But any effort to increase the security of online commerce is a worthwhile endeavor, so what can you do to see about being PCI compliant and make yours a safer site to do business with.

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.

I've often been asked if Cartweaver can be used on a site that primarily takes donations... The answer is certainly! We have a lot of folks that use Cartweaver to “sell” donations. 

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.

Can CF and PHP Get Along?

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.

If you want your site to be found quickly and be indexed thoroughly by Google, the best thing to do is carefully, page by page, make sure that everything is SEO as you can possibly get it, you know... Title tags, H1 - H3 or 4 tags, body content in

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.