Made of Everything You're Not

About a year ago I reviewed various shopping cart platforms for what was to be an “upcoming” project. After numerous delays and client hand holding (with the requisite back and forth) one year later that project finally began. And, as has lately become a trend in my professional life, the client’s spec combined with a drastically shortened and accelerated deadline forced us to go with something completely unknown and with only cursory inspection; the 3rd party e-commerce ExpressionEngine module CartThrob 2.0 (beta at the time of this review BTW).

CartThrob

Of course this presented the problem of actually using an unknown package to build a site with. Thankfully though, while CartThrob has a steep learning curve and is most certainly missing key functionality, it’s an overall nice package that allowed us to do what we needed. Sure, there’s pain involved (lots of configuration, testing and set up) but with a little elbow grease it all worked out.

As mentioned, CartThrob is an ExpressionEngine module for managing an online store. It’s available for both ExpressionEngine branches (1.x and 2.x) and was voted Module of the Year by Devot:ee in 2010 (for the 1.x version only). This being an ExpressionEngine project CartThrob would, in theory, be a nice fit.

One of the really nice things about using CartThrob is that it uses the ExpressionEngine admin panel for managing your store. This meant there wouldn’t be a second administration site that the client would have to learn. (Personally, I always found dual admins to be janky at best and sloppy/lazy at worst so this was a definite bonus in favor CartThrob.)

But this is also double edged because, well, pretty much everything about your store is saved into the entries system within ExpressionEngine. This, of course, causes your Entries panel to become an eye sore whenever you have to do anything there. Instead of having a dedicated section to manage products you use the Entries section. Instead of a dedicated section to manage your orders you use the Entries section. Instead of a dedicated section to manage… well, you get the idea; everything is managed through the entries. This makes sense for the product management but when you have to dig through entries to find orders and coupons and discounts (etc) things get a little jarring for some people (even internally with my team) so it’s a concern.

Still, single freaking admin so it was kind of a lesser evil compromise.

The unusual thing though is that, for how thoroughly the management of items was punted (though, to be fair, it looks to be a feature versus bug debate more than “punting”), CartThrob has an extremely deep configuration section where you can customize CartThrob to function just right. CartThrob has all the basic customization functionality one would expect from any modern shopping cart platform (tax, shipping, payments with lots of merchant options, etc) plus a bunch of settings just to get CartThrob working (CartThrob is NOT an out of the box solution). It’s all presented in an easy to use interface that’s designed to mesh with the ExpressionEngine administration panel design which makes for an easier experience.

As far as merchant accounts go (for accepting payments through your site) there’s the usual suspects of Authorize.net, Paypal and SagePay built right in but also some offline solutions for pay by check and credit accounts. For this project we used Authorize.net which went smooth for the most part but I can’t speak for the other options though if they’re anything like the Authorize.net one they’re probably cool. CartThrob also includes some extensions and hooks so writing your own payment gateway is possible if you need.

CartThrob can also hook into the ExpressionEngine member module so your customers can be registered internally. Like pretty much everything else with CartThrob there’s a bit of configuration involved to get it up and working though. Unfortunately though, there’s not really any out of the box functionality for your members to take advantage of. For example, there isn’t any way for your customers to view their past orders when logged in and when using the control panel and viewing a member’s profile there’s no relationship with CartThrob. You’re gonna have to write all that stuff yourself but, and I don’t know why, but CartThrob doesn’t store any relationships between ExpressionEngine members and it’s customers so expect a challenge.

In terms of the user side, the actual storefront, everything is done using ExpressionEngine templates and template tags. There are lots of module methods available and even though it’s far from a complete package of the expected functionality. In fact, on our team, we got into a habit of thinking of CartThrob as a Lego set for creating what we want instead of having what we want already.

For example, to view the details about a users cart you’d use the template code below:

{exp:cartthrob:cart_info}
	{total_items} <br />
	{total_unique_items} <br />
	{cart_entry_ids} <br />
	{cart_shipping} <br />
	{cart_tax_rate} <br />
	{cart_tax} <br />
	{cart_subtotal} <br />
	{cart_total} <br />
{/exp:cartthrob:cart_info}

On the surface this appears to be nice because it keeps things within the core ExpressionEngine development process. And it would be except, well, CartThrob isn’t abstract enough. Too many times I would try to do something that seemed obvious, like checking for shippable items within a users cart, and would come up short; that functionality doesn’t exist.

