Congratulations on the PhD, Scotty!
It seems as if we ought to form a collaborative effort to meld together the different variations on ShopX, etc. into one coherent project. I need to set up another one beginning this week, and in the process I hope to implement some of the changes that I decided would be useful in the last store. And rthrash has suggested developing for 0.97 (or at least with that in mind), since it should include database-based sessions as part of the core, which would mean that we could/should link to those tables rather than reinventing the wheel (or the laser cannon, depending upon how advanced you view such an invention).
I made some pretty significant changes to Susan’s base code, especially in order to allow for item options. This means that items in your basket actually need to be identified by more than just their product id, since a small red t-shirt is not the same as an extra-large blue one (and the add to cart function needs to take this into account). I also added some session auto-logout code (with alerts to the customer X minutes beforehand) so that session timeouts don’t just throw the whole process into a tailspin for no apparent reason.
Some things that I would still like to do (and hope to start this week):
- Although I was orginally of the opinion that sessions wouldn’t be reliable enough to use for this purpose, in practice they seem to be doing very well for the ordering info (name, address, payment info, etc.). So I don’t plan to change that for now, since I actually like that such private information is only stored temporarily. When MODx has database-based sessions then I would definitely switch to those, if only for the increased security on shared servers.
- For basket contents, however, I don’t think that sessions are working so well in my experience because people are more inclined to add items to their cart and wait a while before deciding to checkout. This means that sometimes their sessions expire (and they’d forwarded to a logout page) when they haven’t entered any personal info at all, so there was no security reason for doing this. So I think that the best method for handling basket contents is using a cookie, and I’m going to re-do my code for the next store to do that exclusively (and probably patch the one that is online and taking orders to look for a cookie when no basket session is found so as not to have to change everything on a live site).
- The new version of eForm is capable of sophisticated regex and custom function validation and can trigger multiple events throughout the validation/submission process, so I think that we should create the minor additional code that would make it a fully-functional checkout script. That would essentially mean adding functions to validate credit card numbers (before sending for processing) and other data and reformat it for standardized output, as well as some error- and fraud-prevention checks against the product database, etc. Like the rest of ShopX, these could be modular chunks of code that people could modify and use as needed.
- I created an offline processing module that is working very well for these folks so far, but has their templates and database info hard-coded into it, so I’d like to finish that properly and then re-do it for the next site with wider use in mind. Currently it uses a separate database from MODx and all of the scripts that access it are stored in a password-protected directory with forced SSL access via .htaccess. I’m not using the MODx API or any other external libraries at all so far on the theory that you never know when one of these might be compromised and allow hackers to access this information, but I’d be more than open to review the security of this setup with those who have more experience than I do, since I’m of the opinion that taking people’s credit card info lightly is bad karma.
- And I still have a lot of cleanup to do, and this store has some peculiarities that caused me to create very specific templates and TVs, so I’d really like to refine this into a more standard package that could be a more useful starting point for other folks.
So how should we go about trying to combine all these crazy ideas into one relatively-coherent package? Should we set up a test installation somewhere that we can all access and try to merge code that way? And if so, should we use 0.922 or 0.95 or jump straight to 0.97?
I have been very happy with my own Frankenstein so far. I think it’s performing at least as well as the last CubeCart system that I set up, which until now was the eCommerce program that I hated the least. The clients seem happy as well, and they’re selling about $500 to $1500 a day through it, with lots of positive comments from customers to boot.
☆ A M B ☆
