Robbogeordie

Here's how I fixed it. I removed the recursive code that I'd put in my .htaccess and simply copied the php.ini file to my admin directory instead. Fopen On in admin Voila, simple as that.

Some more info here: https://www.pickaweb.co.uk/kb/inherit-php-values-in-your-local-php-ini-to-all-subdirectories/

I'm also having this issue. If you put @burt code in a new file in your admin folder and check the output my guess is that it will still be: Fopen Off If your custom php.ini is not recursive then the PHP Values In Your custom php.ini are not inherited by any Subdirectories, so Fopen will be on in the root folder, but nowhere else. I've not fixed mine yet because it's throwing another error due to a missing dll, but to make your custom php.ini recursive add this code to .htaccess : suPHP_ConfigPath /home/USERNAME/public_html Some information here: https://www.inmotionhosting.com/support/website/recursive-php-ini/

This happens on half my orders. I even changed my PayPal settings to automatically redirect back to my website after completing the order,but half the customers must close the browser before being redirected back to the site as no order emails are generated,stock deducted etc. Does this happen to other site owners using PayPal Standard, or am I doing something wrong?

Having problems getting the new version for osC v 2.3.4 to work. I copied my old QBI tables into the database because the addon wouldn't create new ones. After this the QBI admin page is fine and correctly displays the 'New Orders,'Previous Batch of Orders' etc,but unfortunately the download buttons are not working and in the configure page I can't update any settings. I've reinstalled several times,but with the same result unfortunately. If others have got this working on v2.3.4 was there anything extra you had to do,if not then I can't figure out why it's not working for me. It's a great contribution which has served me well on v2.2,so I'd really like to get this up an running.

When our default currency is changed from $ (USD) TO Euro the order email confirmation shows the products with the default store currency $ - the sub totals,shipping and totals are in the correct changed currency - Euros. Products ------------------------------------------------------ 1 x Keyrings - (Pack of 10 Assorted Colors) (KR001) = $9.82 ------------------------------------------------------ Sub-Total: €7.32(EUR) Registered International Air Mail: €5.93(EUR) Total: €13.24(EUR) This code seems to be pulling the default currency - ext/modules/payment/paypal_ipn/ipn.php : $currencies->display_price($order->products[$i]['final_price'], $order->products[$i]['tax'] Installed Version v 2.3.3.0 and tried newer ones,but with the same result. Others have had this issue and I havn't seen any fixes ...anyone got a fix?

The code to reload the page after login works for me also. Thanks Hajimart!

Exactly the same issue "confirmation password does not match the password" on 1.4 Everything pre-fills and loads fine,but the error message pops up when trying to checkout. This only happens when using OPC to login. Also the Breadcrumbs bar does not load the logout link which should show when a customer is logged into their account. If after logging in on OPC and you click to go anywhere else on the website - then the logout option appears in the breadcrumbs bar and when checking out with OPC there is no error.

Hi Jan, Yes,it was working before.It's just the Japanese yen which doesn't have any decimals.The exchange figures are wayout.The only way for it to work correctly is if it is set it to 2 decimal places.Then it's fine. If no one else is having this problem then please don't worry as it could be one of my contributions ..maybe salemaker or something.I'll let you know if I find out what was causing it. Thanks for your quick reply.

Hi, Thanks for this excellent contribution. One thing that I can't seem to get fixed on my site is if I change currency from the base US$ to JPY (which doesn't have any decimals) then the currency is converted to an incorrect amount.I've put a zero in the decimals entry in admin like was suggested earlier in this thread and tried other combinations,but it keeps converting the price completely wrong.The only way to get the amount correct is to add a decimal place to the currency. The currencies.php file is the same as the RC2a one.All the other currencies which have decimal places are fine - does anyone have any ideas what could be causing this,or a fix? Thanks for any help.

Hi, Is there a fix to use with Register Globals off. Thx

