Wasn't sure where to put this - decided to open an issue for discussion. Don't expect there to be patches on here, but we can mark it fixed when there's some kind of consensus - and it saves this discussion derailing the actual patches.

There are currently two clear core modules targeted for conversion to the Field API - taxonomy and profile. Taxonomy already has an issue at #412518: Convert taxonomy_node_* related code to use field API + upgrade path.

Since we have no UI for fields in core, getting the taxonomy patch committed could leave core without a UI for attaching vocabularies to nodes, at least temporarily. I think we need to think early about the implications of this.

Here's potential scenarios:

a. We commit a patch which removes the current interface (node type checkboxes). Later on a core patch introduces a UI for fields in core and there is much rejoicing.

b. We commit a patch which removes the current interface. No core patch lands, CCK or form builder in contrib is required to attach vocabularies to node types in Drupal 7. Taxonomy module in core ends up just being an interface to create and manage vocabularies.

c. We commit a patch with some interim code which creates a single field instance when those node type checkboxes are clicked, and keeps the current 'required', 'multiple select' etc. checkboxes and stuffs them into field instance properties somehow. Later on when the core Field API UI patch lands, we take this cruft out.

d. We commit the patch with some interim code, no core Field API patch lands, Drupal 7 ships with two ways to add taxonomy vocabularies to node types, much confusion arises.

e. We postpone taxonomy and profile conversion until a UI arises, given the time scale, this would mean they don't get converted until Drupal 8.

IMO D and E are unacceptable. B would be bad, but we've moved interfaces for core APIs into contrib before (like modr8), and we're guaranteed the contrib interface would be better than taxonomy.module's because CCK already is better.

So at least in taxonomy module's case, where the interface is horrible and offers less features than CCK's, I'd go for commit first, worry about the UI later - rather than having a legacy interface which we have to spend extra time worrying about just in case.

Profile's a bit different, but there's no work on this that I'm aware of yet, so we may have a clearer idea of where things are headed by the time that's on its way.

Comments

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

Just to be clear: Taxonomy module in core ends up just being an interface to create and manage vocabularies. This is the goal.

B is probably a small disaster for new users.

C is the scenario I'm already playing, but it's very frustrating because I really just want to cut it all out. I have to straddle a line between "pre-inventing" the field-bundle manager because "required", "multiple", and "weight" translate into field instance properties, but in Taxonomy.module now they are properties of the vocabulary. I don't want to invest time in making it perfect because I assume the field UI will do it better, but I need to make sure it works so the UI is actually a step backwards because of the imperfect translation between vocabularies/fields and vocabulary-node-type/field instances.

Taxoman’s picture

Taxoman CreditAttribution: Taxoman commented

If this is solely related to UI, then any of those options would NOT mean more upgrade issues than any other option here?
(I mean, will the fields db schema be the same from the moment of implementing, regardless of which of these options is chosen?)

If so, then option c) looks interesting.
However, if c) poses more problems regarding future upgrades than a), then perhaps a) is the safest route.

IF the time frame is realistic.

Option e) would not be all that unacceptable if D7 was to be worked on as long as it takes to finish all these things, even if that would mean that the release of D7 would actually be at the time currently perceived as D8...

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented

With C, we could presumably store everything as a field instance no? So the upgrade path would be "create field instances for all current vocabulary/node associations with the vocabulary settings" - and the UI would only allow you to add or remove a single field instance per vocabulary to a node type. Then we could still cut out all those form-related columns from the vocabulary table, while still having an upgrade path and enough of a UI to keep what we have now. Would have to take the vocabulary submit form and re-work it to create fields and instances. Not going to be nice, but hopefully it'd be self-contained temporary code we could easily rip out later.

bjaspan’s picture

bjaspan CreditAttribution: bjaspan commented

FYI, over at #372743: Body and teaser as fields, I am using option C. See the function node_configure_fields() in node.module. Granted, it's a pretty simple case.

