kiwiot

Hi John,

Yup totally agree and I actually dug deeper to find that one of my devs had set it incorrectly in the php.ini. That said ini_get is designed to return a string so shouldn’t the plugin code assume that it could be wrong ant type cast anyway?

https://www.php.net/manual/en/function.ini-get.php

Following this as well as I would like a solution

• This reply was modified 3 years, 7 months ago by kiwiot.

Oh ok – sorry I am confused then as the plugin on WP says last updated a month ago and the above bug report timestamps because of WP 5.5 updates are in the last couple of days/week so I assumed that it was not yet updated.

To be clear – your latest version 2.2.1 handles the path change of PHPMailer that is causing the bugs – I couldn’t find a changelog anywhere to confirm.

I totally get that – what I wanted to knopw is when is your plugin being patched?

Is a patch being worked on for this issue – It has occurred in multiple related plugins (no thanks to WP Code) – just want to know if there is a timeline for a fix.

For anyone who wants a quick fix to this jump in and wrap the defines

           if ( !function_exists('acf_add_local_field_group') ) {
                if ( ! defined( 'ACF_FREE' ) ) {
                    define( 'ACF_FREE', true );
                }
            }  else {
                if ( ! defined( 'ACF_PRO' ) ) {
                    define( 'ACF_PRO', true );
                }
                add_filter('lp_init' , array(__CLASS__,'acf_register_global') , 20 , 1 ); /* registeres a global of registered field values for support between ACF5 & ACF6 */
            }

Im seeing this on multiple sites now – wondering is any more has been done here

@angelleyesupport @kiwiot

No reports of blank pages from us – that was the other user. And no reports in the error logs, im sure of that.

I am still debugging this and waiting on the client to approve activating/dactiviating the plugin etc.

I ahve also asked the client to reach out to the customers that this happened to in the past to see if they did get a blank page and did not report it.

I’ll get back to you when I find out more.

I worked back through the sites error logs and nothing shows up. I can confirm that this has happened multiple times in the last month.

Happy to send you wc_logs of the transactions (privately)

I also reviewed the access log for the last duplicate order and found separate instances of the api being called mins apart

02/Aug/2017:19:50:27 +0000|v1|71.198.172.52||302|0|127.0.0.1:6789|1.223|1.223|GET /?wc-api=WC_Gateway_PayPal_Express_AngellEYE&pp_action=set_express_checkout HTTP/1.1|0|0
02/Aug/2017:19:51:16 +0000|v1|71.198.172.52||302|0|127.0.0.1:6789|1.255|1.255|GET /?wc-api=WC_Gateway_PayPal_Express_AngellEYE&pp_action=set_express_checkout HTTP/1.1|0|0
02/Aug/2017:19:54:02 +0000|v1|71.198.172.52||502|1175|127.0.0.1:6789|80.725|80.725|GET /wc-api/WC_Gateway_PayPal_Express_AngellEYE/?pp_action=get_express_checkout_details&token=EC-45W25391BF551111N&PayerID= HTTP/1.1|0|0
02/Aug/2017:19:55:57 +0000|v1|71.198.172.52|www.lunchbots.com|499|0|127.0.0.1:6789|-|99.674|GET /wc-api/WC_Gateway_PayPal_Express_AngellEYE/?pp_action=get_express_checkout_details&token=EC-45W25391BF551111N&PayerID= HTTP/1.1|0|0
02/Aug/2017:19:56:01 +0000|v1|71.198.172.52|www.lunchbots.com|499|0|127.0.0.1:6789|-|2.613|GET /wc-api/WC_Gateway_PayPal_Express_AngellEYE/?pp_action=get_express_checkout_details&token=EC-45W25391BF551111N&PayerID= HTTP/1.1|0|0

Note the payer ID was set but I removed it along with the sites URL this was pulled from.

Definitely a duplicate bug though.

Same issue – however no reports that I know of regarding a blank screen. Will do some research into logs to see if I can find more info

Same issue – is this being fixed as its a big one

@boazpojo I am having this smae problem. Only occurs on production version of wp-engine, not on staing. Install are identical.

Running latest verions of everything

Its up to the plugin developer to include it – but yes of course it can be integrated on the discretion of ILLID as its his.

I currently have no interest in doing this myself as this is a free plugin and he also has a premium version so he may be motivated to make this happen for his own customer base.

• This reply was modified 7 years, 10 months ago by Jan Dembowski.

This can be solved however it is an involved process of restructuring the plugin, something that Mihail (the plugin developer) might want to add in the future.

As a plugin developer myself, whenever clients ask for custom migrations or handling large databases or posts/products etc I use the cron job background processing approach.

https://github.com/A5hleyRich/wp-background-processing

What this does is queue up all the products are run them one by one in the background over a set period of time in my case I default to 0.5 sec per entry. So ion your case thpstock 3000 products would index over a period of 25 mins in the background.

The reason it is hanging is due to processing power and timeout settings on your server – the above approach gets around this.

This is also the method that Woocommerce uses – that same code in the link above is baked in the Woocommerce plugin.

Regards,
Jared

Also had the same issue.

Notice: Undefined index: o:tag in /mailgun/includes/wp-mail.php on line 154

File to change : /mailgun/includes/wp-mail.php

The mailgun plugin is assuming o:tag has been declared. My fix is to change line 154

if ($body['o:tag']=='') {

to

if (!isset($body['o:tag'])) {

One can assume that the else call looks at lines 146-149 which would previously declare tags so I dont think any extra logic would be needed, however if you would like to be extra cautious change the block of code to define o:tag and then use the same mailgun logic

// campaign-id now refers to a list of tags which will be appended to the site tag
	if ( isset( $mailgun['campaign-id'] ) ){
		$tags = explode(",", str_replace(" ","", $mailgun['campaign-id']));

		if (!isset($body['o:tag'])) {
			$body['o:tag']= '';
		}
		if ($body['o:tag']=='') {
			$body['o:tag']= $tags;
		} else {
			$body['o:tag'].=','.$tags;
		}
	}