When magic_quotes_gpc is on with an osCommerce 3 installation, it can cause a weird looking error when editing a product with quotes or backslashes in the name or description.  Each time you edit and save, it adds backslashes before all quotes and backslashes.  Thus what starts as ” becomes \” and then \\\”, \\\\\\\”, and so forth.  This is covered in osCommerce bug report 1010.  I verified the issue and created a patch for it: 

What this code does is it checks if get_magic_quotes_gpc is on and if it is, the code undoes it by running stripslashes on all the values in the GET, POST, and COOKIE superglobal arrays (the GPC in get_magic_quotes_gpc).  The code uses array_walk_recursive so that if any of the values are arrays, those get handled as well.  The osc_stripslashes_callback function is created because stripslashes does not have the correct method signature to be called from array_walk_recursive. 

It’s possible that the code still does not handle magic_quotes_sybase correctly.  It may be that stripslashes does not cover the sybase change.  If so, then it should be relatively simple to change the code to properly cover the sybase case. 

A second problem is that the order information generation is hard coded into the layout.  In other words, the layout and database access are intertwined.  Further, the function unsets all the generated variables as it goes, so it would not be simple to refactor this to separate the data generation from the layout.  It’s not impossible, but it would require a complete rewrite of the data generation — possibly even an interface to provide functions that can handle the looping efficiently. 

Another option would be to generate something like an XML file with the order information.  Then that could either be parsed to generate the email or transformed with XSLT into the email. 

This issue is rampant throughout the osCommerce 3 codebase.  There is still a great deal of content (e.g. HTML or email) embedded in code.  The template system is better than what existed in the 2.2 series, but it still leaves a lot to be desired. 

The problem that I have with the PayPal Standard that comes with osCommerce is that it duplicates a lot of code that is included elsewhere.  This produces difficulty whenever it is used with another contribution that modifies checkout, as the changes need to be put in both places.

Checkout Redux avoids this by refactoring checkout in such a way that it always inserts orders in the database before redirecting to an external processor (orders processed via curl and other backend methods still operate the same way as always).  This eliminates the need for the PayPal module to insert the order in the database.  In addition, Checkout Redux moves the insert order and order notification (email) code out of checkout process and into their own modules.

The result of this is that we can now call the checkout notification module from either checkout_process.php or a notification handler (e.g. standard_ipn.php).  This way, when a contribution needs to change the emailing code, it can always do so in just one place.  No need to modify multiple files to implement a single change. 

The other major goal of this contribution is to shorten checkout.  It does this by reducing the number of pages in the registration process and by skipping pages where no choice is made.  Now, if the customer enters checkout without logging in, it immediately offers a chance to enter a shipping (or billing if only downloadable products are in the cart) address.  When the customer submits the address, if there are no errors, it creates an account and sends the customer to the checkout_shipping page.  This saves two clicks in the process (clicking to the register page and the create_account_success.php page). 

More clicks are reduced by skipping pages where no choice is made.  If a store only has one shipping method, then checkout_shipping is not needed.  Forward to checkout_payment.  Similarly, if there is only one option on checkout_payment, then it can be skipped.  Onward to checkout_confirmation.  As a result, the typical checkout for a new customer is reduced from seven clicks to three (checkout, submit address, and confirm). 

The package includes a modified PayPal module (both the payment module and the IPN handler), a Google Analytics integration (to demonstrate the advantages of some of the checkout success changes), alternate files for use with the DHTML State Selection add on, and an example of how to integrate another add on that changes the checkout_process.php file:  the Club osC Discount Coupon System. 

1. The Javascript script tags used language=”Javascript” and did not include type=”text/javascript”. 
2. The flash (for the clipboard) used embed, which is a Netscape proprietary extension. 
3. WordPress automatically adds paragraph tags and either the code block was in a paragraph with other content or it was in its own paragraph.  Unfortunately,
   <pre> is not a valid child of <p>, so the validator barfs. 
4. Even if I strip the paragraph tags, the <pre> contains a <table>.  Again, table is not a valid child of pre. 

