pre_save filters not working with Public Forms #869

Closed
thewatts opened this Issue Dec 13, 2012 · 4 comments

4 participants

@thewatts

Expected Result:

  • User fills out public form to create Pod item (of type life_groups)
  • Before saving, custom function is run (google_geo) through a pre_save filter.
  • google_geo function takes address fields, gets latitude & longitude from Google API
  • google_geo sets the life_group lat & long fields to the returned values from Google API
  • updated values saved to the DB.

Current Result:

  • User fills out public form to create Pod item (of type life_groups)
  • Before saving, custom function is run (google_geo) through a pre_save filter.
  • values are set
  • updated values are not being saved to DB

More Info:

so, in my filter, $pieces is sent in, modified, and then returned. That much, I can verify.

@pglewis pglewis was assigned Dec 13, 2012
@thewatts

Solution:

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')

Suggestion:

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).

My thoughts:
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!!

@sc0ttkclark sc0ttkclark was assigned Dec 20, 2012
@sc0ttkclark
Pods Foundation, Inc member

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.

@kohnmd

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

@sc0ttkclark
Pods Foundation, Inc member

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.

@sc0ttkclark sc0ttkclark reopened this Feb 22, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment