Plugin conflict with WooCommerce Store Exporter

I’m not making any use of mod_mime_magic either. I also don’t have any jQuery actions tied to any buttons on the admin side. There are a few simple jQuery things I use to sort tasks, and to add date and time pickers to my fields, and to toggle the display of certain fields, but no actions hooked to any buttons.

My best guess is that, by pure coincidence, they may have set up the export action in exactly the same way my exporter works. My exporter looks to see if there is a REQUEST variable of “action”, and if that variable is set to “export”. If so, then my exporter function is called to export data. My exporter, for security purposes, checks the security nonce, and if it doesn’t match, it will throw the type of error you are seeing.

So, in other words, it’s the other way around… that other plugin just so happens (most probable case) to be using the same “action” => “export” argument settings to trigger an export as I do, causing my exporter function to intercept it and check for proper admin referrer.

Thanks for your note–let me share with the other developer and get back to you?

Yes, if that is indeed the cause of the conflict, then one of us needs to change the name of our action.

Have you tried deactivating my plugin first and then seeing if theirs works, to make absolutely sure it’s not some other plugin causing that conflict?

Yes I have. my apologies for not making that clear earlier.

I systematically left the report plugin on and then turned others off and tested. What gave me the first clue was it was PTA Volunteer Sign Up Sheets was a failure error when I tried to turn off PTA Volunteer Sign Up Sheets and PTA short-code by picking both via check box and then select deactivate in the drop down. I got the same error: ‘Are you sure you want to do this?’

Sorry I did not share this before. This occurs independent of the store export plugin being on or not.

Hi DBAR, yup the exact above scenario is happening, we’re both checking $_GET or $_POST ‘action’ and doing something on ‘export’ within the WP Admin. In our Plugin we return false whenever a $_POST element unique to our exporter doesn’t exist as well as check against check_admin_referer().


// Make sure we play nice with other WooCommerce and WordPress exporters
if( isset( $_POST['woo_ce_export'] ) && !check_admin_referer( 'manual_export', 'woo_ce_export' ) )
return;

(not sure how WP.org forums deals with markup)

Is it possible for you limit your security nonce check to Sign-Up Sheets screens and below rather than globally as there will be other Plugins using the export action combination ??

(if there’s a better way to share this action without triggering the security notice I’m all ears, I’m learning everyday)

Sorry guys, was in the recording studio with clients all day, so haven’t had time to follow up.

@visser, if you changed your code like you pasted above, and use $_POST[‘woo_ce_export’], then that should fix the problem. My exporter works on GET query arguments, so it’s looking for $_GET[‘action’] = ‘export’. Only if that action is set do I then check the admin referrer. So, if you made the change as indicated by the code you pasted, I would think that should solve the conflict.

To prevent redundancy, I use the same Exporter class for a few plugins, so if I changed one, it breaks the others. I would need to change them all at once… I could do it, but super busy all week in the recording studio, so it probably wouldn’t happen this week.

Hi DBAR, that codes live so I’ll leave the ball in your court, have fun in the studio ??

Thank you both for talking this through. @dbar if you decide to make these changes and need them tested, I own most/all of your plugins. Just let me know.

@visser — was that change already in place, or something you just made live after this topic was posted?

@mrpatulski – are you still having the same problem with the new code that Visser modified (if that was a new change)?

Just trying to figure out if this is resolved for now, or if it’s something I still need to take a look at sometime after this week.

Hi DBAR, that snippet was already in place – it’s not new – so I’m expecting your Plugin and security check is executing ahead of ours.

We run woo_ce_admin_init() at priority 11 so almost everything else is ahead of us in the priority queue for admin_init.

@visser — OK… thanks for the info. I’ll take a closer look next week when I have more time. Is this happening with the free version of your plugin, so I can test them together?

If yours is set to trigger on the $_POST[‘woo_ce_export’], then I will have to dig deeper to see why mine would still be doing the security check (if that is indeed what is happening) since mine only does the check_admin_referer function call if it first sees a REQUEST action = ‘export’. I checked that in my exporter class yesterday to make sure. Obviously, if I was doing the check_admin_referer function call against every admin request, I would be breaking a lot of other plugins as also since they wouldn’t be using my nonce.

The “are you sure you want to do this” error message is definitely the result of a bad check_admin_referer call, so, when both of our plugins are activated, somebody’s check_admin_referer call is getting called when it should not be.

Have you tried moving your check_admin_referer out of that if statement, so it is more like:

if( isset( $_POST['woo_ce_export'] ) ) {
   check_admin_referer( 'manual_export', 'woo_ce_export' );
   // do csv export stuff here
}

That’s basically the way mine is set up. First check if there is the POST variable you are looking for, then you can just call check_admin_referer on it’s own line… don’t have to put it in an if statement, because it will die with that error message automatically if the nonce doesn’t match.

Here is my code:

$export = isset($_REQUEST['action']) ? $_REQUEST['action'] : '';
		if ($export == 'export') {
			check_admin_referer('pta-export');
			if (!current_user_can('manage_options') && !current_user_can('manage_pta'))  {
	            wp_die( __( 'You do not have sufficient permissions to access this page.' ) );
	        }

	        // Grab the option name where the report is stored, or use the default location
	        $data = isset($_REQUEST['data']) ? $_REQUEST['data'] : 'pta_reports';

			if ( !$report = get_option($data) ) {
				wp_die( __( 'Invalid Report Data!' ) );
			}
			echo $this->export_report($report);
			exit;
		}

@dbar I originally encountered this issue when PTA-VSUS and the paid version of @vissers WCE plugin were both activated. I did further testing and found it does the same thing with the free version of WCE too.

OK… had a bit of free time this evening, and downloaded the free version of the WooCommerce Store Exporter, I can confirm the conflict.

Searching through the exporter code (with a find in my editor), I can’t find any place where the check_admin_referer function appears, so maybe that is only in the pro version???

I see that the exporter function is looking for Get or Post “action” and checking for various actions, including “export”, so I can see that is where the conflict is, since both plugins are looking for the same argument and setting, but mine does a security nonce check which is failing since the exporter is not using the same nonce (or, not using any security nonce at all, at least not that I can find in the free version).

Also, that notice you get when trying to deactivate 2 plugins at once is unrelated. I used some recommended code in my deactivation routine to check the nonce when my plugin is deactivated, but I guess that doesn’t work for bulk deactivate actions, so I’ll remove that nonce check in a future release. But, that’s a totally separate nonce check in a different piece of code.

So, one of us needs to modify our plugin to add some sort of prefix to the “action” argument or the “export” action. Since I have several plugins that use the same exporter class, that is a more tedious process for me at this point and also affects the big PTA Manager system I have running on my son’s school PTA web site (which my 2 plugins here are just a small part of).

If Visser Labs is willing to change theirs, it might be a quicker and easier fix. If not, I will change mine, but it will take a bit more time since I need to make sure I change it across several plugin and make sure I don’t miss any places where I used it (there are quite a few places in my PTA Manager plugin that set up reports for CSV export).