I see this as a "special purpose fields UI" for node managing its body field. Even if we do get a magical All Singing All Dancing Field UI into core, it is not a-priori obvious to me that we won't want it also to be possible to control some aspect of "built-in fields" like body from other places, e.g. the node type edit page. It's not obvious that we WILL want it to be possible, either. I'm just not worrying about it yet.

Anonymous’s picture

Anonymous (not verified) CreditAttribution: Anonymous commented

The migration path is an important issue, and I think the migration path from vocabulary-nodeType to bundle-fieldInstance has obvious solutions.

I'll continue doing "C" because the code is not too much work, but it does present some odd issues.

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented

Question: I am wanting to get rid of users.data column. Core uses it to store a pref for contact module ("can I be contacted" - boolean). Anywhere else?

Anyone want to comment on how best to move this to fields? Ideally we'd keep the UI as is.

bjaspan’s picture

bjaspan CreditAttribution: bjaspan commented

users.data stores any arbitrary information in the $user object that is not known to user.module or Field API (and btw the current method of determining if the field is known to Field API is actually a completely broken hack). Field API is based on pre-determined creation of fields and field instances. So I do not yet see how to move users.data storage to Field API other than by creating a widgetless text field and storing serialized data into it, which would be counter-productive as we'd just be adding extra overhead without really improving anything.

bjaspan’s picture

bjaspan CreditAttribution: bjaspan commented

FYI, I created a new issue for the problem with user_save() identified in #7: #431882: user_save() identifies field data properties incorrectly. Note that I'm pretty sure I wrote the current completely broken code.

moshe weitzman’s picture

moshe weitzman CreditAttribution: moshe weitzman commented

Contact module would create its own boolean field (i guess we use number_integer). You are right that user.module could not participate here.

Xano’s picture

Xano
he/they
Primary language English
Location Southampton
CreditAttribution: Xano commented

I hate doing unnecessary work, so my personal opinion is to go for A: no interim UI. However, since this is not my personal project and we (I) don't like to offer stuff that cannot be used, I am in favour of C: ship modules with a clearly marked interim UI and rip it out again once Field UI lands. Pros: features can still be used and tested. Cons: More work and less motivation to get Field UI ready.

Xano’s picture

Xano
he/they
Primary language English
Location Southampton
CreditAttribution: Xano commented

If we keep Poll and convert it to Field - which we should, it needs a UI as well.

mlncn’s picture

mlncn CreditAttribution: mlncn commented

We need a fully working CCK Field UI in core for Taxonomy, for Poll (i'm told it's not going off to die after all), and truthfully we should have an example textfield for something like "subheadline" for an article content type, although that could be done programatically and non-removable.

Splitting the effort and having a rudimentary job in core and counting on contrib to re-do it right is a bad idea, in my opinion.

Field UI can and should be a swappable and extensible system. Ideally it will be simply awesome. Paging quicksketch for form_builder in core?

yoroy’s picture

yoroy CreditAttribution: yoroy commented

Subscribing (sorry! :-)

yched’s picture

yched CreditAttribution: yched commented

My personal conviction is that a good CCK UI in core requires some community effort (design brainstorm, mockup iterations...).
By 'good' I mean :
- CCK UI is way subpar even for D6
- D7 fields have a few additional features that are challenging UI-wise : fields on non-nodes, formatter settings, field indexes, (not implemented yet:) per context field order and grouping.

I don't have the bandwidth to lead that effort myself, but I would be thrilled to see someone like yoroy or Benjamin embrace this ;-), and I would definitely help summarize the features and requirements, propose a few suggestions, and provide feedback.

IMO a g.d.o thread would be best place to start this. So : any taker ?

mlncn’s picture

mlncn CreditAttribution: mlncn commented

And profile module!!! If we bring profile module up to D7 standards by having it put fields on users, which is perhaps the biggest single win from Fields in Core, a user interface for adding and removing fields is an absolute requirement. And it should be as good as we can make it, and it should apply to nodes too. Right? I feel we have to go for A.

