1.9.1 Upgrade Changes FAX to acceptedterms - Can't Fix

I have about 23 sites running CB. I've only upgraded about 1/2 of them to date because every upgrade I've done has required me to go into phpMyAdmin and fix the fax field because it gets converted to acceptedterms (even though there's another acceptedterms field).

When I fix this (by confirming the column name in comprofiler, then changing the name and tablecolumns to "fax" and the type to "text" in comprofiler_fields), it messes up the Tools validation, which, when I run them and fix them, returns the fields to what they were!

First, why on EARTH has every upgrade from 1.9.1 changed the fax number field into an acceptedterms field? This has happened in every upgrade I've done since 2.x came out.

Second, how do I get this fixed correctly so that the fix stays fixed? All those records have the fax number in them, but after the upgrade, there's a checkbox in the Fax field on the form on the front-end.

If you can help me to fix the fields in the database correctly (or to keep it from happening in the first place), I'll finally be able to upgrade the other sites without having to invest so much time dealing with this mess.

Thank you,
Ernie

Very old legacy sample fields were using reserved field ids and is why that is happening. This has all been fixed in CB 2.x (sample data fields don't use reserved ids anymore). Due to this we ran out of reserved field ids so new core fields had to use reserved field ids that the very old sample data used. There isn't really an elegant fix for this beyond changing the field id of those sample data fields, but we had no way of knowing what configuration that'd break. We hope in a future release to be completely rid of using reserved field ids all together, which will eliminate this problem for good in future CB releases.

In short you just have to keep manually fixing it. Before upgrading you can edit the fax field row in _comprofiler_fields and change its field id to the next auto increment value to avoid it being changed as much as possible.

Thank you for the insight.

I need to resolve this once and for all - I can't keep carrying this over on 23 sites every time an update comes out.

Do you know what the reserved field id's were for the legacy sample fields - or are they different for every install based on users creating other fields?

For example, I have a 1.9.1 site that has a fieldid of 44 for the fax field in the _comprofiler_fields table. The last fieldid is 105. Would changing the fieldid for the fax to 106 prevent the upgrade from breaking the fax field?

Does the fieldid map to another table that I would need to change to match this?

As for sites I've already upgraded, would the same process as indicated above work for them?

I just want to be sure I didn't miss the point of what you were saying - when you say I just have to keep manually fixing it, I wasn't sure exactly what you meant - every time I update a 2.x install, or just to get through those sites I have not yet upgraded from 1.9.1.

Thank you,
Ernie

Do you know what the reserved field id's were for the legacy sample fields - or are they different for every install based on users creating other fields?

They were fixed IDs, yes. The problem is something was going to be lost no matter what we did.

For example, I have a 1.9.1 site that has a fieldid of 44 for the fax field in the _comprofiler_fields table. The last fieldid is 105. Would changing the fieldid for the fax to 106 prevent the upgrade from breaking the fax field?

Yes.

Does the fieldid map to another table that I would need to change to match this?

No.

As for sites I've already upgraded, would the same process as indicated above work for them?

Yes.

I just want to be sure I didn't miss the point of what you were saying - when you say I just have to keep manually fixing it, I wasn't sure exactly what you meant - every time I update a 2.x install, or just to get through those sites I have not yet upgraded from 1.9.1.

What I meant by manually fixing was manually changing the field id to a non-reserved id. Any field id between 1 and 54 is reserved.