Thinking about fixes and enhancements

[MrPhil]

I have been looking at osCommerce and have a number of areas where I think it could be improved. I've done some work, but before I commit a lot more time and energy in going further, I'd like to bounce the following ideas off of all of you. Maybe some (or all) of these line items already exist somewhere, or are already in the works for an upcoming release, or maybe they're new to all of you. I've done some of the following work already, and would be happy to turn the code over to the developers for inclusion in the the next 2.2 and 3 releases.

 

 

Part I -- CLEANUP:

 

1. Update LEFT JOINs for MySQL version 5. This means putting parentheses around multiple table names on the left side, because JOIN is now higher precedence than the comma (,) operator:

 

osC code t1 n1, t2 n2 LEFT JOIN...

in MySQL 4 is (t1 n1, t2 n2) LEFT JOIN...

but in MySQL 5 is t1 n1, (t2 n2 LEFT JOIN...

 

Therefore, t1 n1 [, t2 n2]... lists must be surrounded with () as in the second line. I think this is needed in a half dozen or so places. Can anyone confirm that this is backward compatible with MySQL 4, so no different runtime versions are needed?

 

2. CAPITALIZE SQL keywords and split up lines for readability:

 

$result = mysql_query(

"SELECT field1,

field2

FROM " . TABLE_NAME . "

WHERE condition

ORDER BY field2");

 

not

 

$result = mysql_query("select field1, field2 from " . TABLE_NAME . " where conditon order by field2");

 

This makes it SO much easier to read, edit, and autocompare (fc, diff) files!

 

3. INSERT INTO missing the field list in several places. It's always good practice to explicitly list the fields involved, in case there are any changes to the schema.

 

4. In general, split up excessively long lines of code to make files easier to read, compare, and edit (keep lines under 80 long). At least do this while hitting other changes, if not as a project in and of itself.

 

5. Copyrights have been botched during edits. The proper, legal, format is first_year, last_year OR first_year - last_year. Some people editing code have put in only the latest year, which is wrong and may weaken the copyright. I also see that the footer.php just gives the current year as the copyright date -- that's wrong, it should be first year - current or last year (should this be on a per-page basis?).

 

6. Check where the code asks for directory permissions of 777. First, it's very dangerous to give the whole world write access to your files. Second, unless PHP is running as "other", you can usually be more restrictive. Third, many hosting services forbid 777 directories (755 is the normal permission). Investigate this, and if necessary give the installer the ability to specify the needed permissions. Also, is there a good reason that configure.php must be Read-Only (444) rather than 644? It's a nuisance, and who is going to write to it other than the webmaster?

 

7. Does unset() return a value? In some places it looks like you have a function returning a value (tep_session_unregister()) that simply ends with unset().

 

8. It looks like RC1 has removed the need for register global variables. Are there any other places that need to be hit for PHP 5 compatibility?

 

9. There are still many places with hardcoded file names that should be changed to defined strings. It looks like some people just got lazy while editing the code and never bothered to use (or create) the central filename definition strings.

 

10. There are several places in SQL statements where reserved keywords are used for field names (e.g., "text"). Could this possibly cause any subtle trouble? Should we wrap all field names in backticks `text`?

 

11. <? opening short tags should be changed to <?php to avoid confusing XML processors, etc.

 

12. Changes per osC forum, e.g., 7/6/2007 admin/products_attributes default values addition. There probably have been more such changes that I haven't been following.

 

13. The HTML is not completely W3C compliant. I would suggest changing over to XHTML Transitional anyway, which means that all tag attributes must have values (SELECTED --> selected="selected", etc. for nowrap, readonly, checked, and multiple). Tags and attributes must be lower case (<SELECT... --> <select...). Tag attributes must be in quotes (colspan=3 --> colspan="3"). For XHTML, all tags must be closed ( />, such as for <img ... />, or </tagname>, such as </li>). This may not be compatible with HTML (I think the validator rejects <br />). If there are only a few places where close tags cause a problem with HTML (<br />, <hr />, <img />?) perhaps define() different versions and let the user select HTML or XHTML (see below on page layout customization). Finally, images (<img>) should have both alt= and title= attributes, alt for screenreaders, and title to fix a stupid IE misdesign.

 

14. Is <nowrap> a legitimate HTML tag? It's used in admin/includes/functions/html_graphs.php

 

15. Lots and lots of spelling and grammatical errors to fix (in English. I have no idea how good the German and Spanish are). By the way, are visitors allowed to pick which language they want, or is it fixed by the installer?

 

16. Breadcrumbs and other links: a page should NEVER have an active link to itself. Users get very confused when clicking on such a link and nothing appears to happen. The exception is if the page layout will noticeably change on the next load.

 

17. Many payment systems appear to have someone's affiliate code in them. Is it the determination of osC that this is acceptable (to, in effect, pay one person for the code they provided)?

[MrPhil]

I have been looking at osCommerce and have a number of areas where I think it could be improved. I've done some work, but before I commit a lot more time and energy in going further, I'd like to bounce the following ideas off of all of you. Maybe some (or all) of these line items already exist somewhere, or are already in the works for an upcoming release, or maybe they're new to all of you. I've done some of the following work already, and would be happy to turn the code over to the developers for inclusion in the the next 2.2 and 3 releases.

 

 

Part II -- IMPROVEMENTS AND ENHANCEMENTS:

 

1. Pull common page-top and page-bottom code into include files, to reduce file size and make common changes (such as XHTML DOCTYPE) easier to do. It looks like admin and non-admin will have to have separate includes.

 

2. A "merchant ID" in product information, so that multiple sellers could share a common store (each with limited admin permissions to work only with their own merchandise). These sellers would often be selling on commission, so there could be a mechanism for totaling up sales by different sellers or substores for the purpose of determining commissions to be paid.

 

3. Possibly a separate "department ID" or "store ID" in product information, so that different page formats could be set up for different merchandise (e.g., a children's clothing section and a lawn & garden section might have different colors and decorative images). The top level product category might be borrowed for this purpose, but page layouts would need to change.

 

4. Make it easy to bypass the current sales tax mechanism. For example, in New York state, I have to collect sales tax based not on where I am, but on the shipping address of the buyer! So, I need to pass the shipping address to a module which tells me the various tax rates in effect for different classes of merchandise. Other states could be as complicated. Anyway, the need exists to get the shipping address before calculating the totals, and to subtotal various classes of merchandise (as well as S&H) for which different rates apply. If there's a reasonable way to bend the current tax layout to do this, I'd appreciate hearing about it!

 

5. Much more flexibility in how a page is laid out. I want to blend in the store with the rest of my existing Web site, and not have to fight with osC to get it "almost right". Basically, the "left" and "right" columns and their "boxes" should be available as functions to call from within my page code, and the main content (center) pane becomes one cell in my layout table. I want to put most of the left and right column content under my left navigation column, with some items dropped (e.g., no "news" or "contact us", as that's handled elsewhere), and put the shopping cart link up at the top right in the title row. osC would ship with a standard set of page layouts that look pretty much like today's default store, but with function calls to make it easy to use my existing page layout (or, as mentioned above, have different layouts for different substores or departments or commissioned sellers). I'm open to ideas on how to best do this. Permit features such as "tell a friend" to be disabled, so it's not considered spam? Also, embedding osC content within existing site page layout means that the rest of the site determines whether HTML or XHTML format (see above on W3C compliance).

 

6. Have per-user time and date format, timezone, and Daylight Saving Time rules. If nothing else, this information will show up on the sales receipt page. The store owner would select a default format that a user can override.

 

7. In addresses, permit the user to type the state (US) abbreviation, rather than forcing them to use a pull-down. Typing the state or province could have the matched entry come up and display. The idea is to not force the user to interrupt their typing to use the mouse to select from a list, although that way should of course be permitted. Also, do US visitors always see "ZIP Code" and non-US visitors see "Postal Code" or "Post Code" (consistency)? You don't want to show "Post Code" to US visitors, as most will have no idea what that is, and many non-US visitors will wonder what a "ZIP Code" is.

 

8. Email notification on whole category or just subcategorie(s). Be sure to have a way to throttle email sending rate, as many hosting services get upset if you dump 2000 emails into the hopper at once. Have a common email subsystem that the newsletter could also use.

 

9. In displaying product information, avoid information overload. Show general information first, then permit (but not force) links to more specialized information on other pages.

 

10. Not everyone is going to want to run osC as their entire site. I plan to integrate it into a forum and other stuff (see comments above on page layout). Consider multiple ways to get "into" the store, or bounce back and forth between forums, other information, and the store without losing the shopping cart or timing out. For example, a forum posting might link to a specific item in the store, or the item listing might point to a forum posting discussing the item.

 

11. For products with no descriptive text, the URL field would be interpreted as the filename of the PHP content to be include()d into the store page. This would permit custom page layouts for selected products, instead of forcing the same template for all products (remember that different product/department categories can get their own layouts, too).

 

12. SSS (single site signon). When osC is about to ask the visitor to sign in, it would first check a common utility (to be written) to see if the visitor has already signed in from a forum, blog, gallery, or some other part of the site. The common username would be used to fetch the proper osC settings, without the visitor having to sign in again. If the visitor has not already signed in, the regular osC sign-in would be used, and the user name passed on to SSS so that the visitor can go over to the forum or whatever and not have to sign in again.

 

13. Enhanced pricing lookup function available (e.g., bulk discounts) and enhanced shipping options/costs function (e.g., two tee-shirts ship for the cost of one, three or four for two, etc. because you can fit two shirts in, say, one Priority Mail envelope, or whatever). These would supplement (or replace, if desired), the regular pricing and shipping cost lookups. Shipping could get very complicated as some things could be shipped together in one box or envelope, while others have to be shipped alone.

 

14. Does osC gracefully handle a shopper adding more of the same item? That is, I put 3 widgets in my cart, do some other shopping, and come back and put 2 (more) widgets in my cart. Does this show as 5 widgets or separate entries for 3 and 2? Any opinions on whether it should be one way or the other? Be careful about a given item with customizations (color, size selection, text to be engraved, etc.). Is there a place for the buyer to give special instructions, such as text to be engraved on a plaque or ring?

 

15. A better backorder system, where a shopper would be told upon their initial quantity selection (put X count in cart) how many items will be backordered and how long it should take to get them in. The shopper can choose to remove the backordered items, have them charged and shipped separately, or have the entire order delayed until it can be completely filled (shipping costs may determine what they wish to do). It could be optional to show "in stock" count on the item page (with the warning that other shoppers may be eating away at that stock while you're looking at the page!). Does osC decrement the "in stock" count as soon as an item is put in the cart, or does it wait until checkout is done? Is there a provision for "build on demand" product, where no inventory is kept (will never be out of stock or backordered)?

 

16. Are newsletters available only to registered users? Should there be an archive of them for newcomers to read? This would of course be configurable (allow general public to read all back issues (or just older ones), or just registered members). As with notification emails, be careful to throttle the sending rate.

 

17. What is a "New" product? There are a number of ways store owners could want to show "new" products, and it should be configurable, some combination of:

- last N products added

- products less than M days since they were added

- minimum number of "new" items (so it's not empty), even if it means older products

- maximum number of "new" products to show, with possible random selection from a larger pool

- choose from overall product set or a minimum number from each category/subcategory

 

18. A clean way to "dump" the entire product database (or selected categories/subcategories) to a file, for cleanup and printing of hardcopy catalog. Different store owners will want to use different layouts and different kinds of data, and different document processing programs. Even if dumped to a markup language such as LaTeX, there will probably be a fair amount of manual labor involved. I don't even want to think about importing this stuff into a WYSIWYG word processor such as Word (but many people will want to do that). Ideas?

 

19. I know that some other applications (such as the SMF forum software) have a terrible time with compatibility between add-ons or mods and different base versions, or even worse, with mods stepping on each others' toes when you try to install more than one. SMF uses a package installer that looks for a match with a code pattern to see where to insert new code, replace old code, or delete old code. This tends to break when the base version changes, or one mod has already been installed. I haven't looked at the osC mechanism, but someone might want to mull over it and see if there are improvements that could be made.

[Kawazu]

Might I also suggest changing the password encryption method? A bit more of an undertaking (especially if you already have customers), but it's something we've been taking a look into. We're not satisfied with the method currently used (md5 is much too fast), and we're currently redoing our site and I do believe that's on the list. Not necessarily a huge priority for smaller shops, but I'll share anything we might make just for the heck of it.

[♥geoffreywalton]

Phil

 

Wow, what a list. Have you sent it throught to the development team?

 

Tidying up and making the code more readable wold be great but to back port it would make contributions very difficult to install as line nos could be wildly out depending on if you had applied the changes. Maybe for a new release.

 

There are more and more stores falling over as their host upgrade to mysql5, so any fixes would be great http://addons.oscommerce.com/info/3727 could help them.

 

Keep going.....

[MrPhil]

Wow, what a list. Have you sent it throught to the development team?

I have no idea who to send it to or what the protocol is. I've already done much of the MySQL 5 and PHP 5 cleanup, so I'd be happy to donate the code, if someone will tell me the procedure (and if the developers are interested).

 

Tidying up and making the code more readable wold be great but to back port it would make contributions very difficult to install as line nos could be wildly out depending on if you had applied the changes. Maybe for a new release.

Yeah, it will probably break every mod in the library. Someone needs to think about a structure to accommodate mods to different base codes and previously installed mods. I've floated the possibility over in the SMF discussion boards about a preprocessor that takes a mixture of PHP code and pp directives to merge in all the desired mods at once into PHP files to go on the server. In the long run, I think it would be worth the immediate pain to make the code more readable and cleaner. I can understand not wanting to do this for RC2, but for 2.3 or 3.0 maybe?

 

There are more and more stores falling over as their host upgrade to mysql5, so any fixes would be great http://addons.oscommerce.com/info/3727 could help them.

Most of what needs to be done for PHP5 seems to already be in RC1, except for the MySQL 5 changes. And the only major one there I'm aware of is the precedence change between the comma and JOIN operators. I have downloaded the change files at that link and will look over them to see if there's anything I should add to my existing changes. The latest entry says that everything is obsolete and has been rolled into (?) RC1 already.

 

Keep going.....

Thanks! It's nice to get some encouragement on this.

 

If the developers take a "pass" on my work, I will do it myself and consider making the revised source available from my site (within the license terms). I'd really prefer not to "fork" the development, so let's see what happens.