Your problems 1. I think this is because your setting with 2Checkout is set to aggregate - otherwise you have to pre populate 2co with your products for an itemized listing which can be problematic. 2.No idea why a percentage is added. 3.If your currency is set to US $ as default with your 2Checkout account then even if you have multiple currencies available on your site and your customer has selected another currency on your site 2co either convert it back to US dollars and then the customer can click to convert the currency to their own on 2Checkout site. Otherwise I think 2Checkout also use Geo IP and automatically convert to the customers location currency.They always do this by taking your default currency i.e $ and then applying their own rates which will probably be different to yours. Whichever method is used it is unlikely to match your websites exchange rate and could lead to problems as the customer checks out with you expecting to pay a certain amount and it changes on 2Checkouts site. The only way around this appears to be to have several 2Checkout accounts in different currencies and make sure that if your customer chooses for example Euros they are sent to your 2Checkout account that has Euros as the default currency,or only use one currency on your website. They are the only options I can figure out at the moment unfortunately.

"Salemaker" will do this for you and you can pick individual products with "Specials". Salemaker - you can pick a category or two and how long you want a sale to last,percentage discounts etc - should do what you need.

I have CCGV installed on v2.2 MS2 . The only PaypalIPN version I can get it to work with is PayPal IPN Module v1.4 Contribution 2679. This module does not pass any shipping information to Paypal - so we can't tell if an address is confirmed or not.Does anyone have this version working with some extra code to add the shipping info. None of the v2s later versions work with CCGV that I can tell. Also,tried these and they appear incompatible - PayPal Express Checkout, PayPal Express Checkout IPN, Paypal Website Standard. The only one that I have read will work is an older unsupported PayPal Shopping Cart IPN 1753 by Devosc. Does anyone have any suggestions as there must be lots of people with CCGV who use Paypal Thanks

It looks good now. I tried this contribution and had some issues when I tried to change the ship to address and the login for existing customers. How did you change things to get it working ? Chris

Have you inputted the API signature in your configuration ?

Whoops mine's a different module (just re read)

Don't know which version you're using,but the file I edit is here : \includes\languages\english\modules\payment\paypal_ipn.php

I'm just trying to integrate this Devosc Paypal IPN with CCGV and have been doing some testing. I do like it I must say...so I hope it continues to work ok with any of the PP changes going on right now. Anyway,on my Sandbox tests when clicking for details it shows "pendingreview" status ok. After just discovering this fine contribution I hope it continues to roll on.

Just to keep anyone with similar issues with ccgv and Paypal - I have installed PayPal Shopping Cart IPN 1753 by Devosc and been testing it in PP Sandbox and have been very impressed with it. The shipping address details are passed to PP and the voucher can be used. Everything appears to work as it should apart from the free shipping voucher deducting off the products - same final price mind. I think there is a fix somewhere for aggregating products and shipping together and the discount is applied off this total so that it's not confusing for customers. Any feedback from people who use these two contributions together, or is it best to rip out CCGV code and start again?

Forgot to say that we don't qualify for Website Payments Pro due to location - so although this module can work with CCGV we can't use it unfortunately. Has anyone successfully modified any of the newer Paypal contributions ?

It would be great with "Ask a (product) question" as well.

Don't increase through localization - use a contribution like price updater. The localization should be used for currency conversions,not to alter the default currency.

I have some issues since I also installed the Register Globals Easy to Oscommerce 2.2 -MS2 with 051112, 051113 and 060817 security updates/patches. Environment - PHP Version 5.2.4 Mysql 5 Register Globals off by .htaccess When I clear cache and go to the site I get the following error message - (This error goes away after the first click . We have force cookies set to true - if this is set to false the warning does not show.) : Warning: extract() [function.extract]: First argument should be an array in /home/xxxxxx/public_html/includes/application_top.php on line 224 Code in application top file: // Register Globals MOD - http://www.magic-seo-url.com if (!ini_get("register_globals")) { if (version_compare(phpversion(), "4.1.0", "<") === true) { if (isset($HTTP_SESSION_VARS)) $_SESSION &= $HTTP_SESSION_VARS; } extract($_SESSION, EXTR_SKIP); //*****Line 224***** } We also lose the permanent cart - When we log off with some items in the cart and clear the cache and cookies and log back in again the cart is empty. Does anyone have any ideas/suggestions. As a side note,some of my contributions that didn't work with the other Register Globals patch do work with this one,so it would be good to get these issues ironed out. Thanks, Chris

That's great Joseph - glad it's worked out for you! The fix is thanks to Bob though. It seems to work fine on my site as well.