Error. Please contact Support for assistance / No reponse emails

#1

We have been using s2member for years. small team of 3 programmers… we can usually find the problem, but, this one has us stumped.

I’m sure it’s our site problem… not s2… we just don’t know where to look. No logs show any info other than…

Error. Please contact Support for assistance

We are using Auth.net , on a wordpress site , all updated, php 7.133, we also have SSL, and long time users… I also contacted Auth.net support, and they didn’t see anything wrong on their end.

Customer selects product. inputs information. selects pay now… and then get’s that error. SOMETIMES… they don’t get the error… like when I personally do it. so it’s hard to isolate.

none of the customers get the thank you or response emails… but… some get redirected to the proper page.

I guess the problem for us is… we can’t see any good info about the errors or direction where to look.

Any clue on where to start searching? we’ve been at this for the past 6hrs… and no luck

#2

As we are working on it… it seems maybe it may be related to a CURL timeout issue. the payment is sent to auth.net… and auth.net replies… but… it doesn’t process in time? does that make sense? or are we barking up the wrong tree?

We’ve been able to identify which customer have paid, but, hadn’t had accounts setup for them yet. so… now… we are doing those customers that don’t accounts, manually creating… that’s holding us off from getting too many complaints… but. it’s obviously not a solution

#3

31%20PM
Screen Shot 2020-06-11 at 12.43.31 PM.png2468×886 338 KB

I feel like this is a false negative… as we are running 7.1… and the tool is old… but… we are looking at everything…

#4

image_2020_06_12T06_48_31_731Z
image_2020_06_12T06_48_31_731Z.png928×442 24.6 KB

Here is what we get from the s2-http-api-debug.log file…

Please… help???

#5
  1. Ignore the s2member serverscan utility…it is out of date and the results incorrect
  2. See Stripe Network Communication Error for discussion of recent curl error problems
#6

We are using Auth.net would I do the same thing as in that thread, change that setting to FALSE? but in the auth.net folder?

Secondly.,… our issue only happens intermittently. We are thinking server resources? maybe? We have a GoDaddy VPS, with 16gb ram. running WHM and Cpanel.

FYI:
cURL version
7.69.1 OpenSSL/1.1.1g

WP_MAX_MEMORY_LIMIT
512M

#7

Re-read the thread…the solution is about CURL in PHP. It is not Stripe-specific.

#8

uhmmm… ok… I did… the solution you had in there was $enablePersistentConnections = false; which you said is NOT a solution. You also refer to Auth.net compatability and some potential fix that you will need to do.

But, ok… i’ll continue in that thread, seeing as you are telling me to re-read it.

#9

Apologies if my reply appeared rude…that was not how I meant it to come across.

The $enablePersistentConnections = false is a Stripe-specific setting for solving this issue. And that issue was related to (Network error [errno 2]: easy handle already used in multi handle). Your issue is error 28 which is a timeout.

The reason I pointed you at the thread was to indicate that others had CURL-related problems just show up when their host upgraded their libcurl without their knowledge. It was also to show you all the things you need to do to track this down: confirm you were not upgraded to php7.4, confirm your libcurl was not upgraded, confirm that you restarted the server after the change, etc.

Your CURL timeout is likely server processing load related or network latency related. It will depend on where you are in the world and what is going on with your server. For example, if a client transaction occurs at the same time as you are in admin AND your server is doing a scheduled backup, then you might see this error.

