Fields in Core

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
This group should probably have more organizers. See documentation on this recommendation.

The Fields in Core working group aims to include CCK-like functionality in Drupal 7 and beyond. During the week of December 15, we're organizing a 5-day Fields in Drupal core code sprint at Acquia! To help us fund the sprint, please consider making a donation using the ChipIn widget on the announcement page. We need money for airline tickets, hotel rooms, food and transportation. It would also be great to fly in a few additional people with extensive core and CCK experience.

Xen's picture

$form['#fields'] and widgets

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.

Read more
frankcarey's picture

Extreame fields: Title and Body as fields for nodes; 'mail' (email) and 'name' (username) as fields for user

Has anyone talked about devolving title, body(for nodes) and mail and name for users into fields

One reason for this would be to have mail and name be non-unique if a setup called for that. See this comment.
http://drupal.org/node/394282#comment-1408924

If anyone has discussed this somewhere let me know?

Read more
KarenS's picture

Combo field/Multigroup to create one-off complex field tables

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.

Read more
bjaspan's picture

Per-Bundle storage module

Today I mostly goofed off at work and created the Per-Bundle Storage module (pbs.module), a Field API contrib module that stores all values for all limited-value fields in a bundle in a single table row. Per-bundle storage is the exact analog of pre-Field API CCK's per-content-type storage and thus provides the same benefits (namely, loading all such fields in a single query).

Read more
bjaspan's picture

Renaming Field API groups

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:

Read more
bjaspan's picture

Serialized data in FCI

We have a task for cleaning up the serialized data in the field_config_instance table. This includes preventing duplicate/inconsistent data from existing in the serialized data column and other columns, and considering whether some data now in the serialized column that did not used to be should in fact go back into its own column.

1. Preventing duplicate/inconsistent data

In _field_write_instance, we previously wrote $instance (the whole record) into the 'data' column. I changed the code like this:

<?php
// Create $data to contain everything from $instance that does not

Read more
yched's picture

Translation of Field Labels

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.

Read more
yched's picture

field_attach_*() calls

Taken from email discussion - Quick summary :

chx :

drupal_function_exists('field_attach_*');
field_attach_*(...);

is ugly, we should do :
module_invoke('field', 'attach_*', ...);

yched : This doesn't work because for this forbids reference-altering the arguments

chx: Then let's use the 1st form when by-ref args are needed and the 2nd one for the rest.

(end of summary)

Read more
bjaspan's picture

Convert field form data to object properties

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.

Read more
bjaspan's picture

field_attach_load_single() for MV

We have a Field CRUD API task: "CRUD: API to load single field for single entity: Should take field, entity, and entity_id as arguments. Needed for Materialized Views."

I started to write this function, thinking it would be easy (ha). I decided to make it exactly like field_attach_load() except for a single object and with another argument for the single field to load, like this:

<?php
field_attach_load_single
($obj_type, $object, $field = NULL, $age = FIELD_LOAD_CURRENT);
?>
Read more
bjaspan's picture

field_attach_delete_revision

field_attach_delete() deletes all fields for the specified object from the current and archive field data tables.

Read more
KarenS's picture

No field update

During the code sprint it was decided that core would not allow field attributes to be changed, only instance attributes. This was to prevent destructive changes, like trying to change a field type. But not allowing field changes creates another list of issues. Yves and I talked about this some last Friday (the last day of the sprint that got aborted by bad weather in Boston). Here are my (rough, unedited) notes from that discussion:

No field update:

Read more
KarenS's picture

Allowed values

Several kinds of fields currently offer an 'allowed values' list where you can create either a hard-code list of possible value or some PHP code that will produce an allowed values list. The allowed values list is a field attribute that is shared between all instances of a field.

Read more
bjaspan's picture

Version storage and access

Field API does not yet support revisions. It can easily enough, but we have a few decisions to make.

In D6 CCK, all per-field and per-content type storage tables contain columns for nid and vid but the primary key is vid. Multiple versions all go into the same table.

Read more
bjaspan's picture

Ongoing development and core commit strategies

We made a lot of progress during the Field API code sprint but the code is by no means "finished" for D7. Our planning spreadsheet shows many tasks remaining to be done, though not all of them are ever intended for core in the D7 timeframe. And, of course, we have yet to convince the community that our approach (particularly the per-field storage tables) is correct. So the code is in no way core-worthy yet.

Read more
bjaspan's picture

Coming up for air

It's been a crazy and exciting week. We grappled with a lot of issues, went around in plenty of circles, and took some heat from the community. We did not accomplish nearly everything we wanted to but did achieve several important goals. The big one is that it is now pretty simple to "field-enable" any kind of object with minimal effort. We have field-enabled nodes and users.

Read more

Introducing "Materialized Views"

There have been quite a few posts to the Fields in Core group about the decision to put all fields in individual tables, despite the apparent scalability penalty of removing the per-content-type (per-"bundle" in the Drupal 7 Field API jargon) tables. The reason is that we have something better to replace it with, and we've decided to simplify the Field API code by removing now-unnecessary code related to per-content-type tables.

Read more

Sprint update (via chx)

Pictures from the sprint
Participants: Dries, Karen, Yves, Moshe, Barry, David Strauss, David Rothstein(1 day), Karoly, Florian
Current status from the Fields in Core sprint, via chx in #drupal

Database first:

Storage will be per-field.

What's a field?

Read more

Performance results of table-per-field vs. table-per-content type

We considered preserving support for table-per-content type. There are a lot of reasons why we wouldn't want to, and one of the primary objections to abandoning them is the performance penalty of increased JOINs. So, I decided to run some benchmarks.

I set up a benchmark environment:
* 64-bit RHEL 5
** Dual quad-core Xeon
** 8GB RAM
** RAID-1 10K RPM SAS
** PHP 5.2 with APC
** MySQL 5.0 (InnoDB)
** Apache 2.2
* Drupal 6.8
* CCK 6.x-2.1
* Devel 6.x-1.12
* Views 6.x-2.1

I set up a content type with the following fields (aside from included files):
* Text (single, unshared)

Read more

Participating remotely

Getting a working copy

  • Download and install Bazaar. Packages are available for many platforms.
  • Get a working copy: "bzr branch bzr://vcs.fourkitchens.com/drupal/7-fic my-fic-working-copy"

While you're working

  • Run commits (bzr commit -m "My message") to checkpoint your work. These commits only affect your local working copy.

Updating your working copy to get the latest Fields in Core code

Read more
Subscribe with RSS Syndicate content

Fields in Core

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: