Jump to content
Sign in to follow this  
johnnyrocket

Modular means "Modular", right?

Recommended Posts

This probably isn't the place to start this discussion, but it seems like more and more people (and companies) are being allowed to submit bad contributions as private contributors, just to lure osCommerce users into paying for their services. OsCommerce users aren't allowed to post fixes to these horrible "contributions", and all of us suffer.

 

For example, the contribution from "ItWebPros" for One page checkout is a total joke... They set you up to fail and ruin your code just so you have to call them to get it working and pay $300 just to fix their own damages. Their contribution is supposed to work with CCGV exclusively (not very MODULAR), and it doesn't.

 

Another example - CCGV on RC2 - If it's such a "great" contribution then why can't we get reasonable installation instructions from the poster for RC2a? The most current installation instructions have deliberate extra carriage returns in the text file, just to screw up your code when you copy and paste, again the poster will install it for a fee...

 

Every time I need to make a change to osCommerce I am stuck hunting down some little change from 5 years ago that doesn't work with other contribs and modules.

 

MODULAR programming means that the MODULE or CONTRIB will work on most installations with little to no changes to existing code. PLEASE only post professional, MODULAR contributions. If your contribution requires edits to core files you need to do your homework and change it PRIOR to posting it, as we all have come to expect this from osCommerce contributors.

 

OK, I've had my say... Please add yours!

Cheers!

 

JR

Share this post


Link to post
Share on other sites

I agree that there are some bad contribs out there, & if there are some abusing the system as you detail then perhaps u should use the 'report' system so that such practices can be stopped.

 

I would say that quite a few contribs have been messed up by poeples 'bad' fixes, they find a problem that is peculiar to them, don't bother to check the core code but post thier 'fix' which breaks for everyone else. I'm sure they're intensions were good anyway!

 

The answer is u must always research b4 applying anything to your site.


Sam

 

Remember, What you think I ment may not be what I thought I ment when I said it.

 

Contributions:

 

Auto Backup your Database, Easy way

 

Multi Images with Fancy Pop-ups, Easy way

 

Products in columns with multi buy etc etc

 

Disable any Category or Product, Easy way

 

Secure & Improve your account pages et al.

Share this post


Link to post
Share on other sites

If you find a 'broken' contribution and are able to fix it then do so and upload it. If the original contributor does not allow version upgrades or changes to be uploaded under the original contribution heading, make a new heading.

 

There are many contributions posted, some supported and some not but you have to keep in mind that ALL contributions are use at your own risk and if you are not qualified to make the changes to the contribution to correct problems then you can always ask for help OR find someone willing to do the work for you. YES, you may have to pay someone to do it but lets face it, paying someone else to do it is less costly then you going to school to be taught how to correct it.

 

 

Chris


:|: Was this post helpful ? Click the LIKE THIS button :|:

 

See my Profile to learn more about add ons, templates, support plans and custom coding (click here)

Share this post


Link to post
Share on other sites

A small tip might also be to not always use the latest uploaded version of a contribution....some contributions are messed up by layers upon layers of "bad" fixes.

 

In such a case go back and choose the latest version uploaded by the original poster and then proceed to do the install and eventual fixes based on that version instead.

Share this post


Link to post
Share on other sites

I see a lot of the old-hand programmers ignoring one of the basic premises in the opening post

 

I agree with Johnnyrocket that modular means modular - consider the use of so-called modules within the osC contrib environment and do a comparison with the plug-ins in the WordPress environment and you'll see what i mean.

 

Adding a plug-in in WordPress is an "upload all and click activate" process, then configure plug-in unique settings via the admin side of the site using a user interface page. Same applies with theme changes generally (pre-personal customisation and sidebar widgets addition).

 

It seems to me that here on osC, a contrib is not a contrib unless it requires extensive hacking of core code, non-auto-removal injection of database tables and rows, plus endless bug hunting and swapping out of deprecated commands.

 

My vote goes to the following steps -

 

In the contrib library -

- split the contribs library by earliest known supported osC version for each contrib

- when a contrib has a "major sub-version step to fit osC version XYZ" update, then that contrib version gets a new contrib library entry with lowest compatible version being the osC version it has just been updated to work with.

