Conflict with Pods plugin

and each side is blaming the other, see for example

well, that’s a little harsh! I only pointed out that I didn’t use pods and therefore could not help out. I don’t use and likely never will use Pods as it adds unnecessary bloating on your server, since it only adds an additional layer to WP core functionality…

and there is a discussion here of the likely cause
https://github.com/pods-framework/pods/issues/6087

the cause is squarely in Pods’s court as it provides no mechanism to disable it on certain admin pages such as the Smart Grid which happens to use the wp-admin/post.php as the form editor admin page. Pods assumes this is another custom post page and dishes out all of its functionality….which is not required on the form editor!

anyhow, long story short, here is a hack to disable it. It hooks into the Smart Grid’s admin process which fires only on the form editor page and simply stops all the conflicting scripts from loading. It does not disable Pods altogether, which still runs on the form editor request, and still loads its stylesheets (you could extend the below logic to unload the stylesheets too). It results in the editor loading properly.

add_action('cf7sg_enqueue_admin_editor_scripts', 'disable_pods_on_wpcf7_contact_form');
function disable_pods_on_wpcf7_contact_form(){
  debug_msg('disable_pods_on_wpcf7_contact_form_2');
  if(is_plugin_active('pods/init.php')){
    include_once PODS_DIR.'classes/PodsInit.php';
    remove_action('admin_enqueue_scripts', array(PodsInit::$instance, 'register_assets'),15);
  }
}

@sharmpro

Thank you for the quick response (a nice contrast with the silence from Pods devs)!

I withdraw my harsh criticism and confirm that the hack works.

I’ll take a look at your issue Phil. I haven’t looked at new non-2.8 reports on GitHub since last week and haven’t had a moment to catch up there. That’s just how it goes, not really silence if we are all focused on all sorts of things for everyone else ??

I’ll work on adjusting the admin script handler to work with the new and improved Pods 2.8 logic that can enqueue only if that screen is for a covered Pod.

• This reply was modified 3 years, 3 months ago by Scott Kingsley Clark.

I was able to sort out the issue and get it solved in Pods 2.8 (beta). Should go into Release Candidate this or next week.

I was able to sort out the issue and get it solved in Pods 2.8 (beta). Should go into Release Candidate this or next week.

nice one @sc0ttkclark! Is there some hook plugins should use to switch off pods on specific admin requests?

I withdraw my harsh criticism and confirm that the hack works.

@phil-mckerracher I am marking this as closed for now.

The code snippet you had should work for this specific case without detriment to how Pods works on other areas.

Indeed, but its not very clean as there are still stylesheets being loaded and other server side resources running.

A hook to turn off Pods on specific pages would be cleaner.

How do you handle it in v2.8 ?

Thank you @sc0ttkclark for such a speedy and comprehensive solution, and @aurovrata for the workaround which got me going again in the meantime, both extremely helpful.

Sorry if I sounded testy – it wasn’t a personal criticism, just frustration at the time wasted (mine and others) when I discovered the problem has been known about for years. I guess reproducability is the issue.

@aurovrata The code I have updated for Pods 2.8 will not enqueue anything if it does not meet the new criteria. It only registers the assets for on-demand usage later on in other areas for use as needed.

@phil-mckerracher no worries, I’ve had my hands full with Pods 2.8 and trying to get it ready for release. Our support contributors don’t follow GitHub as closely as we do our forums and our Slack so I’m glad you bubbled this up another way which I just so happened to be listening in on for the keywords ??

Wonderful @sc0ttkclark, good luck with the release of v2.8. Have a good day!