Skip to:

Opened 10 years ago

Closed 7 years ago

#5916 closed enhancement

Action xprofile_field_after_save has no way of knowing field_id for newly created field

Reported by: tometzky's profile tometzky Owned by:
Milestone: Priority: normal
Severity: minor Version: 2.1
Component: Extended Profile Keywords:
Cc: tometzky+wordpress@…


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)

#1 @boonebgorges
10 years ago

  • Keywords 2nd-opinion added
  • Milestone changed from Awaiting Review to 2.2

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 the id as well as the children that we create at However, this might pose backward compatibility issues with plugins that are doing something like checking empty( $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 ) );

#2 @tometzky
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",
  $parent_id = $wpdb->get_var($sql);
  if ( isset($parent_id) ) {
    $field_id = $parent_id;

So maybe there's no need for API change.

#3 @boonebgorges
10 years ago

Ah yes, this is clever, but we should still be passing better values. Thanks for sharing your workaround.

#4 @DJPaul
10 years ago

  • Milestone changed from 2.2 to 2.3

#5 @DJPaul
9 years ago

  • Keywords good-first-bug added
  • Milestone changed from 2.3 to Future Release

#6 @Offereins
7 years ago

  • Keywords 2nd-opinion good-first-bug removed
  • Milestone Future Release deleted
  • Status changed from new to closed

Closing as it was fixed in #6545. Thanks to @svenl77 for finding this out.

Note: See TracTickets for help on using tickets.