- when a new osC version (Beta or RC or final) is released and the contrib does not work with it, then the contrib page is annotated in the header to state that version ABC is the highest working osC version for this contrib version, and that development for higher osC versions has been forked to a new contrib at (link).

- if a developer wants to post a contrib (and as with one page checkout) state no free support is given, then the contrib library page must have a big red box warning of this condition, or a separate section in the contrib library for contribs demanding paid support.

 

In the contribs themselves -

- NUMBER ONE - as far as is possible, the target for any contrib should be that it is a drop-in module (copy files to folders and click go in admin) - study WordPress to see how they do it.

- contrib authors should re-examine all code before publishing it, and in particular,

- - language strings should have their own language file in includes/languages/languagename/modulename.php or be inserts to the includes/languages/languagename.php file - they should not have hardcoded language strings scattered throughout them.

- - The same applies to any constant values and image names/locations hardcoded instead of added through the language files.

- - User ID codes (e.g. payment service account or affiliate codes) should be insertable through the modules page in admin, not hardcoded in the module files with install instructions to edit them before install - the defaults in published code should always be NULL, not the contrib author's own affiliate codes etc.

 

There's probably a hundred further issues I could drag up, but underlying them all, I think, is the fact osC architecture is not designed for the same degree of user modification as other packages (not just WP, think Joomla, SMF forums et al) and osC's architecture in this respect is really showing its legacy and age. If I had one wish, it would be that osC 3.0 was focussed solely on bringing the contrib and theme modification architecture to the same level as those other open source packages. Forget everything else, including (dare I say it?) security upgrades etc - just get the contribs and theme systems up to date with the rest of the industry.

 

Gaz


Wearing a seatbelt prevents head injuries when the computer crashes - - - Yeah Right!!! - not in this office.

Share this post


Link to post
Share on other sites

Some nice ideas, but your asking for a lot more work from the contributer and more code, therefore slowing osc down, the advantage of code thats integrated closly with the core is speed of operation, do you prefer to have an easier install at the cost of loss of performance?

 

Before you rush to dictate these ideals to those providing contribs, it would be nice to see a contrib from you that conforms to them!


Sam

 

Remember, What you think I ment may not be what I thought I ment when I said it.

 

Contributions:

 

Auto Backup your Database, Easy way

 

Multi Images with Fancy Pop-ups, Easy way

 

Products in columns with multi buy etc etc

 

Disable any Category or Product, Easy way

 

Secure & Improve your account pages et al.

Share this post


Link to post
Share on other sites

Sam - I disagree in two directions ....

 

My suggestions / wish list for the contrib library is both simple to implement (but would be tedious to enforce) and logical. In fact it would make life simpler for everyone - core devs, contrib devs, and contrib users. The prime workload would be on splitting out existing contribs and separating the existing uploads to be osC version specific. If you think of "monster" contribs like SPPC or CCGV that have evolved over 6+ years and covered half a dozen or more osC versions, then that illustrates both the splitting task difficulty and emphasises the absolute necessity for doing it.

 

As to the contribs themselves - I'm assuming you mean by "slow down" that you're referring to how the site actually performs, rather than the speed of development. In terms of the former (site speed) then seggregating contrib modules and using INCLUDE calls would have a minimal performance effect unless the contribs themselves were over-heavy in database calls or constructed as bloatware. If you mean the latter (speed of core & contrib development) then I assure you you are wrong, as the other softwares prove daily.

 

In fact, the WordPress plug-in system actually speeds development because the devs focus on their own product and their XML install file simply inserts a call to their plug-in at the correct point of the core code. This encourages the careful development of custom functions within the plugin files (usually in a /pluginname/functions.php file) and greatly reduces both conflicts and the time needed to identify and debug them. Just browse any of the osC forums and you'll see that "contrib conflict" is a major and repetitive get-out-of-jail-free card played by many contrib devs. That occurs far, far less in WP and the other softwares.

 

Burt

 