Still though, don’t get me wrong. Yes, some of the above sucks. Absolutely. But CartThrob is still under development. Plus, since it’s a commercial script ($99) there’s financial incentive to improve it. And, truth be told, for as painful as certain points were it’s still way more fun to build a site with CartThrob than most of the other options I’ve used or reviewed like OpenCart or Avactis.

Plus, again, single freaking admin!

Avactis is another in a long line of e-commerce web applications written in php (similar to OpenCart and PrestaCart), this one a little different in that Avactis has different versions, each with different features, depending on how much you’re willing to spend. Avactis is a full featured product with all the bells and whistles any ambitious store would need (and then some more features stacked on top for good measure) combined with a very php like integration methodology. Unfortunately, the dated administration interface combined with a lack of a plugin architecture and theme community really holds it back from the awesome bar.

Avactis

For the uninitiated, Avactis is created and maintained by Pentasoft Corp; oddly, there’s no website for the parent company so take that for what you will. As mentioned, Avactis is based on a pay model though it’s way more upfront about it than PrestaCart and, while the free version is missing some features, the source is available for modifications. Not too bad in my opinion; at least the more cash strapped shops can still play if they want to.

The different versions of Avactis are Free, Owned ($199), Monthly Leased ($19.95 a month) and White Label ($299) each with their own features and options. Most notably the Free version doesn’t include any (useful) payment modules (Authorize.net anyone?), coupon module, data export and import, quantity discounts or search engine friendly URLs out of the box. They do offer discounts for web developers though (at least 50% and they say up to 100%), and the complete source is available without obfuscation, so at least those functions that are needed can be added which can really ease the pain of paying for the thing in my opinion.

As expected, Avactis has the ability for custom themes though I’m disappointed to see that there doesn’t appear to be any theme community in existence (compared to other cart software packages). The reasoning behind this is probably because Avactis bills itself as being “easy integration with an existing website thanks to unique Avactis tag technology”. And by unique they mean including a php file and calling php function snippets. I’m all for marketing hype but wtf is that?!? Here’s an example:

<?php include('init.php'); ?>
<?php NavigationBar(); ?>
<?php Breadcrumb(); ?>
<?php ProductList(); ?>

It’s called php and EVERY php site does this Avactis not just you. Essentially though, this isn’t a bad strategy and, in fact, is definitely a strength especially without all the hyperbole. Obviously, Avactis can stand alone and doesn’t need to be integrated into a separate site but it’s a good idea to allow easy integration into existing sites.

Avactis PHP shopping cart software

Avactis is packed with all the features any online store would want; content management system, coupon and discount mechanisms, order and customer management, packing slip builder to name a few. Each feature is also highly customizable and usually includes a plethora of options and settings; nice if you build complex product build outs or specific functionality. On the other hand though, this amount of features and customization comes at a cost in terms of ease of use, work flow and a lacking user friendly experience.

The administration interface for Avactis is a nightmare mess of pop-up windows, tabs and accordion widgets. Slick is not a word I would use to describe the experience. Functional or crappy or painful or eyebleedingworstinterfaceeverpleasekillmefortheloveofgod!; those are better words to describe it.

There’s inconsistencies all over the place; for example while editing a product the help widgets will open another pop-up window (sigh…) yet in the main menu hovering over a link will display a tool tip and in the installation process the help widgets are all inline divs.

Avactis Admin Popups

Going through the code yields such codesod qualifiers as the below:

<?php
    /**
     * Defines the possibility of uploading images by file type.
     *
     * @param $file The array consists of the $_FILES variable, for
     * the current file.
     * @return boolean
     */
    function isAllowedImageType($file)
    {
/*        $type = _ml_strtolower($file['type']);
        switch ($type)
        {
            case 'image/gif':
            case 'image/jpeg':
            case 'image/jpg':
            case 'image/jpe':
            case 'image/jfif':
            case 'image/pjpeg':
            case 'image/pjp':
            case 'image/png':
            case 'image/x-png':
                return true;
            default:
                return false;
        }
*/
        return true;
    }
?>

If that doesn’t make any sense to you suffice it to say that the above function is supposed to verify that an image’s mime type matches the list; unfortunately though, the function is, what we call “commented out” and will not be executed. All files sent to the function will validate as true so, essentially, any file type can be uploaded. While it’s entirely possible this is an old function that was replaced with something useful, and it should be noted that I never found any calls to that function (but I really didn’t look too hard), the fact that it’s still in the code-base speaks volumes, to me, about the project maintenance at the very least.