The first problem was easy enough to fix.  I just added the necessary type=”text/javascript” until the problem went away.  The second was more complicated, but with the help of the Flash Satay technique, I was able to make a standards compliant version.  I did not bother with creating the container flash, as the necessary flash is small enough to load completely.  Streaming is not needed.  The fourth was an easy fix.  I just changed the pre to a div.  This works fine in both IE and Firefox, so I’m happy. As you may have guessed, the third was not as simple a fix.  I actually got it working pretty quickly by editing a WordPress function.  However,  I wanted to get it working by modifying the Developer Formatter plugin, as the solution has code specific to the plugin.  That took longer, as the plugin does some wizardry that hides the code block while it is letting the WordPress content filters run.  I originally tried to modify the wrong section of code and got no result, so I switched to adding a new filter that would run after the working WordPress filter.  That failed.  I finally worked out the proper place to change the Developer Formatter plugin and did so. The full set of code changes, starting with devinterface.php:

The type=”text/javascript” was added.  This code would also validate under XHTML strict if the language=”JavaScript” was removed.  However, for my purposes, XHTML Transitional is sufficient.  Next, in the devfmt_ParseStructure function in devformatter.php: 

replaced

and to finish that function, change pre to div: 

Later in the same file, in the devfmt_ContentFormat function, added

These became the last three lines before the else and then the return.  I.e. the effect was to make these the last statements that ran before the string was returned.  Finally, to make the javascript work with the object replacing the embed for the flash, in devfmt_common.js, I changed

to

Now, with these changes, my site validates in XHTML Transitional.  It almost validates in XHTML Strict, but the aforementioned language=”JavaScript” and the use of target=”_blank” keep it from passing.  I’m not willing to give up the open in a new window functionality, so I’ll stick with Transitional. 

I’m going to see if I can talk the author into including these or equivalent changes into the next version of the Developer Formatter.  It looks like the clipboard actually is a third party library called Zero Clipboard by Joseph Huckaby.  I’ll try to touch base with him as well. 

Update: report posted on WordPress forums.

Update:  issue reported at the Zero Clipboard project page.

Two lines changed (75 and 88) and four lines added (99-102). 

What this does is it makes the image fit within the selected size, preserving the image ratio.  This takes the traditional advice (set Calculate Image Size to true and leave the width blank) and expands it for stores that have both narrow and wide images.  The traditional advice could actually cause images that were tall and narrow to expand further in height, breaking out of the box for them.  With this code, the image is always smaller than the box size (or the exact box size). 

And make one change in tep_draw_separator, to keep this change from breaking tep_draw_separator:  

What this does is it keeps osCommerce from preserving the image ratio on the separators. In that case, we want the single pixel image to appear in different ratios than the original.

The behavior that this caused in osCommerce was to make the attributes disappear any time that the cart was updated (item removed or a quantity changed).  The problem being that it was using the posted variables to determine the attributes.  I’m not sure why it does this.  It should have all the required information in the $cart variable stored in the session.  Perhaps it is trying to mirror the product_info page behavior. 

A surprisingly small change fixed this.  I simply replaced the products ID string with the numerical placement in the list.  I.e., for the first item, it’s ID became 0.  The second item was 1 and so on.  I changed it once in the shopping cart page and once in includes/application_top.php.  This decreases the robustness somewhat (we are now relying on order being preserved through the POST), but it worked in my testing. 

The includes/application_top.php change (only 354 changed; the others are just for context and to make the code highlighter offer a scroll bar): 

The shopping_cart.php change (only 86 changed): 

One suggestion to resolve this was to set Recreate Sessions to true.  While that is a good setting, it only helps if the user was not logged in at the time the link was sent or if the link is used after the login session has expired.  Another suggestion is to check IP address, but that breaks people on proxies.  Another suggestion is to check the user agent setting, but that won’t prevent the situation where both people use browsers that happen to pass the same user agent string. 

I went back to the initial problem.  If someone is logged in and browsing with a session ID in the URL, they will always have a referrer on the osCommerce site.  If they leave the osCommerce site, then they will lose the session (which is one reason why cookies are preferable).  Therefore, if their browser sends a referrer, the referrer will be on the osCommerce site.  By contrast, the recipient of our hypothetical email will always have a blank referrer. 