I don't think it's being unfair. osC RC1 is 2 years old this month and is a nightmare to upgrade to RC2 or RC2a for non-programmers like myself with multiple sites out there. Both WordPress and SMF forums are one-click upgrades even between major version numbers - it took one click and 45 seconds of twiddling my thumbs to upgrade from SMF 1.1.8 to SMF 2.0 and that was a huge core code and database upgrade. It takes even less with WP upgrades since v2.7.0

 

I've looked and looked at the diff files for an RC1 to RC2 to RC2a upgrade, and even though I can hack and tweak with the best of them, I'm not even going to attempt those core changes on any of my sites - it took me long enough to get them all running smoothly, and one site in particular has well over 100 contribs hacked into it, plus countless tweaks from myself.

 

If those 100+ contribs were all genuine modules, then it would be a few clicks and a few minutes -

step 1 - click box to de-activate all plug-ins

step 2 - click button to run core & database upgrade

step 3 - tick boxes for plug-ins to reactivate, and click button to reactivate them

step 4 - view site and confirm all's well, then write a blog post to tell everyone how easy it all was.

 

That's the type of architecture that's leaving osC in the dust.

Whole new web-based provide & host services have sprung up in the last 2 years based on providing exactly that for modified osC auto-installs (e.g. EKM PowerShops)

 

Core dev needs desperately to catch up with the rest of the industry if osC hopes to maintain the user growth momentum of the last few years. As much as I like osC and enjoy tinkering with it (anything to avoid real work - right?) pretty soon someone will likely launch an alternative of the type I describe, also open source and free, and watch the user base dissolve then.

 

I speak direct because I care. I LIKE osC, but it's time to get it out of short pants and make it less geeky, and give it the fancy duds so it can go disco-ing like the cool big kids.

 

Gaz


Wearing a seatbelt prevents head injuries when the computer crashes - - - Yeah Right!!! - not in this office.

Share this post


Link to post
Share on other sites

It's worth noting that blogs and forums are simpler beasts than a shopping cart, a blog almost strictly so.

 

A blog has posts; a cart has products. Equal.

Products have prices; posts don't. Cart.

Prices can be with tax or without tax. Cart.

Both blogs and carts have categories. Equal.

A blog has comments; a cart has reviews. Equal.

Reviews have star ratings; comments don't. Cart.

Both have search and browse. Equal.

Both have registration and login. Equal.

Users put products in their carts; no blog equivalent. Cart.

Checkout. Cart.

Interaction with external shippers and payment processors. Cart.

Both are multilingual. Equal.

Carts are multi-currency. Cart.

 

No matter what system of contribution/addon/plugin install you have, I don't think that there is an automated solution for someone who wants to install all of Separate Price Per Customer, Quantity Price Break, Options Price Update, Actual Attribute Price, and MSRP. The fundamental problem is that they all want the same piece of real estate and they want to do incompatible things to it. For example, when you change the selected attribute, should the Options Price Update change the MSRP as well as the regular price? I'm not even sure that it's meaningful to mix Options Price Update with Actual Attribute Price.

 

As a project, osCommerce could do a better job of internal modularity. It's easy to see that just contrasting 2.2 RC2a with 3.0a5. The latter is much improved, although it could be better. For example, getPriceFormated (sic) should not live in Product but outside it somewhere that is easily overridden. Otherwise, every one of the previous contributions will be in there modifying that single function in Product. Not to mention possible template issues.

 

In terms of managing contributions, it's true that the addons area could be a lot better. Ratings for contribution (both functionally and for ease of install); tagging of contribution versions (rc2a compatible, code merge required, update package, specific solution, not multilingual); better handling of contribution forking and merging; so on and so forth. I don't favor mandates though; I favor increasing information. If people don't want to install contributions that don't come with step by step install instructions, then they shouldn't do so. I still prefer whole files, because it is easier for me to diff them than it is to diff an instruction from a text file.


Always back up before making changes.

Share this post


Link to post
Share on other sites
It's worth noting that blogs and forums are simpler beasts than a shopping cart, a blog almost strictly so.

 

A blog has posts; a cart has products. Equal.

Products have prices; posts don't. Cart.

Prices can be with tax or without tax. Cart.

Both blogs and carts have categories. Equal.

