Ok. I fixed this by hacking the pods core, but unless I'm missing something this is a problem that needs to be fixed by pods team in next update.

For the fix, I changed /pods/init.php lines 199-120

FROM

wp_enqueue_script('jquery');
wp_enqueue_script('pods-ui', PODS_URL . '/ui/js/pods.ui.js');

TO

if (is_admin()) {
      wp_enqueue_script('jquery');
      wp_enqueue_script('pods-ui', PODS_URL . '/ui/js/pods.ui.js');
}

And another issue... PODS calling session_start(); in front-end during the WordPress init hook. That's going to cause problems if any of your front-end pages include classes and store them in the session (when you call session_start(), php deserializes objects stored in the session and so the class must already be included.

Anyway, I don't think PODS should be starting sessions on the front-end (why?) so I changed For the fix, I changed /pods/init.php lines 199ish to

if (is_admin()) {
     // Session start
      if (false === headers_sent() && '' == session_id()) {
            session_start();
        }

        // Load necessary JS
        wp_enqueue_script('jquery');
       wp_enqueue_script('pods-ui', PODS_URL . '/ui/js/pods.ui.js');
}

I believe that the session_start is there to handle form expiration. If you're using any Pods UI powered public forms this may give you headaches.

Also if you're including jQuery already using wp_enqueue_script shouldn't it only load one instance regardless?

session_start() is only used when a session hasn't already been started so this won't interfere with session variables stored already.

As for the jQuery, I'm working on a solution for this, but it probably won't be ready by 1.9.0. For now, remove the scripts before wp_head() and you should have no problem.

Use wp_deregister_script('jquery'); or wp_deregister_script('pods-ui'); it should work out well.

Thanks!

I used deregister to remove the javascripts from the front-end and I moved my class includes to my theme's functions.php so they are included before Pods starts the session.

For what it's worth, I'd strongly prefer that PODS not output any code to the front-end of the site. We create all our themes from the ground up and prefer to put all of the output/templating in one place: the WordPress templates.

We use PODS to create custom data structures and the admin panels but do not use PODS templates to output code to the front-end. Instead we create custom WordPress templates for each pod display template we need and in those templates, we retrieve and output the PODS data.

Thanks!