Opened 10 years ago
Closed 8 years ago
#5916 closed enhancement
Action xprofile_field_after_save has no way of knowing field_id for newly created field
Reported by: | tometzky | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | minor | Version: | 2.1 |
Component: | Extended Profile | Keywords: | |
Cc: | tometzky+wordpress@… |
Description
Action xprofile_field_after_save may need field_id number of newly created field. But it has no way of knowing it - it can't use $wpdb->insert_id, as other inserts might be performed if there are any support options defined.
Please add some way to check just created field_id in this hook. For compatibility it would be preferred to leave empty $field->id and create another field for newly created id, as some plugins may check for it to know it the field is new.
Something like:
$new_id = $wpdb->insert_id;
/* ... */
$field_arr = array( $this );
$field_arr['new_id'] = $new_id;
/* ... */
do_action_ref_array( 'xprofile_field_after_save', $field_arr );
I need this for my plugin "BuddyPress XProfile Validate with RegEx" - I have no way of saving data typed by users while creating a new field, as I don't know the id.
Change History (6)
#2
@
10 years ago
- Cc tometzky+wordpress@… added
I've managed to code a workaround in my plugin. If there's no $field->id
then I check for parent_id
column in a database. If its NOT NULL
then there was an option and I use parent_id
instead of $wpdb->insert_id
.
$field_id = $field->id; if ( !isset($field_id) ) { $field_id = $wpdb->insert_id; // There could be another insert after field - a record with type set to 'option' // we need to use its 'parent_id' instead $sql = $wpdb->prepare( "SELECT parent_id from {$bp->profile->table_name_fields} WHERE id = %d", $wpdb->insert_id ); $parent_id = $wpdb->get_var($sql); if ( isset($parent_id) ) { $field_id = $parent_id; } }
So maybe there's no need for API change.
Yes, this is a good suggestion in the abstract, though we should probably do it differently.
The most natural thing to do would be to modify the current object, so that you could get the info you need out of the
$this
currently passed to the filter. (We'd update theid
as well as the children that we create at https://buddypress.trac.wordpress.org/browser/tags/2.1/src/bp-xprofile/bp-xprofile-classes.php#L744.) However, this might pose backward compatibility issues with plugins that are doing something like checkingempty( $field->id )
to identify this as a newly created field. Do other devs have thoughts about this?Less elegant, but less problematic option:
do_action_ref_array( 'xprofile_field_after_save', array( $this, $new_field_id, $children_ids ) );