A blog has comments; a cart has reviews. Equal.

Reviews have star ratings; comments don't. Cart.

Both have search and browse. Equal.

Both have registration and login. Equal.

Users put products in their carts; no blog equivalent. Cart.

Checkout. Cart.

Interaction with external shippers and payment processors. Cart.

Both are multilingual. Equal.

Carts are multi-currency. Cart.

 

No matter what system of contribution/addon/plugin install you have, I don't think that there is an automated solution for someone who wants to install all of Separate Price Per Customer, Quantity Price Break, Options Price Update, Actual Attribute Price, and MSRP. The fundamental problem is that they all want the same piece of real estate and they want to do incompatible things to it. For example, when you change the selected attribute, should the Options Price Update change the MSRP as well as the regular price? I'm not even sure that it's meaningful to mix Options Price Update with Actual Attribute Price.

 

As a project, osCommerce could do a better job of internal modularity. It's easy to see that just contrasting 2.2 RC2a with 3.0a5. The latter is much improved, although it could be better. For example, getPriceFormated (sic) should not live in Product but outside it somewhere that is easily overridden. Otherwise, every one of the previous contributions will be in there modifying that single function in Product. Not to mention possible template issues.

 

In terms of managing contributions, it's true that the addons area could be a lot better. Ratings for contribution (both functionally and for ease of install); tagging of contribution versions (rc2a compatible, code merge required, update package, specific solution, not multilingual); better handling of contribution forking and merging; so on and so forth. I don't favor mandates though; I favor increasing information. If people don't want to install contributions that don't come with step by step install instructions, then they shouldn't do so. I still prefer whole files, because it is easier for me to diff them than it is to diff an instruction from a text file.

 

Mi Matt

 

Good reply and good points, couldn't agree more with you.

 

The only problem ... it is a dream and always will be a dream. This is the "OSCOMMERCE" forum.

Share this post


Link to post
Share on other sites
It's worth noting that blogs and forums are simpler beasts than a shopping cart, a blog almost strictly so.

 

A blog has posts; a cart has products. Equal.

Products have prices; posts don't. Cart.

Prices can be with tax or without tax. Cart.

Both blogs and carts have categories. Equal.

A blog has comments; a cart has reviews. Equal.

Reviews have star ratings; comments don't. Cart.

Both have search and browse. Equal.

Both have registration and login. Equal.

Users put products in their carts; no blog equivalent. Cart.

Checkout. Cart.

Interaction with external shippers and payment processors. Cart.

Both are multilingual. Equal.

Carts are multi-currency. Cart.

 

Errr - not quite

 

A blog has posts, and comments, and threaded replies, and threaded discussions, and pingbacks, and trackbacks, and many of the functions of a wordprocessor and DTP package, including all of the html available to osCommerce product descriptions, and a whole lot more besides.

 

Products have prices ... yup, as demonstrated by several full featured shopping carts that are simply copy-and-activate plug-ins to WordPress. osC itself is also just a plug-in for Joomla! within the CMS structure of that package.

 

In addition to categories, blogs also have tags and authors and editors and contributors and a host of other post/product taxonomic data that does not exist in carts - this balances out the cart's tax and products-into-cart functions.

Additionally, whilst osC reviews can have star ratings, so can blog posts (and comments, and even the images - all rated independently of each other within a single post or page entry) it just needs the plug-in to be uploaded and activated - there's around 20 or so different ones, each with a slightly different focus or style, to choose from.

 

The cart's checkout system is undoubtedly the biggest coding difference between a blog and a cart, however, consider the massively multi-user "product creation" functions native within most blogging softwares - from basic commenter, to contributor, to author, to editor to admin (using WordPress heirarchy) as opposed to the single admin native to osCommerce. Blogs win therefore on organisation scalability. On this topic, WP comes in two flavours - single blog version, and WP-MU which is massively multi-blog management within a single install. osC has the Multiple Stores from single install contribution (it's a monster to install and highly unstable when adding further contribs in my experience) therefore why not target osC 3.x to release in two variants the same as WP - single store and multi-store - until they do, WP is way ahead of osC or Zen or any other cart system on that one.

 

External shippers and payment processors - see the comments above about the cart plugins for WP and other blogs = identical functionality but in a drag and play plug-in. Equal ranking therefore, though the plug-in system of WP actually keeps it ahead of osC on this one, due to the ease of 1-click upgrading when (for instance Google Checkout) a payment processor makes radical changes to their API or terms of service and the plug-in author upgrades the plug-in's code, but not every blog script is as advanced as WP.

 

Blog plug-in carts are multi-currency too, and via a plug-in, all monetary value mentions in any WP post or comment or page can also be made fully and automatically multi-currency - polling the reader's IP address to get their country and auto-converting to the local currency of that IP address with exchange rates pulled from the likes of XE.com and other servers via a cached currency chart (timing of which is usually schedulable via WP-cron or server-cron, including multiple times per day). Currently this is a drag and drop plug-in for WP, but not for osC, and even the contribs that are available, have to be merge-installed to get the same full functionality, even then they only work on catalog product's prices, not the prices quoted in text from the language files (e.g. a shipping insurance compensation narrative in /shipping.php). Blogs win emphatically on that one.

 

No matter what system of contribution/addon/plugin install you have, I don't think that there is an automated solution for someone who wants to install all of Separate Price Per Customer, Quantity Price Break, Options Price Update, Actual Attribute Price, and MSRP.

 

For WordPress it's a drop and play plug-in called "eShop" - and it can be used for both digital and tangible goods, supports PayPal style processors as well as the online direct card processing services and merchant services.

 

The fundamental problem is that they all want the same piece of real estate and they want to do incompatible things to it. For example, when you change the selected attribute, should the Options Price Update change the MSRP as well as the regular price? I'm not even sure that it's meaningful to mix Options Price Update with Actual Attribute Price.

 

See? That's part of the problem - you're approaching it as a programmer, not as a retailer or wholesaler. Options are exactly that - options! They are either free, or cost extra. That's all a customer wants to know on the pricing front. Therefore code it as "this extra stuff costs this much to add it into the bundle" - anyone doing more than that is just making life to difficult for the buying customer and they'll click off to where it's easier to buy.

 

As a project, osCommerce could do a better job of internal modularity. It's easy to see that just contrasting 2.2 RC2a with 3.0a5. The latter is much improved, although it could be better. For example, getPriceFormated (sic) should not live in Product but outside it somewhere that is easily overridden. Otherwise, every one of the previous contributions will be in there modifying that single function in Product. Not to mention possible template issues.

 

Hmmm ... OK - to me "getPriceFormatted" should be stored in the customer table, and based on their country (comma or period between currency unit and cents? etc.) which will yield the correct currency symbol ($ etc) and whether it should be to the left or right of the actual value. All this should be pulled either from the countries database, or from a flat file that can be edited within the admin interface (sayyyy ... would that make it a .... module ... by any chance?).

 

In terms of managing contributions, it's true that the addons area could be a lot better. Ratings for contribution (both functionally and for ease of install); tagging of contribution versions (rc2a compatible, code merge required, update package, specific solution, not multilingual); better handling of contribution forking and merging; so on and so forth. I don't favor mandates though; I favor increasing information. If people don't want to install contributions that don't come with step by step install instructions, then they shouldn't do so. I still prefer whole files, because it is easier for me to diff them than it is to diff an instruction from a text file.

 

Horses for courses - I've never been able to get to grips with diffs - gimme a set of text install steps and the code to copy over. Of course, that easily deprecates in favour of a real drop-and-go modular plug-in system like WordPress's

 

;)

 

Gaz


Wearing a seatbelt prevents head injuries when the computer crashes - - - Yeah Right!!! - not in this office.

Share this post


Link to post
Share on other sites
A blog has posts, and comments, and threaded replies, and threaded discussions, and pingbacks, and trackbacks, and many of the functions of a wordprocessor and DTP package, including all of the html available to osCommerce product descriptions, and a whole lot more besides.
Do you have an example of HTML that is not available in osCommerce but is available in a blog? Admittedly, the default Wordpress textarea for posts is better than the default osCommerce textarea for product descriptions.

 