On top of that Avactis has one of the most wasteful and useless installation processes I’ve ever seen. Initially, Avactis ships with a very minimal file set that includes a 15 mega byte (MB) file whose sole purpose is to contain all additional files in a gzipped and base64 encoded string. The sole purpose of this is to allow Avactis to programmatically write all source files to the file system during installation. For the life of me I can’t imagine what functional requirement precipitated this design decision. Considering the complexity added to the development cycle this would cause it makes no sense to me; I’m at a loss. I could be missing something though; you never know it may have a really sick benefit that I’m just not privy to.

Are any of those “issues” at all relevant? Not the function and not the installation process. Those are subjective issues that may only matter to me; it’s armchair quarterbacking at it’s finest (if I do say so myself). For everything else, well, that obviously depends on the specific needs of the project. For my needs it’s a pass simply because my clients care about the interface and Avactis looks like it hasn’t been updated since 2002 (at least).

So, while Avactis is a nice program with all of the features any store would ever need I personally feel that it’s not ready for my project.

As a continuation of my research into choosing an appropriate shopping cart application for an upcoming project I’m working on I chose to review OpenCart this time. To be honest, I hadn’t even heard of OpenCart until one of the comments from the last post turned me onto it but after reviewing it I am glad I did.

opencart-logo

As mentioned above, OpenCart is another e-commerce platform useful for setting up an online storefront. OpenCart is released under the GNU General Public License version 3 (GPLv3) which means it’s freely available for anyone to use and since OpenCart is written in php it’s right in my wheel house. The main developer of OpenCart is Daniel Kerr who, from what I can gather, is over in Great Britain but not the Australian rules footballer (in case there was some confusion from any Aussies).

Anywho, OpenCart has lot of good features available out of the box with my favorites being the Backup Manager, User Groups, really nice localization (l18n) and internationalization (i18n) options, support for multiple stores and a slick reporting overview. OpenCart also has the one feature I personally love from any and all e-commerce packages; Guest Checkouts. Personally, when I’m buying something from an online store that’s not a 500 pound gorilla like Amazon or Best Buy I hate signing up for an account. Guest checkout is the shit.

The code is really well structured and thought out; it uses a nice implementation of the MVC pattern which made things ridiculously easy to walk through and find out what was going on under the hood. OpenCart appears to be using a home grown MVC framework, which, while, in my opinion a little unnecessary,  isn’t at all a big deal. Unfortunately, the code appears to be open to Cross Site Request Forgery (CSRF) attacks and other security issues. More on this in a minute.

The OpenCart administration module is attractive and laid out logically. Everything is ready and available in such a way that most people with experience working with administration panels would feel right at home. It should be noted though that the administration panel will NOT work in Internet Explorer 6.

OpenCart Dashboard

Naturally, OpenCart also ships with the ability to have custom themes and the default theme that ships with OpenCart is quite attractive too. After reviewing the procedure for creating themes though I have to say that I’m not even a little impressed in how themes are supposed to be created; they appear, in my opinion, to be overly complicated, a little convoluted and deviates from the traditional manner used with countless other open source projects.

OpenCart Store

OpenCart has a basic module system though it isn’t what, in my experience, should be considered a module system; in OpenCart a module is more of a sidebar widget. A small distinction to be sure and not really an issue; more of an inconvenience of nomenclature than anything else but something that drives me nuts (can’t we all agree on what these terms mean already?).

There’s also a lot of manual intervention needed when configuring the system. Want to add a module? FTP the module, go to the module section of the admin, click install, click edit and fill out the form (be sure to enable the module too). Want to turn on search engine friendly URLs? Rename the file .htaccess.txt to .htaccess (through FTP or similar) then go to the administration panel, then to the settings area to enable. Very anti user friendly in my opinion.

There are other issues with OpenCart, like the flow for adding images to a product being pretty convoluted, but those are all small in the grand scheme (pretty much all my gripes can be, rightfully, dismissed as design decisions I don’t agree with). Fair enough. What isn’t acceptable is the complete lack of respect the developer has for security in OpenCart or the developers who try to help out in general. This, I’m afraid, is a deal breaker.

May 2010 was actually a pretty fortuitous time for me to research OpenCart; as soon as I began looking into the program I started seeing some discussion on OpenCart which lead me to a forum post on the official OpenCart forums. Another developer had some suggestions on how to improve the style and conventions of OpenCart and, well, Daniel really showed his ass.

Then, not a week later, I see on that there’s another war going on between Daniel and a developer who found some pretty nasty CSRF issues. Again, Daniel showed his ass (along with a good helping of ignorance mixed with arrogance this time) with nothing being resolved.

