I think the IA decision to put Field UI configuration pages into the context of the fieldable entity is wrong.

Here are two reasons why it won't work out that way:

  1. Fieldable comments: If comments are fieldable, then we want to create separate field bundles per-content-type. So where will the field management pages for comments live?
  2. Fieldable fields: Where is that supposed to live?

Why did we implement that Field UI IA in the first place?

Comments

bjaspan’s picture

I'm pretty sure it was done this way because it was the shortest path to a Field UI in core because it was most similar to the way CCK's UI already worked.

I've always thought the Field UI should have a mode with an entity type dropdown list that lets you operate on all fieldable entity types from one place.

bjaspan’s picture

Component: field system » field_ui.module
damien tournoud’s picture

Title: Field UI IA does not work for all possible use-cases » Where can we tie a UI for fields on fields?

The comments part of this looks like a duplicate of #537750: Field UI for comments. Let's focus this one on the fieldable fields.

sun’s picture

Title: Where can we tie a UI for fields on fields? » Where can we tie a generic Field UI?

Well, both issues can be resolved in one fell swoop, if we would introduce a generic/overall Field UI on admin/structure/fields.

That would also allow to move the kinda strange menu item "Field list" (admin/reports/fields) from Reports. (?!)

Whether we still need the contextual field ui tabs for nodes, users, and taxonomy terms then is a different question. Even more interestingly, those field management pages do not even have an own user permission... so whoever has "administer users" can alter user fields? ugh.

yched’s picture

I agree with this.

During an informal discussion with Barry, Karen and Bec on the last day of Paris DC, we agreed that a central 'Field admin' page, giving access to the 'manage fields' screens for the various bundles of the various fieldable entities, would probably be a best solution.
fieldable entity modules can then add handy shortcut links to those screens where they see fit (on the content type overview table for node fields, in the comment settings for comment fields, etc)

joshmiller’s picture

Issue tags: +DrupalWTF

Tagging and marking #537750: Field UI for comments as duplicate.

Bojhan’s picture

So I think tieing it into the a general Fields UI page, is fine. But that is not the issue really, its more the issue of do we have contextual field ui links or not? I think it makes sense to have them but we do need a centralised way of handeling that, so that it doesn't cause confusion.

SeanBannister’s picture

Sub

Bojhan’s picture

Category: bug » task

The bug is that we don't know, doesn't seem like the right argument for calling this a bug. We might need a generic page where you can manage your entities, but I think this late in the cycle - that is less likely to happen.

nadavoid’s picture

subscribing

bdragon’s picture

Subscribing

yched’s picture

Status: Active » Postponed

Even less likely to happen now, I guess.

I reopened the comment-specific issue with a patch: #537750: Field UI for comments

webchick’s picture

Version: 7.x-dev » 8.x-dev
Status: Postponed » Active

Let's attack this in D8.

pasqualle’s picture

Priority: Critical » Normal
Issue tags: -D7 API clean-up, -D7 UX freeze
jhedstrom’s picture

Version: 8.0.x-dev » 8.1.x-dev
Category: Task » Feature request
Issue summary: View changes
Issue tags: +Needs issue summary update

At this point, I think this would be categorized as a feature request. Bumping to 8.1.x.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

smustgrave’s picture

Status: Active » Postponed (maintainer needs more info)
Issue tags: +stale-issue-cleanup

Thank you for sharing your idea for improving Drupal.

We are working to decide if this proposal meets the Criteria for evaluating proposed changes. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or there is no community support. Your thoughts on this will allow a decision to be made.

Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

smustgrave’s picture

Status: Postponed (maintainer needs more info) » Closed (outdated)

Since there's been no follow up and as a feature request going to close out. If still valid it can always be re-opened.

Now that this issue is closed, please review the contribution record.

As a contributor, attribute any organization helped you, or if you volunteered your own time.

Maintainers, please credit people who helped resolve this issue.