xprofile_insert_field_group() ignoring ID
-
I have deleted all field groups in admin panel and I am trying to add a new one with ID of 1.
This is my code:
$args = array( 'field_group_id' => 1, 'name' => 'Base', 'description' => 'These fields appear on your signup form', 'can_delete' => true ); $results = xprofile_insert_field_group($args);
It ignores my specified ID and returns a different number. Anyone know why?
-
I may be wrong but passing a
field_group_id
could mean an existing field group gets updated. If nofield_group_id
is passed or the passedfield_group_id
doesn’t exist then a new field group gets created. And perhaps field group IDs don’t get recycled?That’s more of a guess than actual fact. The
BP_XProfile_Group
class is where the magic happens if you want to investigate.Yeah something weird is going on as when I create a new field it automatically has the data of a previous field I have deleted.
I am guessing when I segmented the fields it caused an issue with the delete process. It deletes from admin panel but sometimes it says “there was an error deleting” so I guess part of the data remains.
I am going to have to get to grips with buddypress schema.
Yeah sounds like it could be your database preserving referential integrity. i.e. Can’t delete a profile group unless all fields belonging to that group have been deleted first.
Check what’s going on by looking at your database. This may help:
This is a basic mysql table structure issue.
The
id
field is set toauto increment
.
So it you really want theid
to be 1, you need to flush thebp_xprofile_groups
table.
But that may orphan any data you have inbp_xprofile_fields
or cause mismatches with data in the
bp_xprofile_data
table.Perhaps the
id
field should not be an argument inxprofile_insert_field_group
.Does it really matter what the
id
is?@henrywright Thanks Henry, studying it now 🙂
@shanebp I was just trying to make things consistent on subsites. This function will run on new install or if 0 groups are detected. I guess it doesn’t matter its just a bit of a smell that tells me I am probably doing something wrong somewhere.Is it standard behaviour for when a group is deleted via admin the profile data is left orphaned?
This is my first site of this type. I am not sure if I should be having separate process to check for orphaned data.
It turns out the plugin I was using should have made independant tables anyway so I have to start again and work out what went wrong.
Thanks for the help.
Is it standard behaviour for when a group is deleted via admin the profile data is left orphaned?
Standard? No, but in any relational table, if an item is assigned to a group ID and that group ID no longer exists in the table that holds group IDs, then that data will not be displayed, ie. orphaned.
This function will run on new install or if 0 groups are detected.
Why? BP will always create a Base group.
@shanebp Thanks for the reply.
[…]in any relational table, if an item is assigned to a group ID and that group ID no longer exists in the table that holds group IDs, then that data will not be displayed, ie. orphaned.
I deleted through the admin panel so I am not sure what was deleted, that was what I meant by asking if is was standard behaviour. Possibly what I should have said is; when a user deletes a group by using the ‘bp-profile-setup’ page to click on the ‘delete group’ button, is buddypresses default behaviour to just drop the group and leave the profile data in the table or does it also iteratively remove the profile fields?
I can see the reason why you would want to leave the data in the table (and also reasons why you wouldn’t). I had a quick look at the code but I am not familiar enough with it yet to pinpoint the exact code block.
If fields are not deleted then I guess any fields directly referenced would still be visiable on the site. That may be misleading to user as they may assume deleting a group would also remove fields. However you wouldn’t want a group to be deleted by accident and then a large amount of data be lost. I would guess a system of deleting the group and then updating each profile field to explicitly notify calling functions that their parent has been deleted would be appropriate in the circumstance.
I have used a relational database before but I am unfamiliar with the logic employed by buddypress to interact with it.
The behaviour I was was getting was weird. When I deleted a group and created it again no fields were showing. Then when I added a field, it had a value immediately after creating so something weird was going on so I thought I would ask to see if you knew if the profile data gets deleted when a user clicks delete group in admin panel.
I am starting again now so will pay closer attention to all data as it goes into fresh tables but sometimes it is harder to see to absence of data compared to the addition of new data.
Why? BP will always create a Base group.
I am running a multisite where individual user blogs can create their own fields (https://codex.buddypress.org/themes/guides/segregated-x-profile-fields-for-multisite/).
As the article says:
This code will not create dummy content, so for every new site you will need to create a Profile Fields group and add profile fields to it manually.
When I create new site there are no field groups made at all which I assumed is what it was talking about. Also I wanted to have a default set of groups but allow subsite to edit them. If they want to get default groups back they can just delete all their groups and default will be restored. I could add a separate button for that but I just figured I’d do it like this, no particular reason, I am still in early stages of project.
I think there were other errors at play so starting from scratch with a little more understanding will hopefully enlighten me. I will be duplicating tables this time instead of using meta table.
- The topic ‘xprofile_insert_field_group() ignoring ID’ is closed to new replies.