let me put it this way. the plugin (wppizza that is) doesn’t care one iota what kind of session handling the server uses. files, memcache,memcached or whatever else they/you want to use
all it cares about is that sessions work. if they do not , then the setup is simply wrong . there’s 100% nothing the plugin (author) can do about it or “suggest” other than “fix your server setup. I know nothing about it”

i can give you a hint though: if using memcache, the session.save_path should most certainly not be /tmp (which is what it looks like looking at your configuration you sent)

PS: there is always an – outside – chance though that some other plugin messes around with these things , but suffice to say, it isn’t wppizza, i can assure you

>response from hosting provider
>I tried to find some information regarding this error from a trustful source but to no avail.

seriously ? they have heard of google , right ?

https://www.google.co.uk/search?q=PHP+Warning%3A+session_start%28%29%3A+Cannot+find+save+handler+‘memcache’+–+session+startup+failed

from your debug log

[13-Apr-2018 18:46:11 UTC] PHP Warning: session_start(): Cannot find save handler ‘memcache’ – session startup failed ……

that needs to be fixed (you should speak to your host)

if you are talking about the images there’s an option in wppiza->layout->Menu Item Images “pretty photo”
which will open an image in a lightbox kind of thing , other than that , there might be some other plugins that do things like that , but i have no idea

ahh, now that makes sense , because it means that the notification message (at ipn.php) gets sent multiple times back to the server as otherwise you would not ever receive the normal order confirmation email
(this seems to happen only sometimes from what i can see and for reasons only ebay would be able to track down. might be waiting for a timely server response or any other reason, i don’t know)

in a nutshell, the order execution goes like this (there are a few other steps , but to keep it simple)

notification received at ipn, look for an order that has status “inprogress” or “unconfirmed” for that id.
if found, execute order, sending emails etc. once that’s all happened set status to “completed” – done

if the same ipn gets sent again, it will be looking for that “inprogress” status , however, it does not exist anymore as it is now “completed” (as we do not want to execute that order multiple times of course)

that’s as an explanation and it’s the only way i can see this happening

as there is a possibility somewhat, that other gateways might do the same, i will add something to the plugin (that’s the main wppizza plugin) to account for this. As I am in the middle of tearing a number of things apart an update is quite a few days away yet, so in the meantime, you could edit a corefile as follows (assuming you are familiar with simple php editing)

in wp-content/plugins/wppizza/classes/class.wppizza.order_execute.php you will find at approx line 1166

/* error details */
$result['error'][] = array(
'critical'=> $critical, /* force sending of email to admin */
'error_id'=> 30007,
'error_message' => __('order not found using order id','wppizza-admin'),
'wp_error' => ''
);
/* logging, and sending */
$this->gateway_logging($result['error'], $gateway_reply, $order_id, $this->wppizza_gateway_ident, 'get-prepared-error');
/*
ipn, just return false !
*/
return false;

edit this to be the following

/* 
if we receive ipn notifications multiple times for the same order, the status will already have changed to completed, 
so before throwing errors, check if that is the case and if so , simply ignore
*/
$order = WPPIZZA()->db->fetch_order_details(false, $order_id, false, array('COMPLETED'), $wp_user_id);
if(!empty($order)){return;}
/* error details */
$result['error'][] = array(
'critical'=> $critical, /* force sending of email to admin */
'error_id'=> 30007,
'error_message' => __('order not found using order id','wppizza-admin'),
'wp_error' => ''
);
/* logging, and sending */
$this->gateway_logging($result['error'], $gateway_reply, $order_id, $this->wppizza_gateway_ident, 'get-prepared-error');
/*
ipn, just return false !
*/
return false;

save (and make a test order i would suggest)

i’ll add something like that to the next update

if you still have issues once this is added, please let me know.
while making sure that this works, maybe you could also perhaps enable
“Log successful orders” /wp-admin/edit.php?post_type=wppizza&page=settings for a few days
as it might give us a better idea/clue in case the above does not rectify the issue

(if it all works , after letting things run for a while, you can turn this off again)

just did a test on your site and it works just fine…?!
any particular items in cart or checkout details you can give me so i can reproduce this ?

got a link ?

that’s just offensive
feel free to write your own plugin, maintain it over the years keeping things backwards compatible for old php, mysql versions while also accounting for endless variations of server setup, adding forever new things for your 1000’s of users , reply to literally thousands of support requests / emails / forum topics and then come back to me complaining

in any event , that get_orders_orderhistory is a leftover from v2 and is only used in the order history and will probably be removed at some point in favour of a wrapper that will then use the fetch_order_details which will then allow queries that are not as restrictive as they are at the moment with the output being formatted as opposed to just the raw data and a bunch of other options

https://docs.wp-pizza.com/developers/?section=gateway-filter-frontend
in conjunction with

https://docs.wp-pizza.com/developers/?section=global-wppizza-functions
->WPPIZZA_IS_PICKUP

i would have thought