Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added check for field_ui module enabled durning getting field prefix #988

Open
wants to merge 5 commits into
base: 3.x
Choose a base branch
from

Conversation

shishir-intelli
Copy link
Collaborator

Closes #983
Added check for field_ui module enabled durning getting field prefix

@shishir-intelli shishir-intelli added the bug Something isn't working label Nov 21, 2023
@shishir-intelli shishir-intelli added this to the 3.0.4 milestone Nov 21, 2023
@audave
Copy link
Contributor

audave commented Nov 21, 2023

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.

@shishir-intelli
Copy link
Collaborator Author

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?

@audave
Copy link
Contributor

audave commented Nov 26, 2023

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.

@shishir-intelli
Copy link
Collaborator Author

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

Copy link
Collaborator

@divya-intelli divya-intelli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@audave
Copy link
Contributor

audave commented Dec 3, 2023

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.

/**
* Install Field UI module to maintain dependency.
*/
function apigee_edge_update_9003() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The update hook for Drupal 10+ should start with 10.

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Extension%21module.api.php/function/hook_update_N/10

(Probably old update hooks should have been removed when 3.x branch started and Drupal core major version was bumped)

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The update hook for Drupal 10+ should start with 10.

Thanks! Noted 👍

(Probably old update hooks should have been removed when 3.x branch started and Drupal core major version was bumped)

We will take care regarding this next time.

@shishir-intelli shishir-intelli removed this from the 3.0.4 milestone Dec 5, 2023
@shishir-intelli
Copy link
Collaborator Author

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: Reviewer approved
Development

Successfully merging this pull request may close these issues.

Teams lose field values if field_ui is enabled/disabled
5 participants