fields

There's a module for that now: https://www.drupal.org/project/textarea_widget_for_text

It's nice and simple with an alter hook (as detailed on the module page) and in this answer.

Views fields offer the opportunity to "Rewrite results: Rewrite the output of this field". The option further specifies "Enable to override the output of this field with custom text or replacement tokens." It then provides a textarea with the instruction: "The text to display for this field. You may include HTML. You may enter data from this view as per the 'Replacement patterns' below." The replacement patterns, in turn, have the introduction: "The following tokens are available for this field.

In brief: The code at the bottom of this post deletes the named fields. If you are changing the field type for one or more fields, put it in an update hook for a feature module and run update.php before running features revert, your feature will happily rebuild the fields with their new settings. This destroys data.

FieldException: Cannot change an existing field's type. in field_update_field() (line 230 of /home/ben/code/sdl/web/modules/field/field.crud.inc).

Ideal would be on the field settings, or possibly the field display settings, you can set what the singular and what the plural should be.

I don't think automatic adding of an s would work so well.

Point is you have a link field for entering web sites, it should say web site if there is one and web sites if there are multiple.

You enter your username or ID and check off all the places it applies: Twitter, Facebook, IRC, etc.

There's a bit of a pitfall for places like drupal.org where your profile URL is not based on the username.

Or should it be entirely do-it-yourself?

My username/ID is:
On website:

When fields are used for configuration-like stuff (this is for AJAX form messages) it would make sense to be able to export field instances to code (as opposed to, say, node or comment fields).

asked, to no avail:

11:37 benjamin-agaric: is there a standard / anything anyone's tried for giving programatically-created field instances a machine name type thing

By using field storage, we get access to translation.

We've defined the info files, made them dependent on the core module. That was fun!

Caching is fun to implement, but try to hold off until you have all your functionality in place. As someone somewhere surely said (OK, it was Donald Knuth), "Premature optimization is the root of all evil."

We could define our form messages as a nested array analogous to menu definitions— a form ID,

Fields offer the advantage of understanding translation for user-entered data. Therefore, using fields, there's a potential