Tie Field UI pages to any fieldable entity

Hm, I'm a bit skeptical about the usability of one page listing all fields for all entities / bundles. How do you reorder your fields for 'page' node type ? Set the display settings for 'story' in teaser mode ?

But as I wrote in #414328-14: Converting core modules to provide fields leaves them with no UI, a community brainstorm on a good Field UI would be a very good thing IMO, so *please* post your mockups :-)
This issue is probably not the right place, because we need a short term solution with the current UI shortly after #413192: Make taxonomy terms fieldable lands.
I'd suggest a thread on http://groups.drupal.org/fields-core ?

Well, if you look at the part below foreach (field_info_fieldable_types() as $obj_type => $info) { in cck_menu(), that's non-minor, non-trivial code for every fieldable entity module to add...

Doing crazy things is still possible through hook_menu_alter(), but field_ui / cck providing sensible defaults menu paths would still be cool IMO.

Plus: could be modified, I guess, but we also have a 'List of all fields' page at admin/build/fields, which includes links to the 'Configure links' page for the involved bundles - and we'd have no way to generate those links if the paths are entirely custom.
This 'Fields' page is far from optimal, but is still very handy - it's notably the only place where you have a clear vision on shared fields.

Dirty 1st patch (patcheS, actually: one for core, one for CCK UI). Still need some polish, but it works and outlines the challenges:

- If we want Field UI screens to appear as primary tabs on the existing 'Edit [bundle]' page (edit node type, edit vocab), we need to piggyback its menu path pattern:
For node types, one "admin/build/node-type/[node-type]" path per existing node type.
For vocabs, one single "admin/content/taxonomy/%taxonomy_vocabulary" path with a placeholder for the vid.

- In the last case, we'll need both the 'path pattern' for menu items, and the 'real' path for each vocab, to be able to generate the actual 'edit field', 'remove field'... links.

- This also implies different format for the 'bundle name' received by the Field UI page callbacks
In the 1st case, the page callback receives a 'node-type' string, in the 2nd case, it receives a fully loaded $vocabulary object, from which we need to extract the 'bundle name'.
Note that it's a different thing from extracting a bundle name from a fieldable object (field_attach_extract_ids). Taxo terms are the 1st example of a fieldable entity where 'bundles' are actual data structures.

- Each set of Field UI pages need to use the same access perms as the main 'Edit [bundle]' page it ties to: administer content types, administer taxonomy, administer users, etc...

For now the patch adds all needed information as additional entries in hook_fieldable_info().
Arguably, we could add a drupal_alter('fieldable_info') (which we need anyway) and let CCK contrib add all UI-related properties on behalf of core modules. Drawback : those properties wouldn't get proper documentation in core.

Oops, user_fieldable_info() was incorrectly updated.
Apply with CCK patch in #6

fixes tests (typo in field_test.module menu paths for edit forms)

New patches, fixed #10 1. and 3.

2: right, that would require we overwrite the admin/content/taxonomy page callback, like we do for admin/build/types.
I left that as a TODO for now.

4: True, but separate patch. To be frank, I can't really handle working on Field UI code.
As I (finally) admitted in a recent private mail, maybe we should indeed push Field UI in core to give the community an incentive to enhance it or propose better UI concepts.

Anyway, this wouldn't deprecate the code in those patches: the additional 'path info for bundles' will be needed anyway if we want Field UI to handle contrib entity types.

Thanks Moshe :-)
Actually, still TODO: at least document the new hook_fieldable_info() properties.

Updated PHPdoc for hook_fieldable_info() (+ uses taxonomy implementation as a more thorough sample code)
Can probably use a re-read, not all of it is trivial.

+ added 'access callback' in the admin info for bundles. Can be omitted, but I guess some contrib entities might have more complex access rules than just perm-based.

Also, the patch tries to reduce the confusion between machine name and human name in code by settling on 'label' for human names of entities and bundles (like field types, widgets, formatters and field instances do). Mainly affects the CCK side.

