Al Brookbanks

True. Thanks for that.

Suggested cron to be something like; cd /path/to/public_html/modules/plugins/back_in_stock_notifications/cron/; /usr/local/bin/php -q back_in_stock_notifications_cron.php

I don't know why I am promoting this because I'll have a lot of work to do!

Please make your thoughts now and vote here: https://clickanddrop.uservoice.com/forums/399930-general/suggestions/33164668-develop-an-integration-with-cubecart

Please make your thoughts now and vote here: https://clickanddrop.uservoice.com/forums/399930-general/suggestions/33164668-develop-an-integration-with-cubecart

Royal Mail refuse to work with us. I'm sorry.

I've actually come across this before. The merchant sold lengths of rope.

The code could be adjusted to suit your requirements.

Decimal values are not accepted. Most merchants sell whole items.

@Noodleman Do you think we can update the extension to remove the .htaccess deny from all in the cron folder? Reason being is that it allows for not only cron jobs like; wget -q -O - https://www.example.com/modules/plugins/back_in_stock_notifications/cron/back_in_stock_notifications_cron.php >/dev/null 2>&1 Edit but also a web service like Easy Cron.

After authentication at PayPal the last button says "continue" then on return to the website the button says "make payment". I'm not sure what can be changed to improve it. Our integration has been certified by PayPal. I think maybe the confusion might arise in that historically the merchant might pay on the PayPal screen. It's very standard for PayPal integrations to work this way nowadays. The need to return back to the store in order to verify and taxes and shipping costs that might be applicable once the billing/delivery address is confirmed in the return data from PayPal.

In the php.ini set the session.gc_maxlifetime to 604800.. Hopefully that will help.

Auto empty? It shouldn't do that unless your session garbage collection time doesn't match the session length.

Phew!!! Thanks for letting me know. Sorry for the inconvenience caused.

This year has been rough for us all. I'm out the office until Friday with family in Suffolk, UK, working here and there. I'll have a good look at this on my return.

Increase the max_post_vars in PHP config.

It's definitely working.

It looks like you may be able to specify this in the php.ini file. https://www.php.net/manual/en/openssl.configuration.php openssl.capath = /etc/ssl/certs Or it may be possible to add a file to the root folder of your store called ini-custom.inc.php with content; <?php ini_set('openssl.capath','/etc/ssl/certs');

Interesting. Is it possible to tweak the openssl config to specify that default path rather than specifying it as an argument? https://security.stackexchange.com/questions/142159/how-to-get-openssl-to-use-a-cert-without-specifying-it-via-cafile https://www.phildev.net/ssl/opensslconf.html

Maybe digicert has resources for this. Their local certificate files must be public.

That does seem to verify what I am saying. Try it with this endpoint which is the one used for PayPal Commerce API endpoint. api.paypal.com This matches the endpoint in your request log above. Yes. I expect local issuer certificates can be imported to your server.

I haven't found much in the way of solutions to this. https://stackoverflow.com/questions/15773806/nss-client-certificate-not-found-nickname-not-specified This has come up a few times recently. It maybe that we can code it to check the certificate by adding a local path but I'm unsure at this time.

Just the old PayPal Standard integration.

It's something to do with the cURL openSSL configuration. I believe it's failing to validate the SSL certificate at the PayPal Endpoint. An experienced server admin should be able to resolve this. I don't believe there are any issues with our integration.

PayPal Checkout isn't PayPal Commerce.