Unable to edit new fields

I have created a completely new installation of WordPress.
I have exported the wp_participants_database_fields and the wp_participants_database_groups from the problem site.

I was still unable to edit new fields.

I rolled participants data base right back to version 1.8.4.9
I could then edit the fields.

I noticed that the fields on the new build did not match the fields showing in the problem site. There were fields that used to be of ‘Form Element’ type HTML that were not showing up on the problem site.

I tried deleting all these fields from the new site and reverting back to PDB 1.9.5.16 – could not preform the edits.

I started again and re-imported the PDB tables. This time I went into PHPMyadmin and changed HTML type to Text-line

I could still edit in version 1.8.4.9 but not in 1.9.5.16

In both cases, I can edit the existing fields, I can add a field, but I cannot edit the added fields.

Oddly, I even tried deleting all the fields, but still could not edit a newly created field.

Am I going to have to stick with PDB 1.8.4.9 or start all over again with participants database? We have 296 clients, 24 groups and 692 fields. It has taken many years creating this database. Please, please, can you think of anything else I can do?

Without knowing the specific issue I can’t be specific, I’m sorry. We’re at a serious disadvantage not being able to see the error that this is running into.

Even knowing that an older version doesn’t have the same problem isn’t all that helpful without the specific error.

I will say the the HTML field type is not a built-in field type, so that tells me you’re using a plugin to add that field. Does it help to deactivate the “PDB HTML Form Element” plugin?

We have moved the website to a new platform. But still have the same problem.

So, I did a completely fresh installation of WordPress with only the Participants database plugin. I then exported the wp_participants_database_fields and wp_participants database_groups from the original website.

I then gradually imported the fields, cutting off at a different point each time until I located when the error occurred.

It seems that when the auto-increment value for the ‘ID’ reaches 1000, you can still import more fields, you can still create new fields, but you cannot edit newly created fields. I have very carefully examined the 1000 entry and cannot see
an error,
so I imported 997 fields and then added new fields via the website. Again, I could add and edit field 998 and 999, but as soon as I added 1000, I could no longer edit it.

I have tried to research phpmyadmin, but cant find that this is a limit. It does not happen in participants database version 1.8.4.9
Is it possible that a limit has been set in later versions of participants database please?

Yes, that makes sense. I hadn’t anticipated there could be so many fields! So, I didn’t design the database to go that high, and in fact there may be other problems that come up as a result of so many fields.

Anyway, all that needs to happen to allow for more fields is to increase the data size of the “id” column of the wp_participants_database_fields table.

I am not sure how to increase the data size of the id column for the wp_participants_database_fields table.

I have been onto PHPmyadmin and clicked on the structure of the wp_participants_database_fields table. I can see that ‘ID’ is type INT(3), so I tried changing this to INT(4), but that didn’t fix the problem. I cant see a way to change the data size.

I have tried to search for the answer but cant find anything relating to changing the size of the data field for INT, so I don’t think I am looking for the right thing.

Please can you explain what I need to do. Thank you

Changing INT(3) to INT(4) is what I was referring to, that is changing the data size.

What do you mean it did not fix the problem? Did you attempt to re-import your fields?

Hi,

No, I only changed the structure to INT(4) in the PHPmyadmin, but now I have tried editing the wp_participants_database_fields file where it says
CREATE TABLE wp_participants_database_fields (
id int(4) NOT NULL,
changing the 3 to 4 and deleting wp_participants_database_fields table from PHPmyadmin and re-importing but the ID still says INT(3), even though I have changed it to INT(4) in the file!!! I dont know very much about PHPmyadmin, so I really don’t know why this would be. Can you shed any light on this please?

It says it is a primary Key, Is that why it doesn’t change?

I see this line at the end of the wp_participants_database_fields
table:
ALTER TABLE wp_participants_database_fields
MODIFY id int(4) NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=1;
COMMIT;

so I have also changed this to INT(4) and now the re-imported table structure shows ID INT(4). but still, when I get to ID 1000, I cannot edit a newly created field.

Do you have any other ideas please?

That line is not part of the database table it is that command that was used to change the datatype of the id column. Being a primary index column won’t prevent you from changing the datatype.

The first thing you want to do is make sure your changes were accepted. Open the database table to the structure tab and make sure the datatype for the id column is your INT(4) value.

We are really just guessing here still…we never got the error message, so we don’t know what the exact problem was, nor are we seeing any error messages that are generated after this change. It makes sense that this would be it, however, there may be other issues we’re not seeing yet.

In my opinion, the issue with error logging must be addressed in order to know whether we’re trying to fix the right thing.

• This reply was modified 4 years, 8 months ago by xnau webdesign.

I have opened the database structure and it is showing ID as INT(4)

when I roll back to participants database version 1.8.4.9 I can edit the new fields beyond ID 1000 with ID INT(3) or ID INT(4)

but if I update to the latest version, I can edit the field with ID=999 but not ID=1000 or 1001 etc.

Could I possibly send a copy of the wp_participants_database_fields.sql with wp_participants_database_groups.sql with the 1000 fields so you can see what I mean and perhaps spot something very obvious that I am missing?

Is that possible or not?

You can email the file to [email protected] I’ll import it and see if that sheds any light on the issue.