eCommerce News & Resources by oscommerceuniversity.com

SEO is a dominating concern among store owners.  So much so that for many site operators it is almost the ONLY thing they focus on. In her article SEO – Is It All You Need? Michelle Symonds challenges this flawed assumption, and offers a number of other  issues which should be considered or addressed by store owners.  Those include Social Media, Website Design, Traffic Analysis, EMail marketing, and Quality Data Capture.

Social Media:

Ms Symonds issues a call to action here, suggesting that store owners embrace Facebook, Twitter, blogging and social bookmarking.  Unfortunately, she fails to justify this based on any useful metric, then calls for the use of ghost writers or ‘social media marketers’ .  This is hardly ethical given the fundamental premise that social media is based on relationships between people.  Still – Social Media marketing offers a viable alternative to search engine marketing.

Website Design:

Look-and-feel, usability and functionality are indeed key factors which can make or break a web store.   Ms. Symonds point about including a call to action is certainly important.  I would go further.   Make sure your account creation and checkout routines function smoothly and efficiently, maintaining data accuracy throughout the process.   Test them multiple times, checking that required data elements are actually required by the site software, and that mistakes in data entry are handled gracefully – with the user being able to correct those mistakes and still complete the process.  Bottom line – it does not matter how effective your call to action is, or even whether one exists, if the cart can’t perform its tasks accurately and completely.

Take care that usability does not compromise security.  Effectively layered security often requires a few extra clicks in each process.  They’re well worth it.   Trust, or the lack thereof, is a huge factor in sales resistance.    If cutting clicks leaves your site more vulnerable to penetration (and if often does!) its not worth it.  Nobody trusts a site that spouts malware, and disclosure of personal information by crackers can cost you far more than you’ll gain by cutting one or two clicks per page.

Traffic Analysis:

Ms. Symonds makes some very good points about using Traffic Analysis to drive marketing activities.  But traffic analysis can also be used to monitor the security environment.  This requires that you know your software, and be aware of what is normal in the URL’s used to access it.   Traffic Analysis tools such as Google Analytics can also be used to CONTINOUSLY monitor your site for flaws in critical processes such as the checkout and account creation funnels.  Why wait until your cashflow is completely gone to realize your cart has technical issues?  Traffic analysis is about much more than marketing, and it is time the eCommerce industry realized that.

Email Marketing:

Ms Symonds makes the case for Email Marketing as a means to retain existing customers, reaching potential new customers and establishing brand recognition.  All well and good, and I’ve seen many store owners do quite well with this.  But, don’t neglect the opportunities to establish trust by using safe email practices such as using client certificates to verify the originating address, ssl certificates to secure account URL’s and un-obscured cart native urls to route clients to the information you want to share with them.

SEO is important stuff indeed – but site operations optimization reigns supreme.

While playing catch up on some of my reading recently, I’ve noticed a number of posts about CRE Loaded admin security.  Much of this was prompted by the publication of a PHP_SELF related vulnerability which affected both the admin and catalog pages.

One pretty good article on the topic can be found on the infotales.com blog  – http://www.infotales.com/hardening-protecting-cre-loaded-admin-area/.   Some good stuff there including inventive use of a security by obscurity method long implicit in osCommerce based code but little used.  So far, the post has garnered only one commit – Steve Makin’s note on Sept 1st to the effect that simply leaving the admin out of robots.txt accomplishes the same thing.   I tend to disagree.

The only “benefit” to removing the admin folder from the robots.txt file is to allow legitimate bots to attempt to spider the admin space.  Make an error in the IP based protection setup recommended in the Infotale article and they will do so.  Ostensibly, removing the folder ID from the robots.txt file will prevent it from being published to “bad bots” and reduce exposure.  This misses the point that the default admin folder location is ALREADY KNOWN to operators of bots used to locate vulnerable websites and is specifically looked for by any competent cracker of osCommerce based sites.  This is reason enough to actually move the admin location if you are looking to gain some security by obscurity for your site.

The Infotale article also suggests that the admin should be secured by .htaccess rules which restrict access to specific IP addresses,  require additional passwords for the admin folder and using secure user names and passwords.  The first two are great options to use, widely available and in many cases implementable using your hosting control panel.  The IP restriction may be tricky to impossible, if your web access relies on a service which does frequent IP switching.   The final suggestion , to use secure user names and passwords is probably the most frequently overlooked element of ecommerce security.    I’d add to this, USE YOUR USER ID AND PASSWORD ONLY IN SECURED ENVIRONMENTS.