Can we simply check for blank referrers?  Not really, it is possible to configure browsers not to send a referrer.  If we block sessions for people without referrers, we will prevent login by anyone who has a blank referrer.  Also, although we have been talking about email, there are other ways to share links, e.g. posting on a website or tweeting.  In those cases, the link will have a referrer, it just won’t be osCommerce.  So we need to check to see if the referrer is osCommerce and we need to allow for legitimate blank referrers. 

My proposal is that if someone comes to the site with the referrer set, osCommerce will check to see if they have a session open.  If so, osCommerce will see if they have a referrer set for the session.  If not, then osCommerce will set the referrer.  Now, if someone sends a request to osCommerce with a blank referrer, we can check to see if there is a referrer set in the session.  If there is, then we can surmise that this is a new person, so we regenerate and clear the session.  Further, if someone comes to osCommerce with a set referrer, the referrer is not osCommerce, and they have a session ID in the URL, we can regenerate and clear the session as well. 

This covers: 

1. The case where a link is emailed with the session ID.
2. The case where a link is posted externally with the session ID.
3. The case where someone sends a blank referrer on every request.
4. The case where someone is browsing through the site normally and sending  a referrer.

We are left with an odd edge case, where someone who browses without a referrer emails a link to someone else with the session ID in it.  In that case, the code would still fail, and they will share a session.  You can slightly reduce this risk by checking the user agent. 

Code: 

This has also been posted in the osCommerce Tips & Tricks forum.

This brings up a point about the difference between DHTML and AJAX.  AJAX is the new sexy term for fancy javascript and is often used to describe things that are really DHTML.  AJAX stands for Asynchronous Javascript And XML.  DHTML stands for Dynamic HTML.  DHTML is taking the HTML that appears in the page and making changes to it with Javascript.  AJAX is making a small web request to get an XML response.  People often then use the AJAX information in DHTML changes that they make to the page.  This has led to people calling DHTML widgets AJAX. 

My add on is plain DHTML.  It generates all the required drop downs on the server and hides them via a display:none CSS style.  The Javascript that I wrote then turns on display of the appropriate menu when a country is selected from the countries menu.  With all the zones installed, it’s a relatively heavy weight page.  On the bright side, most of the page displays before it gets bogged down in creating the menus.  Someone can enter name, street, zip, and city while waiting for the state and country to load. 

The other add on apparently uses AJAX to load the menus.  Presumably this makes the initial page load faster (fewer menus to send), but it also suggests that there will be a lag after the country is selected, while it loads the new menu.  An interesting future project might be to do a performance comparison of the two contributions. 

The way that this code works is that it adds a new text input next to the existing file input (for both product and category images).  It then uses the functionality in the upload class that osCommerce provides to rename the image to whatever name is put in the text input.  If the name includes a / and the directory structure exists, it will save the image into that directory. 

When you upload a file with PHP, PHP/Apache stores the file in a temporary directory.  So you then have to tell it to move the file from the temporary directory to the real directory.  The parse method in the osCommerce upload class finds the temporary location.  The save method then moves the file to its intended destination. 

The added code has three main tasks:  it adds the text input to the appropriate forms (three forms; one for products and two for categories); it changes the image saving to use the new image destination; and it modifies the database updates to use the image destination rather than the name of the uploaded file (if the image destination is present or if no file is uploaded). 

The net result of this is that with the code, you can not upload a file and blank out the image destination (which defaults to the location of the previous image) to remove an image from a product (or category).  In the regular code, there is no way to do this.  Upload an image with a blank destination, which causes the image filename to be used and the image to be placed in the base images directory.  Or you can upload an image with the destination set, which renames the image to the destination, which may be in a sub-folder of the images directory. 

The one drawback to how this works is that it is currently necessary to create the directory separately (possibly via FTP).  A reasonable enhancement might be to have it do a mkdir to create the directory on the fly.  Not sure how that would work with safe mode though.