Guest Posted July 4, 2018 Share Posted July 4, 2018 Using 2.3.4.1 CE and PHP 7.0 PayPal Standard worked terrifically in my new site until I reworked and installed an old contribution, SEO-G urls. Now....buyers are making purchases, but when returned, their carts are not empty. No order process emails are being sent. Stock not being reduced. Error log reads: [04-Jul-2018 15:54:41 UTC] PHP Warning: require(standard_ipn.php): failed to open stream: No such file or directory in /home/xxxxx/public_html/root.php on line 136 [04-Jul-2018 15:54:41 UTC] PHP Fatal error: require(): Failed opening required 'standard_ipn.php' (include_path='. ; ; Windows: \path1') in /home/xxxxx/public_html/root.php on line 136 Now...root.php is a new file that comes with SEO-G URLS. The line that is throwing the error, line 136, simply reads: require(basename($PHP_SELF)); Lord knows I had to clean up a ton of code in SEO-G to get it working with PHP 7, but I have no idea what is going on with this. Any idea why PayPal is unhappy with that line above? - Andrea Quote Link to comment Share on other sites More sharing options...
Hotclutch Posted July 4, 2018 Share Posted July 4, 2018 (edited) where is standard_ipn.php located ? There's nothing wrong with that one line of code on it's own, try posting your whole root.php, looks like a path error somewhere. Edited July 4, 2018 by Hotclutch Quote Link to comment Share on other sites More sharing options...
burt Posted July 4, 2018 Share Posted July 4, 2018 Your problem is the basename() function. That strips out the path to the IPN file. You need to somehow stop root.php from rewriting URLs that are not in the base of the site. You may also have problems with other files, such as Braintree, Stripe and some Password functions. As well as any properly coded addons which utilise the new TP system of pages... Put simply: SEO-G is a square peg that you have tried to ram into a round hole. Quote Link to comment Share on other sites More sharing options...
Guest Posted July 5, 2018 Share Posted July 5, 2018 4 hours ago, Hotclutch said: where is standard_ipn.php The filepath is mysite.com/ext/modules/payment/paypal/standard_ipn.php I saw someone else had issues with this going thru the support thread for SEO-G, but I don't see how it got resolved, if ever. Funny thing is....no sooner than I posted for help...I received an order and a payment that went thru just fine it seems. Stock turned off (items had zero quantity left on hand), order process emails for me and her, PayPal info in the order in Admin, looked great! I wonder if it may be just that age-old problem of buyers not waiting to be returned to the site and...kaplooey. I do have a feeling that I need to do something in that new root.php file, I just don't know what it is. I'm going to send you a private message, Ashley. 4 hours ago, burt said: Put simply: SEO-G is a square peg that you have tried to ram into a round hole. Well, what do you expect us to do? There's a ton of us up here that are trying to move forward and rebuild our sites with the latest and greatest only to discover: Every thing we ever installed and used in the past is obsolete! Nothing works! Seriously, don't knock me for trying! I'm just trying to save what I HAD. - Andrea Quote Link to comment Share on other sites More sharing options...
BrockleyJohn Posted July 5, 2018 Share Posted July 5, 2018 The issue here is that your SEO addon is now only coded to work with normal pages that live in the catalog folder. There are a number of files that are located in ext but when they run, they change the current folder to catalog so that all the include files and so on are found. That ext folder is used for files that handle communication coming from outside your store. It's mostly for things like payments, but Paypal will not be the only thing that's broken. You won't be able to reset passwords either. The ipn listener file that is exhibiting the problem has been in this location since v1.0 of the paypal standard addon in 2008 so the cause probably lies in how you have implemented SEO-G in your new store; presumably it worked in your old one. If you had to make a lot of changes for php7 then that's the place to start looking. I'd guess you've changed, removed or bypassed some logic that used to cope with this situation. Or, it's one of those code constructs that can behave slightly differently on php7 than they did previously. The most obvious is $$thingy['whatsit']. If you want to do all this yourself then there is a lot of learning to do. An alternative approach would be to use one of the SEO Url addons that are actively developed and supported and already work with the latest code and php7. If they can't be configured to produce identical urls to the old one, you'd also need to redirect from old to new format. Quote Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released. Looking for a payment or shipping module? Maybe I've already done it. Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x Link to comment Share on other sites More sharing options...
Guest Posted July 6, 2018 Share Posted July 6, 2018 I've used osCommerce for thirteen years and I have yet to see a buyer forget their password...request a new one manually...and have it actually work. So...the password reset thing is the least of my worries. I'm sorry, but you will have to create a new account. I say that once or twice a year. I've gone thru the install again for SEO-G and I don't think I had my root.php file set up correctly. It is now, I feel, yet I continue to get the error in my error logs. PayPal won't quit! They keep trying to connect to the standard_ipn.php file every twenty minutes like clockwork LONG after the sale has been made. The orders look great, which is the weird part. Order process emails generated, stock deducted, honestly...on my end it looks like all is well. Just keep seeing these messages in my error log every twenty minutes. If I weren't taking the time to check that log as often as I do, I would be oblivious that anything was wrong. The part of the file in root.php that's throwing the error reads: (first line throws the error) require(basename($PHP_SELF)); } elseif( file_exists(basename($osc_parse['path']))) { $PHP_SELF = $_SERVER['PHP_SELF'] = $_SERVER['PHP_SELF'] = $_SERVER['SCRIPT_NAME'] = $osc_parse['path']; if(basename($_SERVER['PHP_SELF']) == 'root.php' ) { echo '<b>SEO-G Error</b>: Invalid Self-Request, passed URI Request: ' . $_SERVER['REQUEST_URI']; exit(); I have the following also included near the top of the root.php file (taken from includes/application.top php, which the SEO-G install instructs me to do) that reads: // set php_self in the local scope $req = parse_url($_SERVER['SCRIPT_NAME']); $PHP_SELF = substr($req['path'], ($request_type == 'SSL') ? strlen(DIR_WS_HTTP_CATALOG) : strlen(DIR_WS_HTTPS_CATALOG)); This is where I cannot troubleshoot, no programmer here. Which is why I visit you guys so much! Do you see anything that needs fixing? - Andrea Quote Link to comment Share on other sites More sharing options...
♥JcMagpie Posted July 6, 2018 Share Posted July 6, 2018 This is not going to be a simple fix. Have seen something like this before when updating an old addon , as stated above it may be due to the “require(basename($PHP_SELF));” Basically “require(basename($PHP_SELF))” is not returning the full path to your file /script. If your script is in "https://www.mysite.com/cat/paypal/root.php?a=dfg" what basename my be returning is root.php?a=dfg and you are losing the directory paths. See here http://us2.php.net/manual/en/function.basename.php Try replacing it with this, “basename($_SERVER['REQUEST_URI'])” This should always return the full path. Will it work for your specific code? Not sure only way to find out is try it with your code. I would recommend testing in a sandbox first and not on your site. http://sandbox.onlinephpfunctions.com/ Without the full code it hard to say but If I’m wrong I'm sure one of the PHP experts will let you know. Quote Link to comment Share on other sites More sharing options...
BrockleyJohn Posted July 6, 2018 Share Posted July 6, 2018 The code you're quoting won't work with files outside the catalog directory. If you've not changed it then it never did, so why start worrying about it now? Just turn off IPN and manually check if each transaction actually matches paypal... you just need to click verify in the paypal tab on the order. Quote Contact me for work on updating existing stores - whether to Phoenix or the new osC when it's released. Looking for a payment or shipping module? Maybe I've already done it. Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x Link to comment Share on other sites More sharing options...
Guest Posted July 6, 2018 Share Posted July 6, 2018 @JcMagpie Actually, the root.php file is appropriately named. It resides in the root folder. public_html/root.php It's kind of a mashup of includes/application_top.php and new code for the SEO-G contrib. I did have this working on my old site, but I must admit I never watched the error logs like a hawk...as I do now...so maybe it threw errors, maybe it didn't? No obvious signs of trouble were happening on my end. I tried what you suggested, but then I started seeing errors that indicated products could not be found or loaded onscreen. Switched it back real fast. @BrockleyJohn Do you mean turn off the IPN callback that I set up in my PayPal account? Funny thing is, I didn't even set that up until a couple of nights ago, thinking...maybe that's what's wrong? I had never enabled the IPN feature to start with. Didn't matter. Still getting errors. For what it's worth (not related to this, really) I've had PHP 7 errors with the new PayPal app. 5.018 [02-Jul-2018 11:47:46 UTC] PHP Deprecated: Methods with the same name as their class will not be constructors in a future version of PHP; paypal_standard has a deprecated constructor in /home/userxxx/public_html/includes/modules/payment/paypal_standard.php on line 17 Had to use a function __construct to clear that up. Wish the rest of my troubles were that easy to fix! Thanks, guys! - Andrea Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.