Why?  Because the most common form of ecommerce site cracking seen in the pertinent anecdotal evidence has been and remains the social hack.   Crackers may be the same service provider who tweaks your code to allow the latest greatest SEO URL’s to be used, entering using the authentication you gave them for purposes very different than what you had in mind.  Equally overlooked is the fellow overlooking your shoulder as you type your own authentication on the keyboard at a wireless hotspot or public machine at an Internet Cafe.   These types of cracks are great reasons to follow PCI compliance rules related to password changes and strength.

While it would be great if CRE Loaded and other web store software supported the tools needed to implement password rotation and strength policies, you can do this without  such tools built into the cart.  It requires a bit of extra work, but the results may be well worth it as our experience is that sites hosted in more secure environments and managed using less risky habits tend to outperform other sites by at least 2 to 1.   Two tools useful in doing so are PhpMyAdmin and Keepass.  Any other password manager will do, and so would any database tool, but PhpMyAdmin is widely available, and Keepass is free.  The combination makes them ideal candidates for managing password policies manually when the need exists.

First, know your applications structure well enough to pick out which table to monitor.  CRE Loaded uses the admin table to store admin account data, including the ID, password and (most importantly for our purposes) the date field reflecting the last modification of the account record – in this case the admin_modified field.  Using PhpMyAdmin – check this table and look for dates which are older than the maximum allowed password age as set by your store policy.  When you find them, email the address in the admin_email_address field to remind them it is time to change their password using KeePass or your required password manager using the required settings on the password generator.   Don’t forget to recheck to make sure this is done within the required timeframe (2 business days is quite reasonable).    Good luck, and good security!

During my time at Chain Reaction (now known as Chain Reaction Ecommerce, Inc.), I created conceptual design for several new major system components.   One of those elements is the CRE Loaded Forms and Survey System (FSS).  Now present in the 6.3 and 6.4 cart releases,  FSS suffers from a few serious defects in usability.

The most egregious problem is a lack of documentation.   This is complicated by an absence of  data checking and feedback features and sub-optimal work flow setup in what is, admittedly, a pretty immature product.   Still, there is a good deal of potential in this underwhelming initial deployment, if you know where to look.

Lets start with a quick overview of the system as seen from the Admin tool.  Within the new top level “Forms and Survey” menu, there are 4 options.  Those options are Form Builder, Post Manager, Configuration and Backup.  The configuration and backup functionality are fairly self explanatory.  The form builder is used to build forms and the post manager is used to view post results for various forms.  There are a few gotchas in there, chiefly due to the extension of the terminology to include the term “surveys”, but we’ll ignore those for now.

The form builder looks somewhat like a standard osCommerce like  category / object management page.  On the first page you see various Forms and Survey “Folders”.   Unlike other folder or category structures in the cart, this system does not support any descriptive text or meta tags.   Which makes providing any compelling reason for a visitor to navigate further rather difficult at best without using either the Content Director System , RCI object insertions or direct edits of the content template for the forms system.  Fortunately (if you can call it that), CDS is included on all distributions which include the Forms and Survey System.

Another oddity you will notice right away is that one mandatory folder already exists.  This is entitled the “System Folder” and it holds two subfolders which equate to specific cart locations – Account and Order.  Forms added here will appear during the Account Creation and Checkout (or Order Creation) processes and are of a special type – the “Survey”.  It seems that the difference between a “form” and a “survey” is that survey “questions” are rendered within an existing form, while forms are complete forms with their own set of form tags under at least some circumstances.  You can see this by viewing the create_account.php page which shows the inputs associated with the account survey.   The FSS inputs appear in the “Options” section after all others have been rendered but before the password input fields- as part of the “create_account” form, as you can see in a source view.  Its a rather clumsy addition as is, but does offer some additional capabilities without too much silliness visible to the customer.  The order form however, is not so nice.