Does Wordpress do threaded replies and discussions by default? Or is that a plugin? I can come up with examples of carts that have that. For example, look at Amazon.

In addition to categories, blogs also have tags and authors and editors and contributors and a host of other post/product taxonomic data that does not exist in carts - this balances out the cart's tax and products-into-cart functions.
Carts can have tags (not sure if osCommerce has a contribution for this or not), again look at Amazon. Product Attributes in osCommerce have much of the same behavior characteristics as a tag (multiple ones can be assigned to a specific product and several products can have the same options). Products can have third party merchants (equivalent to authors), look at Amazon or several contributions for osCommerce.

 

I'm also not convinced that any of this is notionally as complex as a tax rate. For example, can an admin only edit a comment when the commenter is from location A, the author is from location B, and the post has a particular tag? Do you have to determine if the edit permission applies before shipping and coupons or after?

Additionally, whilst osC reviews can have star ratings, so can blog posts (and comments, and even the images - all rated independently of each other within a single post or page entry) it just needs the plug-in to be uploaded and activated - there's around 20 or so different ones, each with a slightly different focus or style, to choose from.
What happens if someone wants two pieces of functionality, one of which exists in one plugin and one which exists in a different plugin? I suspect that the answer is that if the two plugins cover the same area, you need to choose between them or write a new plugin. With the installation method used in osCommerce, you could integrate them and get both pieces of functionality. Part of my point is that I think that you will find that this issue (addon conflict) is more likely to be important with osCommerce than with a blog. Far more people need both pieces of functionality.
The cart's checkout system is undoubtedly the biggest coding difference between a blog and a cart, however, consider the massively multi-user "product creation" functions native within most blogging softwares - from basic commenter, to contributor, to author, to editor to admin (using WordPress heirarchy) as opposed to the single admin native to osCommerce. Blogs win therefore on organisation scalability. On this topic, WP comes in two flavours - single blog version, and WP-MU which is massively multi-blog management within a single install. osC has the Multiple Stores from single install contribution (it's a monster to install and highly unstable when adding further contribs in my experience) therefore why not target osC 3.x to release in two variants the same as WP - single store and multi-store - until they do, WP is way ahead of osC or Zen or any other cart system on that one.
osCommerce actually has several contributions for this. Each does slightly different things. Taking a quick look at WP-MU, it looks like it allows for multiple blogs to run on the same software, with shared users but separate roles (i.e. you login the same at two blogs but can do different things at each).
External shippers and payment processors - see the comments above about the cart plugins for WP and other blogs = identical functionality but in a drag and play plug-in. Equal ranking therefore, though the plug-in system of WP actually keeps it ahead of osC on this one, due to the ease of 1-click upgrading when (for instance Google Checkout) a payment processor makes radical changes to their API or terms of service and the plug-in author upgrades the plug-in's code, but not every blog script is as advanced as WP.
It's possible that osCommerce could implement one click installation of the various modules (payment, shipping, and order total). It's almost there now. Historically what people have had to do themselves has been to copy the files over. This could be automated to include the file download and putting them in the proper places. The upgrade system could also be improved (currently you may have to uninstall and reinstall).

 

Also, according to the eShop forum, Google Checkout is not available for eShop, because eShop does not support SSL. This may not be the best example to establish your point...

For WordPress it's a drop and play plug-in called "eShop" - and it can be used for both digital and tangible goods, supports PayPal style processors as well as the online direct card processing services and merchant services.
And does it have over six thousand contributions adding additional features? I think that what you'll find is that the eShop would give you most of what you want but when it fails, it will be difficult to add functionality. The impression that I get is that you can't add plugins to eShop. You can only get the eShop author to add new functionality. At least googling for eShop payment processors and eShop plugin did not find a list of payment processors that could be installed in eShop via one click plugin installation.

 

This is also somewhat away from the point. There is a contribution to embed Wordpress in osCommerce. Do we credit osCommerce with every capability of Wordpress?

