Writing robust code that uses fields, in Drupal 7

In Drupal 7, the direct access to entity fields (CCK in d6) is different. In Drupal 6 you write:

in Drupal 7 you have to write:

(this is a recommended way in core docs).
So, we have different languages here now.

I haven’t built any d7 multilanguage websites yet, so I don’t know if that approach makes it really easy to create language-aware code for i18n websites (I hope it does!), but for regular single language websites this approach just adds some headaches to the developers.

The problem here is that you can’t rely on LANGUAGE_NONE! if website admin enables locale module, and English language is active, you’ll have to change your code to something like:

Obviously, we need some general way to access fields, with locale languages enabled.

First approach: field_language()

First approach that I’ve tried is to detect active content language of the node.
http://api.drupal.org/api/drupal/developer—globals.php/global/language_…
There is also field language:

http://api.drupal.org/api/drupal/modules—field—field.multilingual.inc/…

But it didn’t work in the way I expected - when nodes are just created, if the node is created in English language, you still have to use LANGUAGE_NONE constant. (I can’t give 100% guarantee that this works exactly like I say, since I don’t use the language variable for a while already)

I googled and I found

Second approach: field_get_items()

http://www.davereid.net/content/hlkd7fotw-field-get-items

which is fine. but this approach is not perfectly functional, since you can’t access, say, second element in multi-valued field, in one string (I mean, you can’t do field_get_items(‘node’, $node, ‘field_yourfield’)[1] - well, until php5.4) .
also, if you need quick access to five fields, you have to call field_get_items five times, so your code looks like crap.

and here is the third approach I found, which looks like the best way for field work:

Third approach: entity_metadata_wrapper

entity_metadata_wrapper is a helper object from great Entity module (fago is my hero)

here is how you use it:

well, that is clean enough, but not so exciting. What IS exciting, is how you can use entity_metadata_wrapper to load referenced objects on the fly:

when you call value() method here, entity_metadata_wrapper knows that the field is a user reference field, and loads appropriate user account on the fly. In Drupal 6, the same code looks like this:

Also, what is interesting, is that $project->field_users is not a regular array, it is an object, so for example you can call $project->field_users->value() to get an array of all users accounts from the field.
At the same time, this object supports array access, and you can do $project->field_users[0] or you can user foreach like in the example above. Talking in PHP5 language, this field object class implements IteratorAggregate, ArrayAccess and Countable interfaces.

More examples from Entity module readme:

In order to force getting a textual value sanitized for output one can use,
 e.g.

$wrapper->title->value(array(‘sanitize’ => TRUE));

to get the sanitized node title. When a property is already returned
sanitized by default, like the node body, one possibly wants to get the
not-sanitized data as it would appear in a browser for other use-cases.
To do so one can enable the ‘decode’ option, which ensures for any sanitized
data the tags are stripped and HTML entities are decoded before the property
is returned:

$wrapper->body->value->value(array(‘decode’ => TRUE));

That way one always gets the data as shown to the user. However if you
really want to get the raw, unprocessed value, even for sanitized textual
data, you can do so via:

$wrapper->body->value->raw();

You can also save the modified node:

This approach works for nodes and all other entities.

For entities creation (which is a separate story) you can try to use entity_create() or shortcut - entity_property_values_create_entity

I made my choice and I use third approach (entity_metadata_wrapper) in my d7 field-related code.

UPD from Tom Nightingale:
It should be noted though that it will only work with fields that correctly describe themselves to Entity API via its property_info hooks.
A lot of contrib field modules still need to implement this.