Jump to content

Harald Ponce de Leon

Admin
  • Content count

    5,378
  • Joined

  • Last visited

  • Days Won

    125

Posts posted by Harald Ponce de Leon


  1. Hi Andy..

     

    Yes, as Gary noted, please fork the repository at Github. This will create your own repository where your changes can be committed to. As soon as you're ready with what you're working on, send me a pull request (easily done on Github) and I'll review the changes you've made.

     

    The repositories are located at:

     

    http://github.com/osCommerce/oscommerce - osCommerce Online Merchant v3.x

    http://github.com/osCommerce/oscommerce2 - osCommerce Online Merchant v2.x

     

    Please note that the main v3.0 repository is way behind my personal fork (haraldpdl/oscommerce) due to the PHP v5.3 framework changes. If you'd like to work on v3.0, it will be best to fork my personal repository instead for the time being.

     

    Thanks, looking forward to seeing your changes!

     

    Kind regards,


  2. Hi Alan..

     

    In my environment, session.use_only_cookies was set to 1 in my php.ini configuration. When this is set to 1 and cookies are disabled on the browser, it seems sessions will not work at all. The following change has been made to set this php configuration value to match the value of SESSION_FORCE_COOKIE_USE:

     

    http://github.com/osCommerce/oscommerce2/commit/83aa5719a45826122d07467e0760ad98ddbdb4de

     

    Please test this out and report back if it worked for you.

     

    Thanks!


  3. Hi Alan..

     

    This is the changeset you are referring to:

     

    http://github.com/osCommerce/oscommerce2/commit/92eeb647ea9e89291dbb291a14742dc39ed26007

     

    Could you confirm the changes to the following files:

     

    catalog/create_account.php (reset session token)

    catalog/includes/application_top.php (initialize session token)

    catalog/includes/functions/html_output.php (have tep_draw_form() support session token)

    catalog/login.php (reset session token)

     

    Thanks,


  4. Hi Alan..

     

    I'm going to experiment a little more and see if there are simple alternatives which will work and allow the use of the system identifier.

     

    The doctype used previously made the browser render the page in quirks mode as it was an incorrect doctype. This was as if no doctype was specified at all.

     

    Making the doctype compliant with the change in Github made the browser render the page in standard/strict mode, where there are differences as to how the elements within the HTML page are rendered (box model, margins, ...).

     

    I did not know of this behaviour before and was interesting reading up on it.

     

    The rendering bevhiour for v2.2 should not be changed and will remain in quirks mode. We're still testing if the shorter doctype can be used or if the change should be reverted.

     

    Kind regards,


  5. Hi Alan..

     

    Great catch and thanks for pointing this out!

     

    I did not know that "fixing" the doctype would cause such incompatibilities. Quickly looking into this, it seems there is a difference with browsers rendering in quirks mode or in strict mode. Some information about this is available here:

     

    http://www.quirksmode.org/css/quirksmode.html

     

    Still contemplating what to do here.

     

    Kind regards,


  6. Hi All..

     

    Thanks for the feedback - it has been well received. This is a good time to lock the topic to prevent a circular discussion occurring; we would rather answer with releases than statements.

     

    Our main focus is still concentrated on v3.0 and beyond. In addition, v2.2 is also being maintained with bug fixes and security updates. We are looking at pushing 2.2RC3 out this week with security updates.

     

    Without a stable footing we are just building a house of cards on a dodgy foundation, you the community can help make that foundation as solid as possible.

     

    That statement needs to be stamped in everyones mind - the v3.0 release is not a revision to v2.2, it is just shy of a rewrite with opposite fundamentals with how v2.2 was realized. A lot of work has gone into realizing v3.0 (which started as 2.2MS3) to get the foundation right for future point releases, and to make the upgrade path as easy as possible for store owners to perform.

     

    We are proud of how v3.0 is developing and are real anxious to push it out as soon as possible.

     

    Kind regards,


  7. It would be great if you could report which osCommerce Online Merchant version you are running. This can be found at the following page:

     

    Administration Tool -> Tools -> Server Info

     

    The osCommerce logo and version should be shown on that page.

     

    Kind regards,


  8. Hi..

     

    2) what is the Sage Pay Reference ID in admin and order confirmation email? It appears to have nothing to do with any info I can find on my sage test admin account = useless if a customer quotes it to me. It looks encrypted?

     

    The Sage Pay Reference ID is a unique code on the Sage Pay payment system used to reference the transaction.

     

    Please can you state specifically which osc versions this fix needs to be applied to?

     

    That fix is needed for osCommerce Online Merchant v2.2 Milestone 2 installations. This fix can be verified by viewing the checkout_process.php file and if you see this:

     

    // load the before_process function from the payment modules
     $payment_modules->before_process();
    
     require(DIR_WS_CLASSES . 'order_total.php');
     $order_total_modules = new order_total;
    
     $order_totals = $order_total_modules->process();

     

    it needs to be changed to this:

     

      require(DIR_WS_CLASSES . 'order_total.php');
     $order_total_modules = new order_total;
    
     $order_totals = $order_total_modules->process();
    
    // load the before_process function from the payment modules
     $payment_modules->before_process();

     

    Kind regards,


  9. Hi Ross..

     

    The Sage Pay Form, Sage Pay Server, and Sage Pay Direct payment modules have been updated with bugfixes you described above.

     

    http://addons.oscommerce.com/service/sage_pay

     

    The update to Sage Pay Server also fixes the signature issue you were experiencing with Maestro cards. The verification of the CardType value did not include SWITCH which the gateway was returning as this was not mentioned in the API integration documentation. Sage Pay have made a note of this and will make an update to their documentation.

     

    Thanks again for your feedback!


  10. Hi Ross..

     

    Thanks for your feedback!

     

    1. This is a confirmed bug and an updated version of the Sage Pay modules will be pushed out shortly.

     

    2. This could very well be due to an outdated template you are using. It would be great if you could confirm this.

     

    3. This bug was fixed in 2.2 RC1 with the exact solution you have posted :-) We will make a note of this in the documentation.

     

    4. The modules will definitely provide more advanced features in v3.0. It won't be possible for v2.2 as core source code changes are required. This could be taken care of with an add-on though.

     

    5. The problem with the signature is being looked into.

     

    Kind regards,


  11. Hi Kyle..

     

    That error was corrected in the v1.1 module version with a new parameter to control where the card input information should be accepted. 2.2MS2 stores need to set this setting to the Checkout Payment page where 2.2RC1/RC2 stores can choose either Checkout Payment or Checkout Confirmation pages.


  12. Hi Allen..

     

    This is not a problem with the PayPal module but with your store configuration. Try setting the ENABLE_SSL parameter to false in your catalog/includes/configure.php configuration file.


  13. Hi Marc..

     

    I see the Paypal IPN module has been removed from the newest release. Why?

     

    In 2.2RC2, the PayPal IPN module (paypal_ipn) has been renamed to PayPal Website Payments Standard (paypal_standard).

     

    But they can call checkout_process.php! It will update the status to PAYPAL_..._ORDER_STATUS_ID. Try it!

     

    This has been fixed in 2.2RC2 with additional checks in checkout_process.php.


  14. Hi Mike..

     

    Passing each product to PayPal is not possible due to the strict checks made against the product cost, product quantity, order total cost, order shipping, and order tax values passed to the gateway. Due to the dynamic nature of calculating order totals on the catalog side, using an additional order total module, such as the low order fee module, would fail PayPal's calculations due to a mismatch with the order total cost value.

     

    It is not possible to pass custom order total values to PayPal so this feature is not supported, and only the name of the online store is passed with the transaction.

×