bjaspan’s picture

bjaspan CreditAttribution: bjaspan commented

profile.module could be converted to use Field API while maintaining the same interface it has now. In fact, profile.module presents even more challenges for a generic Field UI since profile's capabilities are also integrated with the user registration process, menu local tasks, etc., making a custom profile UI likely.

Damien Tournoud’s picture

Damien Tournoud CreditAttribution: Damien Tournoud commented

How big is the CCK UI right now? I think it could make sense to get it into core, even before we discuss the UI itself and as a support of that discussion.

I suggest the following roadmap:

- finish #488542: Tie Field UI pages to any fieldable entity, and get its core part committed
- produce a patch including the self-contained CCK UI into core (keep it self-contained so that we could remove it later if needed)
- do a "code only" review of the patch and get it committed
- discuss and redesign the UI based on that

yched’s picture

yched CreditAttribution: yched commented

"How big is the CCK UI right now? "
About 2500 lines of code + ~200 lines adding 'field settings subforms' for core's text, number and list field types.

I now (finally) tend to agree with the approach Damien sums up in #18.
Field UI needs to integrate with the D7UX trend, and it seems it won't happen unless the current state of the UI ships with core.
I want to be extra clear that I myself won't have the bandwidth to lead the design and implementation work on this. But I'll participate and feedback where I can, of course.
I'm working on a UI-oriented summary of Field API concepts and challenges, that I'll post as a wiki page on g.d.o. Should be ready in the very next days.

Note: All of the functions in CCK UI currently use the cck_ namespace. Maybe this doesn't need to change before going in core. It leaves the 'field_ui_' or whatever namespace free for "the killer UI", whether it ends up in core or in contrib.

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch commented

2700 lines isn't that much in the scheme of things. I'd much rather see us ship the final D7 release with the CCK UI than no UI at all - make it a separate optional module and we leave plenty of space open for whatever else might come along.

EvanDonovan’s picture

EvanDonovan CreditAttribution: EvanDonovan commented

To provide a non-core-developer perspective, I think providing the CCK UI in core by default would be much better than providing nothing by default. I think that people like me would be massively frustrated if we had to download a separate module just to get taxonomy to work.

yched’s picture

yched CreditAttribution: yched commented

@EvanDonovan: Thanks for the feedback, but let's not have a +1 spree there. *Everybody* agrees that a Field UI in core would be better than in contrib. The point here is deciding the best way to get there - and possibly easily roll back if it appears it's not doable within the D7 time frame or with core current UI tools.

EvanDonovan’s picture

EvanDonovan CreditAttribution: EvanDonovan commented

@yched: Sorry, I think there was a misunderstanding. I assumed that from the original issue, that it was a possibility that option B would take place and the UI was left to contrib (see catch's words about modr8, especially). It seems like #1 & #20 suggested "no UI at all" in core was a possible alternative, whereas #18 suggested putting the CCK UI in as an interim measure at least. That was what I thought was a good way to proceed.

yched’s picture

yched CreditAttribution: yched commented

Side note:
UI-oriented summary of D7 Field API: http://groups.drupal.org/node/23545
[edit: Discussion thread: http://groups.drupal.org/node/23282 - or is there any other place more in line with D7UX habits ?. Discussion happens in the comments of the "UI-oriented summary of D7 Field API" wiki page linked above]

sun’s picture

sun
Primary language German
Location Karlsruhe
CreditAttribution: sun commented

subscribing

yched’s picture

yched CreditAttribution: yched commented

Created a fresh issue for #516138: Move CCK HEAD in core.
Most urgent question: separate module or field.ui.inc ?

yched’s picture

yched CreditAttribution: yched commented
Status: Active » Closed (duplicate)

Field UI is in (hint: and needs followup work - http://drupal.org/project/issues/search/drupal?&status%5B%5D=Open&compon...)