Harald Ponce de Leon

When Ian's Credit Class work is integrated into the project, there would have been too much information shown to the customer on this one page. Originally the textarea box was moved to the Checkout Confirmation page however due to the flexibility of the modules, depending on which module is installed and used the information could have been lost if the form on the confirmation page was sent to the payment processor server. It is possible to have the textarea box on the Confirmation page however the modules requiring to make a request to another server via HTTPS POST would need to be done via Curl or using native SSL features in the upcoming PHP 4.3 release - something which would have broken compatibility between servers. This is why it was moved to the Checkout Success page. By using Curl, the form method on the confirmation page would be taken to the processing page (checkout_process.php) where the request to the payment processor would be done in the before_process() payment class method.

Sure you can - sign up an account at SourceForge and get your solution listed at HotScripts. Thats how I started :) I don't know the intentions of your solution on how it will relate to osCommerce - if it no longer relates to osCommerce I will kindly ask you to stop making postings here as this is a support forum for osCommerce only. There are plenty of other forum sites available if all you're looking for is help to get you started in your own ways.

Is someone able to provide the API documentation for both SIM and AIM processing methods - this will help in stablizing the payment module.

This is an interesting quote from their FAQ: This is also interesting: .. now if that was set here, how many posts would that reduce the forums to? ;)

Did you not read the forum rules? Please provide appropriate reason why you feel it is not necessary to upload that to the contributions area. If the file is bigger than 300k, please email it to me so that I may add it for you (with your name as the author).

Something that we've started to do in the project is to make sure the bells and whistles (javascript) still work when the browser does not support it. I think the only example I can provide is the product image in the product information page. Clicking on it with javascript enabled will bring up the picture in a new window. Clicking on it with javascript disabled will load a new page with just the image showing. This can be done by specifying logic in <noscript></noscript> tags and be writing the javascript logic in javascript itself (huh? I mean with document.write :)) I do not mind DHTML menus etc - as long as the feature they are representing works with browsers that have it disabled. An example here is a DHTML menu - the buttons representing the menus should still be clickable to go to that area so that browsers that do not show the menu can still navigate on your site. This isnt a case for dropping bells and whistles - but making sure your site can be navigated by as much browsers as possible - which is important for an online shop otherwise potential customers will be that no more.

There is a cross browser DHTML menu solution available at Milonic.

moved to contributions

moved to Contributions forum