So the recommendation is for you to talk to your hosting company, try to figure out what changed on the date that you started noticing this error, start to log your server performance stats so you can correlate the issue with a server over-commitment (which is tough on a share hosting site since there is performance limits in your slice and performance limits of the underlying server…so log the cycle steal time see https://scoutapm.com/blog/understanding-cpu-steal-time-when-should-you-be-worried).

#10
  • not PHP 7.4 (we’ve tried 7.0, 7.1, 7.2)
  • libcurl is older version
  • last Server Reboot was 2 mos ago, then 2 weeks and 4 days ago was a Patching Notification
  • we are on a self run VPS from Go-daddy… they suck… and don’t want to help unless more $$$
    *i’m physically in Philippines, but, the server is in Arizona, and customers are in USA… so… i don’t think that makes a difference right? Also, i’ve tested it with my own CC. and it didn’t replicate. I would really love to be able to replicate it somehow, any ideas on how to load up that server?

We did find a script from Wordpress that has seemed to help a bit… that was a hotfix function from May last month…

Also, we are working on going through some of our custom code, and closing sessions more aggresively.

We don’t think it’s timing out, as it’s an instant issue when the user clicks “buy now”. No time passes to the customer from what we undertand.

Since it was intermittent, we’ve used the Health Report from WP to know if we are making progress.

Also, after that WP hotfix code, our error looks different in the logs… which feels like progress to us

#11

What WP hotfix did you apply and what is the new errorcode?

#12

/**

  • Write session to disk to prevent cURL time-out which may occur with
  • WordPress (since 4.9.2, see ),
  • or plugins such as “Health Check”.
    */
    function custom_wp_fix_pre_http_request($preempt, $r, $url)
    {
    // CUSTOM_WP_FIX_DISABLE_SWC can be defined in wp-config.php (undocumented):
    if ( !defined('CUSTOM_WP_FIX_DISABLE_SWC ') && isset($_SESSION)) {
    if (function_exists(‘get_site_url’)) {
    $parse = parse_url(get_site_url());
    $s_url = @$parse[‘scheme’] . “://{$parse[‘host’]}”;
    if (strpos($url, $s_url) === 0) {
    @session_write_close();
    }
    }
    }

return false;
}
add_filter(‘pre_http_request’, ‘custom_wp_fix_pre_http_request’, 10, 3);REST API, Loopback issues - plus PLugin looks abandoned - WP Customer Areahttps://wp-customerarea.com

#13

https://wp-customerarea.com/support/topic/rest-api-loopback-issues-plus-plugin-looks-abandoned/

But sadly… it didn’t work. we also tried to go to 7.1 --> 7.4 and that broke other things in the main theme… so… we reverted back to 7.0 PHP… We are upgrading gravity forms and the theme to allow us to go to 7.4. but I don’t think that’s the solution

#14

I wouldn’t put this patch in place unless you have really reverse engineered it thoroughly. It’s trying to close a php session initiated by another plugin. I can see a lot of side-effects to this.

If you want to determine if this is, in fact, your problem…scan your plugin directory for session_start to see if another plugin you have installed is using php sessions. If none of your plugins use php sessions then this is not a potential cause of your problem.

I re-read your original post and it looks like the curl timeout is from your WordPress site trying to contact the payment gateway vs. the problem other had with the gateway timing out calling s2member.

I would suggest you may be having intermittent network delays. What country is your server in vs. what country is the auth.net server in. COVID work-at-home has triggered a massive drain on the world’s Internet.

You can try some ping / tracert tests to the auth server from your server from a terminal session on your server to see what kind of response you are getting from auth-net.

#15

Hi, we are beating our heads against all walls here. We are loosing 30% revenue daily due to this problem. We are thinking it maybe a server problem. Which is weird, as we have 3 sites, all using s2member, and they are all getting it.

The problem is INTERMITTENTLY… we can’t reproduce it… but, we see it happens. Here is what we got so far.

  1. We did go through, and scan for session open. closed all those loops…
  2. We upgraded one site to php7.4 and the others at 7.0
  3. We updated WP and left it as old
  4. We have an old verions of Curl 7.19 comes to mind, but, I can’t remember.
  5. We thought the intermittent part was a memory thing, but, the pic below shows unrealted
  6. we hacked s2 to also send a message to us and the customer to let them know that we know it happend, we applogize, and then create an account for them… this SUCKS. but… for now. ok.

To recap, intermittently, the customer inputs their info on the paypage, hits submit, they get an error. The money is taken out of their account but, they don’t get an account created on WP.

FYI, sometimes, they try repeatedly, and then it works… each time money deducted, so they get charged 3-4 times to get one account created. So, we think it’s not browser or IP related.

It points to the server… I know… but… I can’t recreate it… and I dunno what to check to see why the call back is being “blocked”… oh… we also turned off WordFence, and whitelisted Auth.net IP addrss…

#16

Re-read my previous post. You ignored it. I suggested you test for network problems between the server and the gateway using ping, tracert, and if needed…network traffic logging.

#17

Aww… come on man… I didn’t ignore it. LOL. I read it like 5x and had my guys read it, and I copied and pasted it in our daily scrums… I just didn’t respond specifically to it. We tried TRACE, and it worked every time “we did” it. We couldn’t get it to repeat. Next step with that is a Chron job, for 24hrs, every 10 minutes ping auth.net. to see if it can replicate it. Unfortunately, we don’t have credentials to send that will activate a data reply from auth.net. but, they do send someting

It is some kind of network or connectivity issue, that is intermittent. and it affects Curl.

Next overall step is to upgrade server from cent os 6 to 7, and upgrade Curl.

Do you recommend a good server or s2 guy that can help diagnose? that we can hire for a few hours on our system?

#18

You guys are thorough…I will give you that…I only said you ignored my network test suggestion because you didn’t mention it in the list of steps you had taken.

So…based on everything you have done so far…you have pretty much covered all the usual suspects. So now it gets trickier to debug.

You said the bug is intermittent and you have yet to reproduce it, but your clients are reporting the issue. So two things…

  1. How often is this happening. If it happens once a day then there are options to tracking it down. If the problem is being reported once a month then it is more difficult.

  2. Look for more patterns. Time of day, day of the week, client type (desktop / mobile), client O/S (windows, mac, ios, android, linux), browser (chrome, firefox, edge, safari). For example we had a bug reported that someone could not enter the CVC on the pro forms…turned out to only be a problem on Safari on IOS. So problems can be very narrow when you ultimately track them down.