Hmmm ... OK - to me "getPriceFormatted" should be stored in the customer table, and based on their country (comma or period between currency unit and cents? etc.) which will yield the correct currency symbol ($ etc) and whether it should be to the left or right of the actual value. All this should be pulled either from the countries database, or from a flat file that can be edited within the admin interface (sayyyy ... would that make it a .... module ... by any chance?).
In the customer table? So, for each product, you have to add a new *column* in the customer table? That doesn't seem scalable. Perhaps you meant that the currency preference should be stored in the customer's table? I'm not sure that there's enough information in a currency to justify a whole module. It's basically five pieces of information that you can enter into a single form. Or run one line of SQL. It would not be difficult to automate this into a plug in module.

 

The function getPriceFormated (sic) outputs the actual price plus the special's price (if present) in the correct way (including HTML) for the customer's currency, including or not including tax as per the configuration. It is based on the product and will give the same result for the same product and different results for different products. It is not stored in a table but calculated from various pieces of data (product, specials, tax rate, currency, etc.). My point was that this should be split off from product, as people will want to override the default behavior. When they override, they should not have to change the product file, as they only want to change one function. Further, this function is display related and may change without any changes in the product row in the database (for example, specials are in their own table).

 

I was agreeing with you here. This is a place where osCommerce could be more modular and therefore easier to override but isn't. However, contrast that with the ease of adding a textarea product attribute contribution. That would be a simple drop in of a single file. If there was an automated contribution loader, you could use it on most product attribute contributions (not on file upload attributes, because there is currently no place to automatically hook in the upload processing functionality).

 

My major point is that it is easier for a blog to integrate plugins because a blog is an inherently more basic concept. A comment is linked to a post but comment behavior does not change from post to post. You can add a ratings system to your comments because it's easy to separate the ratings from any other information that you might want to attach to comments. Adding functionality is easy. The difficult part comes when you want to modify functionality. I suspect that Wordpress handles this well for the first modification but has trouble with the second modification. This may not impact you much, if you rarely need to make modifications in the same place twice. However, with a cart, modifications tend to cluster in certain places and shops have very individual needs. One store may never use specials, so that functionality can be hacked out (as many templates do). Another store may need specials and MSRP and Quantity Price Breaks. Here's a question, does the quantity price break apply to the special price? Or is it an either/or situation? Two different stores may answer that question differently.

 

The big advantage of osCommerce is the ability to customize it. Two osCommerce stores can have very different behavior. We should not make changes that restrict this. We should make changes to make addon installation easier, especially for the common case, installing on a new store. We should work to make the team better aware of places where osCommerce should be more modular (like creating a FormattedPrice class that can be overridden separately from the product, currency, and tax rate classes).

 

