When submitting through a Public Form, this doesn't work. Though afterwards, I can go into the wp-admin screens and manually re-save the pod item, and the filter works.
For creating a new pod item through the wp-admin screens, the filter works.
I've gone through this tutorial : http://lowgravity.pl/blog/introduction-to-podscms-2-x-part-3-pod-item-filters/, and I've applied the same debugging logger -- the log shows that the fields are being correctly modified in my filter (code here: http://pastebin.com/NhikCcqB)
so, in my filter, $pieces is sent in, modified, and then returned. That much, I can verify.
For the pre_save filter to work on Public Forms, the fields being modified need to be passed through the form submission.
Example of brokeness:
The pre_save filter tries to modify a field, location, before saving.
However, location is not included in the $fields array.
$mypod = pods( 'mypod' );
// Only show the 'name', 'description', and 'other' fields.
$fields = array( 'name', 'description', 'other' );
// Output a form with specific fields
echo $mypod->form( $fields );
**Even though location is modified in the pre_save filter and returned in the $pieces array, since it was not included in the $fields array of the public form, it will not be considered an active_field, and therefore not modified.
In order to fix this, you must pass location into the $fields array for the public form.
In the event of the developer not wanting the user to be able to edit this field, yet still wanting it accessible by pre_save filters, they would have to make it a hidden form field within the $fields array :: 'location' => array('type' => 'hidden')
'location' => array('type' => 'hidden')
This functionality affects the permalink field as well (it won't get set unless included in the Public Form $fields array).
In my opinion, this is really confusing (as there is no clarification in the documentation of this being a requirement).
a. Either documentation should either be extremely clear, notifying the developer that if fields are needed to be available for pre_save helpers/filters - including permalinks - they need to be within the $fields array.
b. For public forms, all fields are active_fields. Not sure if that would kill things from security standpoint, but it certainly would be less confusing :)
Props to @pglewis for great detective work!!
Standard practice is to use a pre-save filter to modify the fields piece, and add to the active_fields array if the field wasn't submitted with the original form. Documentation to follow shortly, but thanks for making sure we get that specifically documented.
This solution does not seem to work with WP_Object fields like post_title. When I add post_title as a hidden input, it appears in the active_fields array but not the fields array. So trying to modify its value, for example from an empty value to "My Post Title" that title does not get saved. The post title remains empty after the post has saved.
My code to reproduce this can be seen here: http://pastebin.com/afQKKCU6
This is something we need to document, but for all 'object' fields, instead of values being in $pieces[ 'fields' ], it's really in $pieces[ 'object_fields' ]
Only WP-based objects have object_fields set, like post_title for post types, user_login for users, etc.