Forms can also be seen using the fss_forms_detail.php page.   The order form url can be formed by adding “fss_forms_detail.php?fPath=1&forms_id=2″ after your B2B installation URL.    You’ll see two form inputs – test file upload and Please rate your experience.  Obviously, you won’t want each customer to be offered a chance to load up your storage with miscellaneous files in most cases.  So, be sure to turn this input off by toggling the status icon in the admin.  (FSS -> Forms Builder -> System Folder -> Order -> “test file upload” is the path to the control).

My next post on this will go into more detail about how to use the Forms Builder, and what capabilities are offered by the configuration values.  But, before we get into those, it would be helpful to get into the details of what HTML forms are and how they work.  Here are a few helpful resources:

HTML 4.01 Foms standards

HTML  5 Forms Standards

HTML Form Tutorial at w3Schools.com

An older, but more detailed tutorial at htmlgoodies.com

Based on these, and other resources, I’ll outline how to use FSS to build a complete form…

E-commerce web site setup can be quite a complex process.  It is quite easy to lose track of the fine details and fail to address them.  This was brought to my attention recently by a spate of Link Submission approval requests and a couple of contacts asking why I had failed to approve them.  The reason was simple – they had violated several of the basic rules of link exchange courtesy.

In most cases the back link to this site was simply not present.  In other cases, the back link was present, but the site linking back was not the same as the site for which a link was requested.   In most cases the site content was in no way relevant to the purposes of  or content on this website.   Many of these issues are common when link campaigns are being conducted by unscrupulous “SEO service” firms.  But, they can be equally common among inexperienced site operators new to  link exchanges or bona fide service providers who are just in too big a hurry to get links requests out.   While you can’t do much about the former, the latter offers some opportunity to do two things.  Acquire some relevant back links for your site, and avoiding wasting time on irrelevant garbage links.  Doing so requires that you go beyond simply adjusting the available configuration values in your Link Manager system and provide some informative language on the link system pages.  Let’s look at how that is done.

Like any other system in osCommerce, language files are stored in files which share the name of the systems root file, but are located in the includes/languages/ directory tree.  Huh?

Each osCommerce system has one or more pages associated with it.  Each page is generated by loading a file in your browser. That file is located in the folder which hold the top level of the shopping cart file set.  That folder is the shopping carts web root.  Thus, we refer to that file as a “root file”.

The root file loads a number of related files.  One of these is a “language file”.  Language files are PHP files which contain definitions for “constants”  or “defines”.    They are stored in folders located in a directory defined in the carts configuration file – usually “includes/languages/” relative to the cart root.  Those folders are named after the language used to create the definitions.  So, for the English language file of a cart located in we would look in /home/yourstore/public_html/includes/languages/english for a file with the same name as the file which generates the page we want to modify.

So, to modify the links submission page we will open the links_submit.php file found in this location into our editor.   We are going to do two things.  First, modify the text on the link submission page to give a bit of guidance about what types of links we will accept.  Next, modify the text of the email sent to the submitter to reinforce the stores policy on links.