We will not always succeed in doing those things. For example, the File Upload contribution has always been more developer friendly than store owner friendly. However, would it have been better for me to have waited before contributing it? A contribution with a clumsy install is still better than no contribution at all. Contrast that with the case of a payment module that I wrote but never contributed. It was only minimally tested (worked on the store where it was installed) and needed some care and improvement. Apparently I never got around to contributing it (as I can't find it). Someone else has presumably written another version, when they could have just improved mine. If I had waited to contribute until the File Upload contribution was perfect, there might not have been an Options Types V2 contribution. At the very least, Zappo would have had to do more work to get it up and running.


Always back up before making changes.

Share this post


Link to post
Share on other sites

I thought of another way of looking at the relative complexities of a blog and a cart. WordPress uses ten database tables. It stores both tags and categories in the same table. It can do this because there is no real difference in WordPress in how tags relate to each other or relate to categories. You can think of a tag as a special kind of category that displays differently. By contrast, in osCommerce, a manufacturer is not just a special kind of product attribute. A manufacturer has information (e.g. URL) that an attribute does not have. Likewise, an attribute has information (e.g. price offset) that a manufacturer does not have. Categories don't need any of that information. This forces osCommerce to use different tables for relating products to categories, manufacturers, and attributes. As a result, osCommerce (2.2 RC2a) has forty-seven tables (I believe that 3.0 has more).

 

A blog is conceptually simpler than a cart. It has fewer relationships among the data that it stores. This makes it easier to add relationships, as there are fewer old relationships with which they can conflict.

 

WordPress implements this well. It is absolutely true that WordPress is more modular than osCommerce (particularly 2.2 and older, but still true of 3.0). I'm not as convinced that WordPress plus eShop is more modular for e-commerce tasks than is osCommerce.

 

I want to reiterate that I think that this is an area where osCommerce both can and will do better in the future. The 3.0 series is much better than the 2.2 series at this. Parts of osCommerce (in particular, payment, shipping, and order total modules) are already most way there to what you want (you still have to move files manually). New areas are being added for 3.0 (in particular, drop in handling of new product option types).


Always back up before making changes.

Share this post


Link to post
Share on other sites

I think we both agree that osCommerce needs to have some dedicated time applied to modularisation.

 

My original intent in replying was not to try elevating one software over another, but to illustrate examples from how other packages are doing modular expansion. As I said, I like osCommerce - I like its flexibility and expandability, and that generally speaking, the core files system and conventions are very logical once you've had a little time to explore them.

 

It is the routine upgrades that are a real bind - whether it is actually the effort required, or the way the scope of the changes is presented, I'm not sure, but I've not upgraded any of my sites from RC1 to RC2 because the amount of work implied is simply too much.

 

Then there is also the effect of core upgrades in relation to "monster mods" - CCGV / CCGV(Trad) especially springs to mind. CCGV v5.20 was apparently the last stable version and that worked with osC 2.2 MS2. Since that version, the forums are full of howls of agony from users unable to complete installation into an RC1/2 install. The developers for CCGV(Trad) have emphatically refused to attempt a port of their version for any RC osC version and have repeatedly stated they will wait for the final osC release - that leaves everyone who downloaded osC from osC.com between mid 2007 to present and into the future, unable to use either CCGV version.

 

CCGV is not the only "monster mod" with this issue, SPPC appears to have revolving issues according to the forums. When I read the latest queries from the threads related to SPPC and other price tiering modules, I get the impression that osC's architecture is designed to stop such modules from operating successfully - however, I also blame the contrib authors in part - each time a fix or improvement is uploaded, they RARELY state which osC version it applies to and I suspect too many support seekers are simply downloading a package that looks as if it's for their osC version, but isn't, because the contrib uploaders did not include enough versioning information.

 

osC core teams and the osC website are to some extent also guilty in this - there is a general dearth of info about the core code differences between the older MS2 and current RC series - what I'm referring to is for the "little changes" such as the one that killed off so many mods in the MS2.2 to RC1 switch in the overall checkout/payment/shipping core code files. I lost count of how many wasted hours were spent trying to add a mod, discovering the install location had code changes, and then having to rip out progress so far and look for a different contrib to do the same job because the one I wanted was no longer compatible with an RC osC.

 

This then of course comes back to the old argument of should RC versions of osC be the prime distribution file set?

 

Like many others, I believe that in July 2007, Harald & Co made a major blunder by removing MS2.2 as the primary download and replacing it with RC1. They should have offered the two alongside each other, offering MS2.2 as the stable version, and RC1 then RC2 as the latest public availability of the development version. Had they done that, my sites would have been on MS2.2 and CCGV and SPPC would be installed and running, instead of missing, and I would not be having to run separate sites for wholesale & distribution customers instead of having them integrated under one site with the retail interface.

 

Unfortunately, my sites were originally installed (basic install and setup) by someone else, who simply grabbed the offered download version from osC.com and ran the install without checking version number. The version number also did not become significant until a couple of months of site development and product populating work had been done, then it was too late to revert. I suspect many webmasters new to osC have found themselves in that position.

 

The summary point is that there needs to be a better system for completing core code upgrades, or at the very least a better way of presenting the upgrade instructions, such that they don't inhibit users from upgrading.

 

I also believe that (as with RC1 and RC2 for example) when core devs decide a major function like checkout needs a major operating code rework, that the core devs put out a consultation call to the contrib devs whose offerings rely heavily on the then current operation system for the section to be upgraded - dare I say IPN & API call back functions from payment processors + CCGV + the completely reworked checkout_process.php between MS2.2 and RC1 and RC2?

 

Gaz


Wearing a seatbelt prevents head injuries when the computer crashes - - - Yeah Right!!! - not in this office.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×