This was truly the breaking point for me. Why in the world would I ever use software written by someone who, when confronted with the issues, acts like nothing’s wrong? Nope. I have people relying on me to make choices that won’t, you know, ruin their business and OpenCart, for all it’s bells and whistles and nice code and pretty administration panel, is a horrible platform because the developer refuses to do anything about issues when presented with them.

I’m getting ready to put together an e-commerce site soon and, with the budget what it is (sigh), I have to use a third party package to build on instead of writing a custom platform. Not a new scenario, at a basic level, but it’s been a while since I’ve had to go with this strategy. Put plainly; I have no idea what my options are when it comes to e-commerce though I know I don’t want to go with OsCommerce or CubeCart or, and only because the client forbids it (seriously), Magento.

Should We Use PrestaShop?

PrestaShop is an open source licensed (3.0) e-commerce platform that I was recently introduced to by my friend Caroline; it’s not without it’s faults but there’s also a lot to like once you get past the boogers. PrestaShop has one of those open source business models that’s good for developers but kind of bad for the civilians. By that I mean if you know what you’re doing you can get a shop up and running with little to no cost outside of development time. If not, well you have to spend money in the PrestaStore to buy modules for payment gateways and additional functionality.

Out of the box PrestaShop includes payment modules for Bank Wire, Cash on Delivery (COD), Google Checkout, Paypal, Paypal API and, seriously, checks (I imagine because nothing screams competent company like check by mail and COD payment options). If you want to use any other payment gateway, like Authorize.net for example, you either have to buy it from the PrestaStore for 255 fucking dollars or write your own. Seriously.

The documentation is lacking to say the least. There are all sorts of references to a mythical “Developers Guide” which is coming soon with no hint as to when it’s going to be made available. Since they have an entire site dedicated to selling modules it’s hard not to think of this as intentional (which makes PrestaShop look like dicks in my opinion).

One thing that’s pretty refreshing though is their honesty about incompatibilities with various versions of php. They even know what’s wrong with each version. Right there on the download page they have a very nice warning:

* Some PHP 5 versions are bugged and prevent PrestaShop from working correctly:

* – PHP 5.2.1 (authentication is impossible)
* – PHP 5.2.6 (authentication is impossible under 64bits servers)
* – PHP 5.2.9 (image management/upload broken)
* – PHP < 5.2 (invalid date timezone)

On the one hand it’s really cool that they know there are issues with their software depending on the configuration. On the other hand though it’s a little unnerving that they know about the issues but haven’t fixed them yet. That says to me, and maybe it‘s just me, that development is a little inconsistent and poorly managed; something you DON’T want when choosing any third party solution.

The PrestaShop installation process is actually pretty nice, though  the design is guaranteed to make your eyes bleed and it’s not without it’s bugs. The installer goes through the normal and standard system checks we’ve all became used to with third party packages which is nice. The only real issue is that the installer needs the last name field to be capitalized. Weird but really a non issue in the big picture.

PrestaShop Installer Bug

As to the larger issues of bugs and management, Nick Bartlett has spent quite a bit of time documenting those. I haven’t had a chance to look into the extent of them yet, not having used PrestaShop in a production environment yet, but according to Nick’s blog, which I highly recommend checking out if you’re interested in PrestaShop, there are bugs and issues with timezones, removing orders, overzealous security hacks and the product attributes leaves much to be desired.

It should also be noted that I was never able to get the search engine friendly URLs to work. This was on Apache 2.2 CentOS 5 box. I don’t know why though I didn’t look into it too much. Could be my fault but I doubt it.

PrestaShop Administration Panel

The default theme is really gross for both the admin and client sites but it’s possible to create custom themes for the client site. You’ll have to suck it up for the admin site though.

PrestaShop Demo

Digging through the code leads to all sorts of insights. For example, the code style is a bit of a hybrid between procedural and OOP but in a very familiar way. It reminds me of a lot of projects; very logical. Interestingly, PrestaShop uses Smarty as it’s templating mechanism. For me, this is really nice; especially since I’m already familiar with Smarty.

Also, as previously mentioned, there’s a module framework though, also as previously mentioned, the documentation doesn’t exist. So, in theory, it’s possible to extend on PrestaShop though I haven’t had a chance to dig into how that’s done exactly. Expect that to happen in the future though.

All and all, even with the bugs and “issues”, and keeping in mind that I haven’t actually used PrestaShop, I’m not against it. Yes, it sucks that the module everyone and their mother is going to need (Authorize.net) is a paid module but it’s still better than OsCommerce.