The definition used for the pages main body text is ‘TEXT_MAIN’.  By default it contains the phrase “Please fill out the following form to submit your website.” and looks like this:  define(‘TEXT_MAIN’,'Please fill out the following form to submit your website.’);

How this is structured is important.  PHP needs to be able to tell what content is static, and which is to be “parsed” for further modifications.  It does this using the quotation marks.  So, including quotation marks requires a process called “escaping” which is best left to a PHP developer with good eyes and a knowledge of how this is done.  See the PHP website for details on constants and strings. For simplicities sake, we are going to do our modification while avoiding the use of quotation marks of any type – in order to avoid creating syntax errors.   So, we change it to the following:

define(‘TEXT_MAIN’, ‘Please fill out the following form to submit your website.
<br>Please note that we accept only RELEVANT links.  This means your site must
be related to building or operating an ecommerce, online shopping or web store
site – or providing education or services to those who are engaged in such
tasks.’);

This adds a bit of specific information about the types of links we want to collect and the sites from which we would prefer to be linked.

Next, we modify the email sent to the submitter.  This is found in the EMAIL_TEXT definition – which starts out looking like this:

define(‘EMAIL_TEXT’, ‘Your link has been successfully submitted at ‘ . STORE_NAME . ‘.
It will be added to our listing as soon as we approve it. You will
receive an email about the status of your submittal. If you have not
received it within the next 48 hours, please contact us before submitting
your link again.’ . “\n\n”);

We change ours to look like this:

define(‘EMAIL_TEXT’, ‘Your link has been successfully submitted at ‘ . STORE_NAME . ‘.
It will be added to our listing as soon as we approve it. You will
receive an email about the status of your submittal. If you have not
received it within the next 48 hours, please contact us before submitting
your link again.<br>Please be aware that we will not accept:
<ul>
<li>Irrelevant links of any type.</li>
<li>Relevantly placed links on or to link farms.</li>
<li>Bait and switch links of any type.</li>
</ul>
‘ . “\n\n”);

This reminds the submitter of our ground rules, and adds a few more details about what we will or won’t accept.

Finally, we modify the  TEXT_LINKS_HELP  definition which holds the help text and looks like this:

define(‘TEXT_LINKS_HELP’, ‘<b>Site Title:</b> A descriptive title for your website.<br><br><b>URL:</b> The absolute web address of your website, including the \’http://\’.<br><br><b>Category:</b> Most appropriate category under which your website falls.<br><br><b>Description:</b> A brief description of your website.<br><br><b>Image URL:</b> The absolute URL of the image you wish to submit, including the \’http://\’. This image will be displayed along with your website link.<br>Eg: http://your-domain.com/path/to/your/image.gif <br><br><b>Full Name:</b> Your full name.<br><br><b>Email:</b> Your email address. Please enter a valid email, as you will be notified via email.<br><br><b>Reciprocal Page:</b> The absolute URL of your links page, where a link to our website will be listed/displayed.<br>Eg: http://your-domain.com/path/to/your/links_page.php<br>This page must be located on your website and that page must be accessible from your front page.<br>’);

We modify it so it looks like this:

define(‘TEXT_LINKS_HELP’, ‘<b>Site Title:</b> A descriptive title for your website.<br><br><b>URL:</b> The absolute web address of your website, including the \’http://\’.<br><br><b>Category:</b> Most appropriate category under which your website falls.<br><br><b>Description:</b> A brief description of your website.<br><br><b>Image URL:</b> The absolute URL of the image you wish to submit, including the \’http://\’. This image will be displayed along with your website link.<br>Eg: http://your-domain.com/path/to/your/image.gif <br><br><b>Full Name:</b> Your full name.<br><br><b>Email:</b> Your email address. Please enter a valid email, as you will be notified via email.<br><br><b>Reciprocal Page:</b> The absolute URL of your links page, where a link to our website will be listed/displayed.<br>Eg: http://your-domain.com/path/to/your/links_page.php<br>This page must be located on your website and that page must be accessible from your front page.<br><br><b>Link Relevance:</b> Your link must be relevant to ecommerce or ecommerce education to be accepted.’);

Now that we have these modifications in place, we can expect some improvement in the percentage of submitted links which are mutually beneficial to us and the submitting web sites.   Note that this technique can also be applied to important pages such as the checkout process and account creation pages in order to  improve their usability.   Making similar changes in the other language file sets will help keep your cart well prepared to deal business in a multi-lingual environment.

As with most eCommerce specialists, we are looking closely at the new kid on the block, Magento.  Despite the availability of users manuals, I like to begin by just using it.  This is a good way to determine just  how user friendly a new application can be.

I decided to begin with an activity that I have found to be key in effective product management activities in just about every shop I have ever worked with – product  import and export.

This should provide a serious test of usability  that goes beyond the developers ability to generate a pretty layout on the page, as well as determining just how powerful the carts ability to support batch processing can be.

I started by looking at the carts import/export tool.  This didn’t take very long to locate,  being found quickly on the first level of the system menu in the cart admin.   The second level selections were profile and advanced profile, which seems to promise some flexibility and potential for expansion in this critical cart system.  Very good so far.

Selecting the Profile tool, I was presented with a searchable and filterable grid listing with configurable listing size and an “Add Profile” button.  The listing  included 6 pre-constructed profiles providing management for 3 data sets.  Customers, Products and Product Stocks.   This is one data object (customers) more than can be managed by an osCommerce cart with Easy Populate without any modification to the Magento cart – again, very good so far.

Having already created on test product, I started with a product export.  This is done by selecting a product related “profile” then selecting the “Run Profile” option from the menu on the left side of the admin screen.  Straight forward, and quickly accomplished.

I did however, skip evaluating the column headers other than a quick glance to assure they were there.  Doing this turned out to be a mistake.  More on that later.

My next step was to attempt an import of foreign product data.  I just happened to have a nifty little data set handy for just that test.  I popped back to the profile listing and hit the “Add New Profile” button to create an import profile to match my file structure.  This presented a 4 section page with the usual left menu and button panel at the right top of the main page.

The first set of  options required setting  a profile name, the type of entity involved, dataflow direction (import/export), a store id (everything left to default), a number of records (bit strange that), and a decimal separator.  This section can be seen in the image below:

Notice the “(Products will be added\updated to this store if  ‘store’ column is blank or missing in the import file)”  statement.  Again, more on this later…

The next section was rather obtuse.  Titled “File Information”  It contained a single drop down titled “Data Transfer” and containing two options – Interactive and “Local/Remote Server” .  I left this at “Interactive”.

The next section was titled “Data Format”.   The first element is a “Type” dropdown with selections including “MS Excel XML” and “CSV/Tab Separated”.  Toggling the selection from Excel XML to CSV/Tab Separated switches the initially presented  “Spreadsheet Name” input apparently used to select a single spreadsheet out of a workbook  for new inputs titled “Value Delimiter” and “Enclose Values in”   in a rather cute use of AJAX.  the final input is a dropdown of “Yes/No” options entitled “Original Magento Attribute names in first row.”

The final section of the page is the “Field Mapping” section.  It presents with a single button labeled “Add Field Mapping” :

On clicking the “Add Field Mapping Button” you’re presented with controls to add a “Field Mapping” entry.  This consists of a drop down labeled “In Database” and a text input box entitled “In File” along with a remove button.

The attribute selection dropdown contains an extensive selection of Magento product attributes (which refers to attributes of the product class or object rather than any specific aspect of a physical product as an experienced osCommerce user might expect).   I quickly setup a map outlining my file contents:

Short sweet and to the point.  Which it had better be.  Take too long and Magento’s AJAX admin will bite you in the butt by throwing you to the login screen, which will return you to the profile listing where you started with an “Invalid Post” error like this one:

Ah, the ability to make mistakes more quickly and waste time more obliviously – all thanks to Asynchronous JavaScript’s session fracture feature.  In general, I’m not impressed by AJAX.  This is one good reason why.

I then proceeded to attempt to upload this file.  Not so quick.  Turns out that when Magento say’s “Products will be added/updated to this store if ‘store’ column is blank or missing in the import file.” – they aren’t serious about that.  Really.   After a number of errors about missing “types” , attributes and so forth, I realized that if you expect to import your data you must include at least 4 extra columns in your import file which contains the store, website, attribute_set and type attributes.  For those running only a single store (I expect most users), the values of ‘default’, ‘base’, “Default’ and ‘simple” should work fine.  On export, the store attribute column contains the value “admin” – I ran into a report that using this on import would result in products not being visible in the store front until it had been changed.

Along the way, I also discovered that despite the complete absence of any data on required fields in this tool there are a surprising number of fields which are required before a product can be imported.  Not sure that “Short Description” belongs in that list, but its there.  The complete list, with legal values where applicable, is:

Name
Description
Short Description
SKU
Weight
Status (Enabled, Disabled)
Visibility (Catalog, Search)
qty
tax_class_id (None, Taxable Goods, Shipping)

I’m not sure if the import process can be carried out at the same time as  other administrative tasks or not.   I sure hope so.  It took the better part of 45 minutes to import a mere 1256 products.  What it was before a years worth of optimization work on the EAV based product management, I don’t want to know.  By way of comparison, this is at least 5 times as long as it takes to upload 5000 products with 50 more fields on a shared hosting account using Easy Populate on CRE Loaded.  Suffice to say, I plan to have a good book and a cup of coffee handy before attempting to  import 5000 to 10000 products – a catalog size  not uncommon on many sites.

Overall, I’m impressed with many aspects of the import / export tools provided by Magento.    That there is a unified framework for data flow speaks well for this shopping cart.  But, the user friendliness is a bit lacking.   In page documentation of the required fields is lacking, reports in the Varien forums indicates that it is also missing in the User Manual and the exact functionality of the user mapping is not entirely clear.    This appears to be focused entirely on column selection from within the local data set – more of a field listing than mapping – as there is no provision for matching foreign field names.  The main purpose of  this feature seems to be to allow import of files without column headers in place.  While I’m new to Magneto, my more than 25 years worth of experience with delimited files tells me that building such files  without column headers is like juggling hand grenades with loose pins.  You know its going to get ugly, its just a question of when.  The presence of misleading statements as to ability to set the default store and the absence of any required element guidance on the front end are major flaws in this system.  I was however, fairly impressed with the back end error handling.

Keep in mind, this system review is not intended to be a comprehensive critique.  It is shaped by a focus on usability for users new to the software, and limited by my restricting myself to searches of the Magento Knowledge Base, Wiki and Forums in order to obtain a view of the software more congruent with that large portion of such users who seem to never RTFM.  I hope that one or more of the available users guides will address these issues quite well, though comments in the dozens of forum threads containing hundreds of posts from frustrated users tend to indicate otherwise.

Look for more posts on Magento in the near future – many of them from the new user perspective and undertaken without review of available literature as I take a good luck at just how user friendly Magento can be – and survey some of the more common frustrations with the Varien shopping cart’s community variant prior to reviewing the available documentation…

The osCMax project recently released an updated version of osCMax which removes the File Manager and Define Languages tools due to unspecified security concerns.

Details can be found in the osCMax forums – http://www.oscmax.com/forums/announcement-discussions/20984-security-notice-oscmax-2-0-4-released.html and in the osCMax Blog – http://www.oscmax.com/node/341

Few details are available but this flaw may also affect CRE Loaded and other osCommerce derivatives…

As I write this, I am listening to a rather annoying and repetitive series of cutesy little beeps. Why? Because I’ve been reading an article I first found back in April of this year and keep meaning to review here. Its not very long, but it packs a good deal of punch and should be read by anyone looking to build a new site or reconstruct an older one.

The article is found at Search-Engine-Optimization-Help-Website-Spider-and-Visitor-Usability and is written by Ivan Strouchliak. He starts off with a small number of examples of how NOT to design sites. The examples are actual working websites that someone, somewhere expects to generate revenue. They are by no means amateur constructed sites for the most part. The list includes 3 apparently expensively produced FLASH websites.

The key mistakes they made include unusable navigation, site structure that is obtuse or worse, excessive use of color, effective but unfamiliar navigation user interface schemes and excessive use of slang vernacular.

Not an exhaustive list of crash landings – but not a bad group to start a good discussion of web usability with either. Ivan goes on to offer some good general advice on site optimization which may not be directly applicable to ecommerce sites using dynamic content management, but which should certainly be shaping development of such systems.

The key points are:

1. Use a widely accepted format for your website (Usually including navigation areas, header, content area and footer) and include contextual links in the content area.

This is important because familiarity breeds usability. A simple concept often ignored in the search for brand differentiation. Its also important in that most users focus their attention on the content. Why not? – it is what they are looking for after all.

2. Follow two simple rules of writing :
A. Use small coherent paragraphs
B. Use Headlines

These rules are important in that people rarely read every word on a page. They scan the page and read what is of interest to them. So breaking the content into readable chunks with attention drawing headlines can improve the rate at which a page captures the users attention.

3. Minimize use of Javascript and include it from separate files whenever possible. He rightly points out that CSS has improved enough to drastically lower the need for Javascript and that spiders can’t process it as well as text markup even though they have improved this capability.

4. Be consistent.

While bots see the page as code, human users get confused if the page structure changes too often and will bail from the site.

5. Make finding stuff easy by:

A. Keeping file size small.
B. Include an internal search engine
C. Provide a clear trail of information

He refers to this latter as “information scent” – a reference to the phenomenon of users following the trail of references relevant to the target of their search throughout a sites page content.

I think to me, it may be more important to keep the pages content area small and focused than to keep the file size itself small. Not that the latter is unimportant – but that keeping the content tightly focused on a specific set of associated keywords should generate a more effective search target AND keep the page size lower.

Ivan closes up with a warning about using flash websites. He cites continued difficulty in indexing by search engines and general poor usability as compelling reasons to avoid FLASH as a primary means of site construction – or perhaps at all.

Food for thought.

Recently, a security threat was discovered in Zen Cart.  Specifically, the forgotten password routine could be used to discover a limited amount of data on several pages within the admin.  The information disclosed was not much – but any is too much.  So they created a  fix, and like any good development team they distributed it to their users.   But they did not stop there.   Like any good neighbor, they started letting other developers know where the issue might affect their distributions.  Sure enough the issue is also present in other osCommerce variants and descended carts.   This includes CRE Loaded, osC Max and osCommerce with the Admin Access with Levels contribution installed.  The most recent osCommerce releases do not use Admin Access with Levels, but an alternative of their own.   Thus, they may not be prone to this issue.

Thanks to the Zen Cart teams sharing of this issue with other development groups, patches were generated and supplied to users of osC Max within 48 hours of notification.  EOS Online Merchant received a similarly rapid  repair, and a CRE Loaded patch which includes data to address this issue is expected to be released today.   This type of cooperation may not be essential to keeping eCommerce software safe from penetration, but it certainly helps.  I look forward to seeing further collaboration towards more secure software for online shopping in the future.

In his post on CRE Loaded Clutter , Chris at oshelpers.com describes FDMS as inessential clutter in the course of presenting what is essentially an explanation of why CRE Loaded 6.3 is so overpriced for the feature set.

I beg to differ on this specific point.

Perhaps, as the system designer responsible for FDMS and the Chief Operating Officer of the firm which sold the system I have a few biases of my own here.  Download related issues in CRE Loaded accounted for a respectable portion of system complaints before FDMS development.  The existing download system lacked some pretty obvious marketing tools and capabilities.  The reporting systems sucked.  Those issues were just about enough by themselves.  Add to them the negative impact of the “Zero Weight Guessing Game” in the checkout and shipping routines which affect 100% of all cart users and the development of  FDMS  and its eventual inclusion into the core distributions was completely justified.  The market demand was also more like 20% than the 0.2% Chris estimates off the cuff.    The system also made it a lot easier for shops with physical products to offer product related downloads such as instruction manuals, user guides and brochures  — pushing the number of potential benefactors even higher.  The list of reasons why FDMS is both essential and “A Good Thing” goes on and on.   Inessential is not justified here – though it is certainly fair to say the system is  over-priced when considered against other needs clammering for attention in the CRE Loaded code base.

CRE Loaded actually did a splendid job of selecting contributions for inclusion in the cart up to the 6.2 release.  In fact, it came very close to continuing that streak in the 6.2 release itself.  Ugly story there that I might tell someday, but not today. Fact remains that the top features in any CRE Loaded distribution can still be found in the top downloads of all time for osCommerce contributions and most of them remain in the top 50 if not the top 10 out of over 5000 candidates.

What Chris missed,  ignored  or chose not to  communicate there is that beginning with 6.2, CRE Loaded was no longer to be a “loading project” but a development project. Not a secret at all.  I certainly mentioned it in the CRE Loaded forums as I drove development in a new direction and I am pretty sure Chris was there to see it.    It was the right course then and a better one today.

The problem is that Chainreaction has an issue with steering a course that  calls on building a development company.  A problem with any course that relies on providing value to the community for which the community feels a need to pay.   The fact that so much clutter of any type remains is a reflection of this problem as much as anything.   That 107 of 114  feature requests made over the past 3 years remain open, many of them unanswered much less un-implemented is a clear sign of the weakness of Chainreaction Ecommerce ‘s  commitment to meet community needs.

Over the past week, Tom O’Neill has been hard at work getting EOS Online Merchant ready for its 0.53 Alpha release.

Part of that preparation includes deployment of an ongoing demonstration site at the new EOS Online Merchant website.  This demo site is actively being used for development, so expect features to be a bit fluid in not only quality, but quantity.  The EOS Online Merchant Catalog Demo can be found at http://demo.eosonliinemerchant and the Admin Demo can be found at http://demo.eosonlinemerchant.org/admin/ .   The catalog user access information is:  User ID – test1 and Password – test1 .

We’re withholding the Admin demo for a bit – as we will need to secure the more vulnerablel spots before allowing public access.  Interested developers can contact me for access.

This marks yet another early milestone in the continued development of the EOS Community.  Keep a weather eye on Source Forge for a new release sometime in the next two weeks.