Jump to content
Latest News: (loading..)
puggybelle

PayPal Standard 5.018 standard_ipn.php won't connect

Recommended Posts

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

Share this post


Link to post
Share on other sites
Posted (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 by Hotclutch

Share this post


Link to post
Share on other sites

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.


This is a signature that appears on all my posts.  
IF YOU MAKE A POST REQUESTING HELP...please state the exact version
of osCommerce that you are using. THANKS

 
Get the latest current code (community-supported responsive 2.3.4.1BS Edge) here

 

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.


For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce (2.3.4.1 CE) here: https://github.com/gburton/osCommerce-234-bootstrap/archive/master.zip

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites

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

 

 

 

Share this post


Link to post
Share on other sites

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.


I'm using the cutting Edge v2.3.4.1 CE:thumbsup::smile:

Get the latest osCommerce Online Merchant Community Bootstrap Edition v2.3.4.1 CE

 

Share this post


Link to post
Share on other sites

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.

 


For a new install or if your store isn't mobile-friendly, get the community-supported responsive osCommerce (2.3.4.1 CE) here: https://github.com/gburton/osCommerce-234-bootstrap/archive/master.zip

Working on generalising bespoke solutions for Quickbooks integration, Easify integration and pay4later (DEKO) integration at 2.3.x

Share this post


Link to post
Share on other sites

@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

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×