John,
Is your host running Varnish or another type of caching at the server level?
Stripe - multiple trial installments
Tim,
Thanks for your feedback… The answer is no, I’m the hosting… I compiled everything myself so I know exactly what is installed…
1 Like
Thanks for getting back…
It is pretty plain vanilla… I compiled by hand, apache and php myself so I know exactly what switches that were used… (On CentOS 7, also installed by me)
The compile was:
./configure
–prefix=/usr/local/apache
–enable-rewrite
–enable-so
–enable-ssl
–enable-setenvif
-with-pcre=/usr/local/pcre
Loaded Modules are:
core_module (static)
so_module (static)
http_module (static)
mpm_event_module (static)
authn_file_module (shared)
authn_core_module (shared)
authz_host_module (shared)
authz_groupfile_module (shared)
authz_user_module (shared)
authz_core_module (shared)
access_compat_module (shared)
auth_basic_module (shared)
socache_shmcb_module (shared)
reqtimeout_module (shared)
filter_module (shared)
mime_module (shared)
log_config_module (shared)
env_module (shared)
headers_module (shared)
setenvif_module (shared)
version_module (shared)
ssl_module (shared)
unixd_module (shared)
dav_module (shared)
status_module (shared)
autoindex_module (shared)
dav_fs_module (shared)
dir_module (shared)
alias_module (shared)
rewrite_module (shared)
php7_module (shared)
(Note: you may notice socache_shmcb_module (shared) above and wonder… my understanding is that this is a key-value cache used for storing SSL sessions and authentication details and not for content, The module mod_file_cache would be used for content, which is not installed.)
PHP compile was:
./configure --with-apxs2=/usr/local/apache/bin/apxs
–with-mysql=/usr/lib64
–prefix=/usr/local/apache/php
–with-config-file-path=/makeusr/local/apache/php
–disable-cgi
–with-zlib
–with-gettext
–with-gdbm
–with-gd
–with-png-dir=/usr
–with-jpeg-dir=/usr
–with-freetype-dir=/usr
–with-zlib-dir=/usr
–with-mcrypt=/usr/lib
–enable-mbstring=all
–with-curl=/usr/lib
–with-curlwrappers
–enable-ftp
–enable-pdo=shared
–with-pdo-sql-shared
–with-pdo-sqlite-shared
–with-sqlite-shared
–enable-intl
–with-libdir=lib64
–enable-soap
–with-mysql=mysqlnd
–with-mysqli=mysqlnd
–with-openssl
If you are familiar with the above you can see it is quite standard… I only compile components I specifically need, I leave little to chance, if I can help it. There is no caching that I had any control over.
The only thing I can imagine, it is a pretty wild, wild idea is that my ISP is doing something… I run the office off of satellite (Hughesnet). I think I’ll test this by going over to my daughter’s house. She has cable and I’ll see if there is a difference. Thing is, if it is that, then my client will have customers that CAN’T use their website, somehow that is not going to work.
Is there anything I can monitor to detect what is causing it to re-trigger the do_action(‘init’,…) ??? I’m pretty certain base on my previous testing that this is what is happening. In the beginning of this thread I hacked some logging locations and got the following:
stripe_checkout - line 76 - pre validation check
stripe_form_submission_validation_errors
stripe_checkout - line 76 - pre validation check
stripe_form_submission_validation_errors
Email exists - checkout
Notice that the functions for checkout and validation get called twice… The backtrace on a single call is:
file] => /usr/local/apache/htdocs/peer-pods/dev/wp-content/plugins/s2member-pro/src/includes/classes/gateways/stripe/stripe-checkout-in.inc.php
[line] => 81
[function] => stripe_form_submission_validation_errors
[class] => c_ws_plugin__s2member_pro_stripe_responses
[file] => /usr/local/apache/htdocs/peer-pods/dev/wp-content/plugins/s2member-pro/src/includes/classes/gateways/stripe/stripe-checkout.inc.php
[line] => 58
[function] => stripe_checkout
[class] => c_ws_plugin__s2member_pro_stripe_checkout_in
[file] => /usr/local/apache/htdocs/peer-pods/dev/wp-includes/class-wp-hook.php
[line] => 286
[function] => stripe_checkout
[class] => c_ws_plugin__s2member_pro_stripe_checkout
[file] => /usr/local/apache/htdocs/peer-pods/dev/wp-includes/class-wp-hook.php
[line] => 310
[function] => apply_filters
[class] => WP_Hook
[file] => /usr/local/apache/htdocs/peer-pods/dev/wp-includes/plugin.php
[line] => 453
[function] => do_action
[class] => WP_Hook
[file] => /usr/local/apache/htdocs/peer-pods/dev/wp-settings.php
[line] => 467
[function] => do_action
[file] => /usr/local/apache/htdocs/peer-pods/dev/wp-config.php
[line] => 97
[file] => /usr/local/apache/htdocs/peer-pods/dev/wp-load.php
[line] => 37
[file] => /usr/local/apache/htdocs/peer-pods/dev/wp-blog-header.php
[line] => 13
[file] => /usr/local/apache/htdocs/peer-pods/dev/index.php
[line] => 17
…so you can see that in a normal call stack for checkout , stripe_checkout APPEARS to only get called ONCE. Something is causing it to get called twice, I believe that is…
do_action(‘init’, ‘c_ws_plugin__s2member_pro_stripe_checkout::stripe_checkout’);
The cause of this problem is not unheard of… (posted a link earlier in this thread on that issue)
Can you forward this to one of the programmers…??? Maybe something will click??
Maybe some good news…!!
Spent the last several days, and many, many hours since my last post struggling with this issue…
Here is my latest trip down this rabbit hole…
At one point, while beating my head against this problem, I remembered seeing an error in the php error.log from the phpmailer with respect to the ssl cert…
error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed in…
So I spent several hour tracking down this issue as a possible cause. Basically I found that everything seemed to be configured correctly on the server…
Ran…
/usr/local/apache/php/bin/php -r “print_r(openssl_get_cert_locations());”
Array
(
[default_cert_file] => /etc/pki/tls/cert.pem
[default_cert_file_env] => SSL_CERT_FILE
[default_cert_dir] => /etc/pki/tls/certs
[default_cert_dir_env] => SSL_CERT_DIR
[default_private_dir] => /etc/pki/tls/private
[default_default_cert_area] => /etc/pki/tls
[ini_cafile] =>
[ini_capath] =>
)
and confirmed that the .pem file was actually at that location… Then to validate that it was a viable cert… Ran that cert against a well known mail server.
echo QUIT | openssl s_client -crlf -starttls smtp -CAfile /etc/pki/tls/cert.pem -connect smtp.gmail.com:587
I won’t post the output here, (very long) but it returned what was expected from a valid configuration.
So… that got me thinking that maybe the mail server itself that I had been using, and was configuring the SMTP plugin to, might be causing the above error, and therefore causing the do_action(‘init’,…) to re-fire more than once, which I had previously confirmed was the key trigger of my problem. ( Note: I also had found a number of posts indicating that any resource problem can potentially cause that re-firing…)
As a side note on that… I did find a post from a fella that was also struggling with a similar problem with the do_action(‘init’,…) and he posted an interesting solution using add_filter_once(…)… Here is that post, maybe this might be considered here??
So, back to the rabbit hole… since I had verified the cert against the gmail server I decided to configure the SMTP plugin to use the smtp.gmail.com server.
The first try failed, but I realized that there may be some caching of the configuration on the web server so I restarted the Apache instance.
Bingo… It worked…!!
I’m out of time for today, so I need to hammer on this a bit more to make sure it was not a fluke, but I’m hopeful…
1 Like
Heh, heh… cute…
1 Like
I wanted to wrap this thread up for anyone else that might fall down this rabbit hole…
This thread started, when I was asking about the possibility of essentially having two subscriptions at the same time.
That answer was NO, but since it is allowed in the Stripe API, Hopefully it have been added as a feature request.
As I was testing this, I encountered a different error, and that was when I started getting the error: “…that email is already in use…” When in fact it, that email, was not in use. After much testing it was found that the do_action(‘init’…) for the check_out function was getting fired twice. More research revealed that this had happen to others and the apparent cause was triggered when WordPress encounters a missing resource or an error in loading a resource during that function call.
So… going deeper into that rabbit hole I found that Wordfence and the SMTP plugins were the source of whatever was causing this resource failure in this WPress installation.
Problem was, that the SMTP plugins was critical for this installation, so a solution needed to be found. After much searching through error logs it was found that there was a problem loading an SSL cert verification. Testing the server’s OpenSSL installation revealed no problems which then suggest that maybe it was the call to the mail server.
This turned out to be the case and after testing a number of email servers it was found that Gmail was the only one, I had access to, that did not encounter/trigger that error.
This then allowed the Stripe check_out function to work properly (only firing once, instead of twice). A possible solution within s2member was also found and posted in the thread.
I have not gone back to research Wordfence issue as of yet… not immediately critical so I’ll get back to that at a later time.
Hopefully I’ve left a number of useful breadcrumbs for others and maybe even it might be “fixed” such that others would never fall down this rabbit hole in the future.
1 Like
Just a note here to be sure one of your plugins is updated.
1 Like