Working with Drupal fields

Sometimes it can be handy to have extra pages for a node (or any entity). For example:

• To show different sets of information on separate pages for a single product, page, or thing.
• So you can set different access requirements on each page for a node.
• You want to block access to the ordinary route (e.g. node/123 and its aliased equivalent) for some reason, but you still want some other page to represent that node.

I've found a few people with that need on Drupal slack before, so I thought I'd write a guide because it's surprisingly...

I'm a fan of configuring things for display through Drupal's admin UI. It gives site builders confidence and power. What if you want to place blocks or views listings in amongst fields on pages of content? For example, to display:

• A listing (view) of related content, such as accessories for a product
• A standard contact block, advert, or some other calls to action in the middle of the content, exactly where the user is best 'caught' in their journey, rather than having to stick those in sidebars or after all the content fields.
• Some specific value(s) pulled from fields on some indirectly related entity, through a token, such as details from a taxonomy term representing the 'section' that a page is in.
• Consistent relevant links on user profiles to take people to common destinations

This is where the Entity Extra Field module (entity_extra_field) comes in. It supports embedding blocks, views or values to be replaced via tokens. So a site builder can set these up to be managed just like ordinary fields on the page (whether it's a node, term, paragraph, or any other type of content).

I recently released a new contributed module to aid translation on Drupal 7 sites: Entity Translation: Separated Shared Elements Form (ETSSEF). Yes, it has a convoluted name! It finally resolves a suggestion from years ago in an Entity Translation project issue, to allow editing untranslatable fields separately to translatable ones. One of our clients has a multilingual product database site with a few hundred fields on their content, so anything like this that could reduce the size of their editing forms is useful. I figure the best way to demonstrate this is with a recipe that blends it together...

Content (node-level) translation or entity (field-level) translation?

It seems an obvious question to ask, but what are you translating?

The tools exist to translate just about anything in Drupal 7*, but in many different ways, so you need to know exactly what you're translating. Language is 'a first-class citizen', in the sense that any piece of text is inherently written by someone on some language, which Drupal 7 is built to recognise. Sometimes you want to translate each & every individual piece of text (e.g. at the sentence or paragraph level). Other times you want to translate a whole page or section that is made up of multiple pieces of text.

This is part 3 in my series of articles about creating a custom field. I recommend reading Part 1: Field type and Part 2: Field widget first, if you have not done so already.

After creating the field type and field widget it is now time to complete the set by creating the field formatter.

##a) Create the file
The field type must be located as follows:

<module_name>/lib/Drupal/<module_name>/Plugin/field/formatter/<field_formatter_name>.php
N.B. The field formatter name should be in CamelCase.

##b) Add Contains, namespace and use
In the newly created field type file add a brief comment to explain...</field_formatter_name></module_name></module_name>

This is part 2 in my series of articles about Drupal widgets, and specifically creating a custom field. I recommend reading Part 1: Field type first, if you have not done so already.

After creating the field type it is now time to create the field widget.

##a) Create the file
The field widget must be located as follows:

<module_name>/lib/Drupal/<module_name>/Plugin/field/widget/<field_widget_name>.php</field_widget_name></module_name></module_name>

N.B. The field widget name should be in CamelCase.

##b) Add Contains, namespace and use
In the newly created field type file add a brief comment to explain what it consists of:

/**
 * @file
 *...

Having written articles on how to create a Drupal 8 field type, field widget and field formatter I thought that now is the time to explain why you might want to create a custom field type. More specifically, why I have created a custom field.

To provide some context: my pet Drupal 8 project is to produce a companion site for players of the Fantasy Football (soccer) game Fantasy Premier League (N.B. this is not my site :) ). For the uninitiated, Fantasy Football, as described by Wikipedia, is "a game in which participants assemble an imaginary team of real...

I have been experimenting with the Alpha release of Drupal 8 and so I'm sharing some of my experiences so that you can avoid the pitfalls I have encountered.

First I would like to give credit to the two articles I used during the exercise:

• Upgrading Code Snippets Module to Drupal 8: Creating a Custom Field
• D7 to D8 upgrade: fields, widgets and formatters

Hopefully this article will provide a third point-of-view to make your task easier.

a) Create the file

In D8 the location of files is very important. The field type must be located as follows:...

Previously on this website I have written about rendering blocks programmatically and adding things to content to be managed alongside fields. It's time to combine the two! On many projects, we find ourselves needing to render a block consistently across all content of a certain type. For example:

• Are you trying to place advertising blocks or fixed javascript code between the fields in the content of a page, not just shoved into regions around the content?
• Do you want to show a standard piece of content (we use the bean module for enhanced content in blocks) to be placed...

Drupal 7 fields are great, but using multiple valued fields and [field collection][fc] you can quickly reach the point of having a form that looks like this:

In this contrived example I've got two field collections and a multi-valued 'Links' field within that.

Although it's reasonably clear what clicking 'Add another item' will do in each case, when the form is full of data it can become less so.

We can give content editors a helping hand by changing the buttons from 'Add another item', to something more useful like 'Add another carousel item' etc...