This will prevent future errors related to #983, but I can imagine it breaking a lot of existing sites.

Anyone who currently has field_ui disabled, quite a common setting on productions instances, will find that all their fields will lose data as they are now looking for different attribute name on apigee.

This will prevent future errors related to #983, but I can imagine it breaking a lot of existing sites.

Anyone who currently has field_ui disabled, quite a common setting on productions instances, will find that all their fields will lose data as they are now looking for different attribute name on apigee.

@audave, I agree to what you said,
IMO, we can check if field_ui module is enabled,
If yes, return the field name prefix else check/search for the value 'field_' in field name, if exists return default value 'field_' or else return "".
Any suggestions?

The problem is not so much what the prefix is but that it changes depending on the state of a different module.

In my opinion there is no need to account for a prefix at all. This would lead to drupal fields being stored as apigee attributes with the name field_myfieldname - but unless you are looking directly at the management API I don't see why that would be a problem.

Whatever the final solution is, it is probably worth writing an update hook to copy existing data to the new attribute.

We have added a dependency of Field UI module and rolled back the previous changes which will prevent such issues in future.

I do not thing this approach is a good idea.

In general the field_ui module is a UI module, its there help you configure fields on your content types (or teams). At almost every place I have worked in the last 12 years it has been disabled in production (and enabled in dev).

This approach forces people to enable a UI module in production, which they wouldn't otherwise do, and it shouldn't be relevant to the functioning of the apigee module.

Also.

Lots of sites will loose their data when this is implemented. As stated in my previous comment, the problem is that the prefix changes.

So anyone who currently does not have the field_ui module enabled will have all the field data stored as an apigee attribute field_myfieldname -> After they are forced to enabled the field_ui module as part of this change, this will no longer be the correct attribute name on apigee.

@audave

I do not thing this approach is a good idea.

In general the field_ui module is a UI module, its there help you configure fields on your content types (or teams). At almost every place I have worked in the last 12 years it has been disabled in production (and enabled in dev).

This approach forces people to enable a UI module in production, which they wouldn't otherwise do, and it shouldn't be relevant to the functioning of the apigee module.

Also.

Lots of sites will loose their data when this is implemented. As stated in my previous comment, the problem is that the prefix changes.

So anyone who currently does not have the field_ui module enabled will have all the field data stored as an apigee attribute field_myfieldname -> After they are forced to enabled the field_ui module as part of this change, this will no longer be the correct attribute name on apigee.

Because in Apigee management UI Custom attribute name size has limits, that is why we remove the prefix to increase the field name size.

Solution (Including the changes in the PR):
We can provide a configurable setting form in Drupal portal to edit the value of the field prefix
(Ideally updating the original field prefix value in field_ui.settings.yml),
and set the default prefix value as field_,

So that anyone who currently do not have the field_ui module enabled in Drupal and has field prefix or no prefix already stored in Apigee attribute can manage the field_prefix in Drupal portal through that configurable setting form to prevent data lose when field_ui module is forcefully enabled after this changes.