In the third part of my series about PodsCMS 2.x I would like to write a little about new action hooks which were introduced recently. Previously we used a small number of helper functions which were a bit limited when it comes to possible usage cases, their debug and development wasn’t too clear also. Now the things are different.

In 2.x the amount of events where we can hook in has greatly increased in comparison to PodsCMS 1.x. Another good news is that  hooks are duplicated for each action – first hook is fired for all types of pods, second one is fired just for particular type of pod – which gives us a lot of possible usage scenarios. We can target our functions to all pods or maybe just for the ones which are freshly created and belong to particular pod type.

!!! Please remember – all hook names are prefixed with ‘pods_{$scope}_ ‘ string so we have use for example “pods_api_pre_save_pod_item” to access our filter !!!

Pod pre-save (scope = api)

Those hooks are called before we save our pod data. We can use them to do some calculations, set values for hidden fields or validate data. They are also very useful if we want to fire specific functions depending on value changes (increase, decrease, relationship changes).

  • pre_save_pod_item (ex. pods_api_pre_save_pod_item)
  • pre_save_pod_item_{podname} (ex. pods_api_pre_save_pod_item_books)
  • pre_create_pod_item (ex. pods_api_pre_create_pod_item)
  • pre_create_pod_item_{podname} (ex. pods_api_pre_create_pod_item_books)
  • pre_edit_pod_item (ex. pods_api_pre_edit_pod_item)
  • pre_edit_pod_item_{podname} (ex. pods_api_pre_edit_pod_item_books)

Pod post-save (scope = api)

Those hooks are called after we save our pod item. We can use it for various tasks like email notifications for example. I am using them very heavily, mostly for statistical purposes.

  • post_save_pod_item
  • post_save_pod_item_{podname}
  • post_create_pod_item
  • post_create_pod_item_{podname}
  • post_edit_pod_item
  • post_edit_pod_item_{podname}

 Pod pre-delete (scope = api)

Those actions are performed just right before pod item is being deleted.

  • pre_delete_pod_item
  • pre_delete_pod_item_{podname}

 Pod post-delete (scope = api)

Finally, post delete actions are very useful for any update scripts, cleaning functions (similar to post-save ones).

  • post_delete_pod_item
  • post_delete_pod_item_{podname}

Development with easy debugging and sample example

As I mentioned in one of previous articles debugging pod item helpers in podsCMS 1.x was a hard thing mainly because pods data was saved using AJAX calls. Now pods are saved in similar way as WordPress posts – using post-redirect-get method.

Why am I writing about it? Well that’s very important for us because hooks are fired before redirect call is made and all data is not available for us – so simply relying on var_dump() or WP_DEBUG will not work here.

Fortunately this is not a problem and we have various possibilities to solve that problem. Please let me present one way of achieving this task.

I always put pods functionality in separate plugin to have an easy possibility to use pods functionalities on various sites. For our purposes lets just assume that we would like to do it on a theme level.

1. Create file podsDebugger.php in your themes main directory

2. Open functions.php and add at the bottom

Please change TEMPLATEPATH to STYLESHEETPATH if You are using child theme.

3. Now we are ready to develop and debug our hook functions. Open functions.php once again and add:

Now You should see nice array of variables which You can use.

And what now? Well that’s up to you 🙂

Related posts

Posted by Kamil Grzegorczyk Owner / Development

  • Lance Butler

    Good stuff. This has been quite helpful, and it’s always good to see how others might be taking advantage of Pods CMS. I really dig the part about the pods debugger class. I hadn’t thought of using something like that before, but it’s a great benefit for sure!!!

    • Thank You 🙂

      Regarding podsDebugger – You can also use the same approach to debug all WordPress hooks fired on post-redirect-get like ‘save_post’ action. The idea is exactly the same.

  • I want to share that for validation it is better to use the hook filter ‘field_validation’ or more specifically you would use add_filter(‘pods_api_field_validation’, ‘yourfilter’, 10, 7). Yes, it takes up to 7 parameters. And of course the ‘api’ scope seems to be the only scope available so yeah…

    The parameters are as follows:

    $valid – boolean (this is the value you are returning from your filter as a result of validation the $value below)
    $value – the field’s value
    $field – the field name
    $object_fields – extra stuff, as well as the stuff below

    You can see the code where that filter hook lies in /classes/PodsAPI.php line 4917 in Pods 2.2.

  • junpendon

    Hi, thanks for this awesome tutorial.

    I’ve created a single file upload field using plupload and want to enhance my form.

    – How can I disable “Add File” button after successful upload?

    – Delete uploaded file from WP uploads folder when “Minus Sign” next to the uploaded file is clicked and the restore back “Add File” button.

    Is it possible using actions and filters?

    Thanks in advance!

    • Kamil Grzegorczyk

      I believe that is possible but the answer is too big and complicated to handle it in the comments.

  • MIchael Patek


    I’m wondering how you’d handle a possible error happening in the pre_save function? Is there a way to exit the save process without saving the pod, and displaying a message to the user?


  • Anand Shah


    Cool, article. Helped me a lot. Thank you.

    it possible to attach a file dynamically using pre_save hook to file
    field? I have a Pod that has a file field and a textarea. On the front
    end I only display the textarea, when the form is submitted I create a
    PDF of the content that was entered in the textarea using the pre_save
    hook which works fine. But I haven’t had success attaching the PDF to
    the file field in the pre-save hook.

    Oh and point #2 about opening functions.php has a typo

    inlcude_once(…… should be include_once(……. 🙂

Like what you see?

Contact us today and get started!