Forgot to remove a TODO. The CCK patch is the same as in #14

Bohjan: Screenshots attached.

Note that this patch isn't about UI design discussions, though. It just updates the *current* CCK HEAD UI ('Manage fields', 'Display fields' tabs, as in CCK D6) to core HEAD with taxo fields now fieldable, and translates in code the fact that fieldable entities will have their own base UIs sprinkled in different parts of the menu tree: edit node type, edit vocabulary, ... Any Field UI, whatever shape it ends up having, will need to account for that, using more or less the information collected in this patch.

The goal here is just to keep CCK HEAD as a working UI, for people to actually use the Field API and provide a starting ground for the forthcoming design discussions.

Thus, I did not attach shots for the actual content of the 'Manage fields' / 'Display fields' pages, so as to keep the issue focused:-).

The CCK patch had a typo. Reattaching both patches for clarity.
The core patch hasn't changed and is still RTBC.

OK, here are those shots, then. It's roughly the same as CCK D6.
- "Manage fields" is where you add fields to a bundle, reorder them, change their settings, remove them.
- "Display fields" is where you define fields display settings for the various display contexts ('build modes')
(note that 'the 'Exclude' column on the 'Display fields' page will go as soon as #367215: Remove 'exclude from $content' display setting gets in)

To be extra extra clear: please let's not discuss the content of those pages here. The sooner the patch gets in, the sooner this discussion can happen.

"You are adding elements to the UI" - not exactly. I'm making the current elements available where they currently miss :-)

Well, it's doable if we can merge the functionality of both pages into one :-). Obviously we didn't succeed this in CCK D5/D6. I think vertical tabs might help us in D7.

But *really*, that's not the right issue to discuss any of this. The point here is to make it possible to attach a UI, whatever it is, to fieldable entities. Let's focus on getting this in asap, so that the discussion on the actual shape of the UI can be supported by actual code.

@catch: Hm, actually taxonomy_bundle_name_from_menu_helper() remained in the CCK patch. And, er yes, the PHPdoc is still TODO, forgot about that. CNW, then.

The point is: if we want field UI menu paths to appear as tabs on the 'Edit vocab Foo' page, they need to piggyback the admin/content/taxonomy%taxonomy_vocabulary/... menu path.
It means the Field UI page callback receives a fully loaded $vocab object from the menu system, but, being entity agnostic, it has no way to know that the bundle name it needs is in the $vocab->machine_name property.

I'm actually not really happy with that 'name of helper function' thing in hook_fieldable_info(). Best way would be to solve this as we solved the similar issue on $objects: 'id key', 'bundle key' in hook_fieldable_info(). But how would we name that ? 'bundle_name_in_bundle_object key' ?

Side note:
UI-oriented summary of D7 Field API: http://groups.drupal.org/node/23545
Discussion thread: http://groups.drupal.org/node/23282

Removed 'bundle helper' and taxonomy_bundle_name_from_menu_helper(), as explained at the end of #28:
hook_fieldable_info() now contains the name of the $bundle object's property that holds the bundle name, just like we do for fieldable $objects themselves.

- reshuffled the 'keys' in hook_fieldable_info() a little bit:

function hook_fieldable_info() {
  $return = array(
    'taxonomy_term' => array(
      'label' => t('Taxonomy term'),
      'object keys' => array(
        'id' => 'tid',
        'bundle' => 'vocabulary_machine_name',
      ),
      'bundle keys' => array(
        'bundle' => 'machine_name',
      ),
      'bundles' => ...,
    ),
  );
  return $return;
}

- added field_attach_extract_bundle(), similar to field_attach_extract_ids(). Each page callback in CCK uses it to transform the $bundle param handed by the menu system into a bundle name *string*

"Slave #24 was a bit possessed tonight" - I'll try to say this outside of the issue queue, just once.

Rerolled.

Thanks webchick.

I committed the CCK part of the patch.