Fields in Core

This wiki page lists the steps for CCK D6 -> Code D7 fields upgrade.
It is based on a list KarenS maintained a few months ago, and might be incomplete or partially out of date.

Each field type will have its own bunch of reshuffling of the $field into the $field and $instance structures.

• Add new columns for:
  • deleted: defaults to 0
  • data: contains serialized array of complete $instance.
• Module-defined field settings are now at $field['settings'][...]

With Field API in Core I think we are shooting ourselves in the foot if we ship without a UI for it.

That having been said, let's see where we are at.
The Current Field UI / CCK UI still lives in contrib because it is said to be too complex or downright bad to belong in core.
Hence, if we want a Field UI in core we need to make it less complex. If you visit admin/build/types with CCK UI enabled you have have an admin page that needs to achieve all of the following:

1. Creating content types
2. Edit existing content types' settings

In http://drupal.org/node/367595 the groundwork is being laid for multilingual support in the core fields api.

At a May 21, 2009 IRC meeting to plan translatable fields (see this summary), a consensus emerged that translatable fields should emulate the current Translation module behavior.

With translatable fields we are introducing a second way in which nodes (and other Drupal data objects) can be made translatable, alongside the existing (node-only) one.

The purpose of this wiki page is to begin to map out in detail just how field-based translation will work, taking as our basis the existing node-based translation. For each feature of node-based translation, will there be an equivalent in field-based translation? If so, what will that equivalent look like, and how will it be represented?

Most or all of this will go as follow-up patches to http://drupal.org/node/367595; but it's worth starting to map the work out now.

This page so far has a few preliminary notes and needs a lot of expansion. Please add and edit. What further aspects of the existing node-based translation will we need to emulate in field-based translation? What will we need to consider?

To become an update for the issue RDFa: Add semantics from the ground up:

UPDATE ON THE UPDATE: This is the approach we think could be taken in contrib for RDF, and the original title Proposal for RDFa in Core, storing and loading, after first day of sprint has been changed. You can see the current approach over here.

Our CRUD functions:
<?php
rdf_mapping_create($bundle, $attribute, $rdf_term);
rdf_mapping_read($bundle, $attribute = NULL);

I've been experimenting with implementing complex fields by creating a field type that's also a fieldable entity.

But I've run into some problems in the form department. The issue is that $form['#fields'] makes it rather difficult to include a field in a complex element, when field implementations expect the form global #fields to include the the field and instance. It's 'just' form API #process functions that seems to be the problem.

I've been thinking about the concerns about storing fields in separate tables and have another idea to knock around. Storing each simple field in its own table could obviously result in a lot of tables for each content type, but storing a few complex fields could significantly reduce the number of tables involved. So another option is to make it easier to create a complex fields to match the needs of a particular system. If that was easier to do, anyone concerned about performance could combine the fields they need into a smaller number (or even a single) complex field.

We currently have three Field API groups: CRUD, Type, and Attach. As recently as Monday, chx was confused about what these names mean; he thought "Attach" was for attaching a field to a bundle. If he can be confused, then the names are just confusing. I propose that we change them as follows:

Current code is full of t($instance['label']) as a CCK legacy.
I know that this is not the recommended way to make user-defined strings translatable, but I'm not sure what the right way is.

I think we need another Field Attach API function.

Currently, a fieldable entity calls field_attach_form($obj_type, $obj, $form, $form_state) to load the appropriate field elements into $form for editing $obj. Later, it calls field_attach_validate(..., $form, $form_state) so the field widgets can perform their validation. Eventually, it will call field_attach_insert($obj_type, $obj) or field_attach_update($obj_type, $obj) to store the field data in the database.