Rebuild menu after changing label

Actually, showing the field labels as secondary tabs is not really a feature ATM, but rather a buggy implementation of content.module's hook_menu(). Not sure we want to keep this. These secondary tabs might be useful to break the field settings form into subtabs.

Patches are more than welcome. Not sure what else we can do to 'open up the development process'.

And the patch is only needed if the field's name is in the menu system, which it won't be if it's no longer on a tab, so that's why this is just sitting for now. The menu_rebuild() function is a huge, massive, time-consuming resource hog, so we don't want to run it any more than necessary.

See http://drupal.org/node/157176, http://groups.drupal.org/node/4972, http://groups.drupal.org/node/5886, http://groups.drupal.org/node/5893, and many other threads.

We also made a presentation at DrupalCon Barcelona to at least 100 people explaining our plans, and posted them at http://drupal.org/node/177892. And there are numerous other CCK and Drupal experts who have been providing feedback and giving us patches and reviewing our ideas, including Jeff Eaton, Barry Jaspan, Moshe Weitzmann, and others.

This is by no means a 'closed' process.

We can't issue a final release until Views is updated, because the Views integration will need to be changed, and there have been changes in core as recently as yesterday that affect our code and require changes that have to be incorporated, so we're not slowing anything down by fixing whatever we find that needs fixing as we go, we can't issue a final release anyway.

We're working this week to try to get a preliminary development release issued.

The secondary tabs Yves is talking about would not have the field labels on them, but would be something like breaking the settings screen up into 'field', and 'widget' tabs, so the jury is still out on whether or not those labels will be tabs anywhere. Therefore, it is premature to commit changes until we see which way that goes.

Oops, we cross-posted. I can add some links to the project page. That's probably a good idea.

Well, I really like each field as subtab. In fact, I propose that these subtabs also appear under the Edit tab for the content type. That would save a click into Manage Fields tab. Presonally, I don't think the widget/field configure page is more unweildy than our other forms.

Well, it's cool when you have a few fields, but on content types with 10+ fields ?

I don't think the widget/field configure page is more unweildy than our other forms
If/when we add custom validators (http://drupal.org/node/212665), it will cross a line... Ok, not done yet.

I can tell you for sure that we have lots of situations where there are dozens of fields on a type. The tabs would really break down there. I agree that it's handy to have a quick link of some kind to the field, but I'm not sure the tabs are the right answer.

And on splitting up the widget/field page, some of them are already getting very complex (like the date module) and might really benefit from splitting them up or doing some kind of javascript wizardry to show and hide one section or the other.

But that is a UI issue that could wait for phase II, not needed to get an initial release out the door.

I removed the fields settings pages as MENU_LOCAL_TASK for now. We can still consider options, but I'd rather not go public on the 6 branch with the subtabs on. They were never intentional in the first place, so let's not look like we're set on this.