We have several use cases of altering a field formatter settings and there is no easy way to do it. Patch adds two small alter hooks, hook_field_formatter_settings_form_alter() and hook_field_formatter_settings_summary_alter() since the latter is required in order to alter in settings to a formatter that does not natively provide any settings.

Files: 
CommentFileSizeAuthor
#55 945524-55-tests_only.patch2.93 KBjthorson
FAILED: [[SimpleTest]]: [MySQL] 39,740 pass(es), 5 fail(s), and 2 exception(s).
[ View ]
#55 945524-55.patch6.98 KBjthorson
PASSED: [[SimpleTest]]: [MySQL] 39,718 pass(es).
[ View ]
#44 drupal-field_formatter_settings-945524-44.patch3.23 KByannickoo
PASSED: [[SimpleTest]]: [MySQL] 39,676 pass(es).
[ View ]
#41 field_formatter_settings_d7-945524-1.patch3.24 KBjaffaralia
PASSED: [[SimpleTest]]: [MySQL] 39,437 pass(es).
[ View ]
#36 945524-36.patch7.25 KBswentel
PASSED: [[SimpleTest]]: [MySQL] 41,491 pass(es).
[ View ]
#33 field_ui-945524-33.patch7.25 KBxjm
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in core/modules/field_ui/field_ui.api.php.
[ View ]
#33 interdiff.txt3.42 KBxjm
#28 drupal-945524-28-tests.patch3.17 KBJelle_S
FAILED: [[SimpleTest]]: [MySQL] 41,340 pass(es), 5 fail(s), and 2 exception(s).
[ View ]
#28 drupal-945524-28.patch6.49 KBJelle_S
PASSED: [[SimpleTest]]: [MySQL] 41,341 pass(es).
[ View ]
#25 drupal-945524-25-tests.patch3.17 KBJelle_S
FAILED: [[SimpleTest]]: [MySQL] 39,997 pass(es), 5 fail(s), and 2 exception(s).
[ View ]
#25 drupal-945524-25.patch5.56 KBJelle_S
PASSED: [[SimpleTest]]: [MySQL] 39,997 pass(es).
[ View ]
#22 drupal-945524-22-tests.patch3.11 KBJelle_S
FAILED: [[SimpleTest]]: [MySQL] 39,780 pass(es), 5 fail(s), and 2 exception(s).
[ View ]
#22 drupal-945524-22.patch5.5 KBJelle_S
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal-945524-22.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
#21 drupal-945524-21-tests.patch3.11 KBJelle_S
FAILED: [[SimpleTest]]: [MySQL] 39,418 pass(es), 7 fail(s), and 4 exception(s).
[ View ]
#21 drupal-945524-21.patch5.5 KBJelle_S
PASSED: [[SimpleTest]]: [MySQL] 39,776 pass(es).
[ View ]
#20 drupal-945524-20-tests.patch3.11 KBJelle_S
FAILED: [[SimpleTest]]: [MySQL] 39,780 pass(es), 5 fail(s), and 2 exception(s).
[ View ]
#20 drupal-945524-20.patch5.5 KBJelle_S
PASSED: [[SimpleTest]]: [MySQL] 39,780 pass(es).
[ View ]
#17 drupal-945524-17.patch2.39 KBpfrenssen
PASSED: [[SimpleTest]]: [MySQL] 35,635 pass(es).
[ View ]
#16 drupal-945524-16.patch2.33 KBtim.plunkett
PASSED: [[SimpleTest]]: [MySQL] 34,196 pass(es).
[ View ]
#14 drupal-945524-14.patch2.52 KBtim.plunkett
PASSED: [[SimpleTest]]: [MySQL] 33,433 pass(es).
[ View ]
#1 945524-field-formatter-settings-alters-D7.patch2.69 KBDave Reid
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 945524-field-formatter-settings-alters-D7.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]

Comments

Status:Active» Needs review
StatusFileSize
new2.69 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 945524-field-formatter-settings-alters-D7.patch. This may be a -p0 (old style) patch, which is no longer supported by the testbots.
[ View ]

Initial patch that requires the hook docs to be fleshed out, but works.

To make module like Field Formatter Class even reasonable for mere mortals this patch is really needed.

I tested and the code works. Looking forward to the docs.

Can you make the case that this is a regression from CCK in Drupal 6?

This is sort of a regression and sort of a new feature that has been largely unused by many.

In CCK Formatters did not settings. So, they did a few things to overcome this. One example is the way imagecache worked with imagefield for the display settings. Since you couldn't specify settings all the available settings were listed for each imagecache preset. This list could be altered fairly easily. Another example is the swftools module that created a global config and housed it on custom config pages. These could be easily form altered and were straight forward forms.

But, the way D7 does it is totally new. Formatter settings are not bolted on through something else and this was a late addition to D7. So, we went from CCK with a bolt on formatter setting solution you could easily alter (even if just at the form level in fairly straight forward forms) to native formatter settings you have to be a FAPI guru with a lot of patience to begin to hack on (the formatter settings forms are not trivial to work on).

Because this is done in a whole new way from D6 CCK and we are just now finding in real usage there are some problems I like this patch. It does not change the API but does add two new alter calls (which are only called on the formatter settings page). I've already seen two separate use cases for this functionality. One I linked to.

Hope this helps.

Even if you can alter the settings form and summary, how do you reflect the actual changes in the rendered array ?
We intentionally did not include an alter hook on 'formatted field output' render arrays, because such a hook would be called potentially 100s of times on listing pages. So right now the only way is hook_field_attach_view_alter(), which operates on the render array of the whole entity - you thus have to find your way in there to the sub array(s) you want to alter.

Note that widgets settings forms are currently not alterable either. If one is, the other should too for consistency.

@yched - If you want to add or alter the structure I see no other way than to use hook_field_attach_view_alter() and I think that is acceptable for that. But, there are other cases where you may want to alter the config form in a way that has no impact on altering the render array. For example, what if someone wants to limit the image styles listed to a subset of the total image styles. This could be done through the settings form without altering the rendered output.

Version:7.x-dev» 8.x-dev
Status:Needs review» Needs work

The image formatter field system is so gross... theme_image_formatter, theme_image, theme_image_style, it's all so gross and ugly.

subscribe (sorry)

Issue tags:+needs backport to D7

subscribe

Title:Impossible to alter field formatter settings or summaryField formatter settings hooks in core
Category:bug» feature

+1 for this. Now we're into D8, can we look into this API addition some more?

The Field formatter settings API module implements this in D7 contrib.

So far there are 4 contrib modules using these new hooks, which demonstrate their usefulness well.

Status:Needs work» Needs review
Issue tags:-API addition, -needs backport to D7

Status:Needs review» Needs work
Issue tags:+API addition, +needs backport to D7

The last submitted patch, 945524-field-formatter-settings-alters-D7.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new2.52 KB
PASSED: [[SimpleTest]]: [MySQL] 33,433 pass(es).
[ View ]

Rerolled with git prefixes, and fixed the spelling of summary.

Still needs the api.php docs to be created.

Ummm, I made #1308860: Allow modules to alter fields settings hook, and either completely forgot about this issue, or was thinking of something else at the time. I'm going to mark that one as a duplicate. Either way, here's what I wrote up there...

Looking at field_ui_field_settings_form(), we discover that hook_field_settings_form() only lets the module defining the field append additional settings to the field. External modules should be able to append additional settings to the defined fields.

Currently, if a contributed module (like Field Permissions) wants to add field settings, it is required to do a form_alter(). We should fix this by making it so that hook_field_settings_form() applies to all modules, not just the module that's defining the field.

StatusFileSize
new2.33 KB
PASSED: [[SimpleTest]]: [MySQL] 34,196 pass(es).
[ View ]

Rerolling, also moving $form_state out of the $context into a proper variable, like hook_field_widget_form_alter has it.

StatusFileSize
new2.39 KB
PASSED: [[SimpleTest]]: [MySQL] 35,635 pass(es).
[ View ]

I fixed a typo ("formater") in the patch from #16 and added a comment to the second call to drupal_alter().

Issue tags:+Needs tests

patch is good but no go without tests :(

Do we have a same issue for field settings? EDIT reopened #1308860: Allow modules to alter fields settings hook

Status:Needs review» Needs work

CNW for tests.

Status:Needs work» Needs review
StatusFileSize
new5.5 KB
PASSED: [[SimpleTest]]: [MySQL] 39,780 pass(es).
[ View ]
new3.11 KB
FAILED: [[SimpleTest]]: [MySQL] 39,780 pass(es), 5 fail(s), and 2 exception(s).
[ View ]

Written tests to see if the new alter hooks work. First patch: tests only, second patch: patch from #17 with added tests.

StatusFileSize
new5.5 KB
PASSED: [[SimpleTest]]: [MySQL] 39,776 pass(es).
[ View ]
new3.11 KB
FAILED: [[SimpleTest]]: [MySQL] 39,418 pass(es), 7 fail(s), and 4 exception(s).
[ View ]

Trailing whitespaces removed...

StatusFileSize
new5.5 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch drupal-945524-22.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]
new3.11 KB
FAILED: [[SimpleTest]]: [MySQL] 39,780 pass(es), 5 fail(s), and 2 exception(s).
[ View ]

Ok, now I know the test pass:

Punctuation... (the devil is in the details)

#22: drupal-945524-22.patch queued for re-testing.

Status:Needs review» Needs work
Issue tags:+Needs tests, +API addition, +needs backport to D7

The last submitted patch, drupal-945524-22.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new5.56 KB
PASSED: [[SimpleTest]]: [MySQL] 39,997 pass(es).
[ View ]
new3.17 KB
FAILED: [[SimpleTest]]: [MySQL] 39,997 pass(es), 5 fail(s), and 2 exception(s).
[ View ]

Reroll...

Status:Needs review» Reviewed & tested by the community

Looks good and still applies, let's do this!

Status:Reviewed & tested by the community» Needs work

+++ b/core/modules/field_ui/field_ui.admin.incundefined
@@ -1060,6 +1060,17 @@ function field_ui_display_overview_form($form, &$form_state, $entity_type, $bund
+      // Allow other modules to alter the formatter settings form.
+      $context = array(
+        'module' => $formatter['module'],
+        'formatter' => $formatter,
+        'field' => $field,
+        'instance' => $instance,
+        'view_mode' => $view_mode,
+        'form' => $form,
+      );
+      drupal_alter('field_formatter_settings_form', $settings_form, $form_state, $context);
+++ b/core/modules/field_ui/field_ui.api.phpundefined
@@ -169,6 +169,18 @@ function hook_field_formatter_settings_form($field, $instance, $view_mode, $form
+function hook_field_formatter_settings_form_alter(&$element, &$form_state, $context) {

Context should be described in php doc for hook_field_formatter_settings_form_alter()

+++ b/core/modules/field_ui/field_ui.admin.incundefined
@@ -1095,6 +1106,15 @@ function field_ui_display_overview_form($form, &$form_state, $entity_type, $bund
+      // Allow other modules to alter the summary.
+      $context = array(
+        'field' => $field,
+        'instance' => $instance,
+        'view_mode' => $view_mode,
+      );
+      drupal_alter('field_formatter_settings_summary', $summary, $context);
+++ b/core/modules/field_ui/field_ui.api.phpundefined
@@ -169,6 +169,18 @@ function hook_field_formatter_settings_form($field, $instance, $view_mode, $form
+function hook_field_formatter_settings_summary_alter(&$summary, $context) {

Context should be described in php doc for hook_field_formatter_settings_summary_alter()

Status:Needs work» Needs review
StatusFileSize
new6.49 KB
PASSED: [[SimpleTest]]: [MySQL] 41,341 pass(es).
[ View ]
new3.17 KB
FAILED: [[SimpleTest]]: [MySQL] 41,340 pass(es), 5 fail(s), and 2 exception(s).
[ View ]

Added phpdoc.

Status:Needs review» Reviewed & tested by the community

This looks good to me.

We're over thresholds atm so I unfortunately can't commit any feature patches. Help with smashing critical and major bugs would be greatly appreciated.

We are over, since when?

Assigned:Unassigned» xjm
Status:Reviewed & tested by the community» Needs work
Issue tags:-Needs tests

@yannickoo: You can see the number of major and critical bugs in the contributor links dashboard blog. The thresholds are 100 each major tasks and bugs; and 15 each critical tasks and bugs. See the threshold policy for details.

The test coverage looks good. However, I think we need to add example implementations for the hook documentation rather than empty stubs.

+++ b/core/modules/field_ui/field_ui.api.phpundefined
@@ -169,6 +169,39 @@ function hook_field_formatter_settings_form($field, $instance, $view_mode, $form
/**
+ * Alter the formatter settings form.
+ *
+ * @param $element
+ *   Form array as returned by hook_field_formatter_settings_form().
+ * @param $form_state
+ *   The form state of the (entire) configuration form.
+ * @param $context
+ *   An associative array with the following elements:
+ *   - 'module': The module that contains the definition of this formatter.
+ *   - 'formatter': The formatter type description array.
+ *   - 'field': The field structure being configured.
+ *   - 'instance': The instance structure being configured.
+ *   - 'view_mode': The view mode being configured.
+ *   - 'form': The (entire) configuration form array.
+ */
+function hook_field_formatter_settings_form_alter(&$element, &$form_state, $context) {
+}
+
+/**
+ * Alter the field formatter settings summary.
+ *
+ * @param $summary
+ *   The summary as returned by hook_field_formatter_settings_summary().
+ * @param $context
+ *   An associative array with the following elements:
+ *   - 'field': The field structure being configured.
+ *   - 'instance': The instance structure being configured.
+ *   - 'view_mode': The view mode being configured.
+ */
+function hook_field_formatter_settings_summary_alter(&$summary, $context) {
+}

NW for that change.

Also, some minor code style issues (see below).

+++ b/core/modules/field_ui/lib/Drupal/field_ui/Tests/ManageDisplayTest.phpundefined
@@ -75,6 +75,22 @@ class ManageDisplayTest extends FieldUiTestBase {
+    // Assert hook_field_formatter_settings_summary_alter is called.
...
+    // Click on the formatter settings button to open the formatter settings form.
...
+    // Assert the field added in field_test_field_formatter_settings_form_alter is present.
...
+    // Open the formatter settings form again to check if the settings are updated.

These comments are over 80 characters and need to be rewrapped. Also, hook and function names should always have () in inline documentation.

I'll fix what I can here.

Status:Needs work» Needs review
StatusFileSize
new3.42 KB
new7.25 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid PHP syntax in core/modules/field_ui/field_ui.api.php.
[ View ]

Attached:

NR for the sample implementations. Please check over them; I didn't actually test them.

Assigned:xjm» Unassigned

Status:Needs review» Needs work

The last submitted patch, field_ui-945524-33.patch, failed testing.

Status:Needs work» Needs review
StatusFileSize
new7.25 KB
PASSED: [[SimpleTest]]: [MySQL] 41,491 pass(es).
[ View ]

Status:Needs review» Needs work
Issue tags:-API addition, -needs backport to D7

The last submitted patch, 945524-36.patch, failed testing.

Status:Needs work» Needs review
Issue tags:+API addition, +needs backport to D7

#36: 945524-36.patch queued for re-testing.

Status:Needs review» Reviewed & tested by the community

Patch is good, ready to be committed imo

Version:8.x-dev» 7.x-dev
Status:Reviewed & tested by the community» Patch (to be ported)

This looks like a nice simple addition and it comes with test coverage. Thanks!

Committed and pushed to 8.x. I believe this should be eligible for backport, so marking as such.

Status:Patch (to be ported)» Needs review
StatusFileSize
new3.24 KB
PASSED: [[SimpleTest]]: [MySQL] 39,437 pass(es).
[ View ]

Hi,

I created patch for D7.

Thanks,
A. Jaffar ali

When the patch for drupal 7 wil reviewed, when could it be in core? Will there be any conflicts with field formatter settings module?

Status:Needs review» Needs work

@jaffaralia: Thanks, but can you also backport the tests?

+++ b/modules/field_ui/field_ui.api.phpundefined
@@ -170,6 +170,41 @@ function hook_field_formatter_settings_form($field, $instance, $view_mode, $form
+  ¶

spaces

@yannickoo: you can review/test this yourself

Status:Needs work» Needs review
StatusFileSize
new3.23 KB
PASSED: [[SimpleTest]]: [MySQL] 39,676 pass(es).
[ View ]

Here is the patch without the whitespace. I don't know how to customize the test because I don't know how to write them yet :/

Status:Needs review» Needs work

BTW there is a typo in the test for 8.x:

+++ b/core/modules/field_ui/lib/Drupal/field_ui/Tests/ManageDisplayTest.phpundefined
@@ -75,6 +75,22 @@ class ManageDisplayTest extends FieldUiTestBase {
+    $this->assertField($fieldname, t('Field added in hook_ield_formatter_settings_form_alter is present.'));

It should be hook_field_formatter_settings_form_alter. The "f" from field is missing.

Can you create a new issue with a patch to fix it?

Oh, I think webchick fixed the typo in her commit.

It's very difficult to backport the test because in drupal 7 there is no test module, just the field_ui.test and I don't know how to implement the hooks in the test file. Please advise how to do this.

You have to create a test module for this, but I think easy way is to copy/paste it from Drupal 8, get rid of all the code that isn't needed and create a new SimpleTest that enables this module.

Version:7.x-dev» 8.x-dev
Category:feature» bug
Status:Needs work» Needs review
Issue tags:-needs backport to D7

Ok, moving back to 8.x first as this simply doesn't work - without a work around though. Found this out while working on #1234624: Limit the number of fields to display where I started implementing this hook in field ui as that makes sense.

The key problem is in field_ui.admin.inc line 1379

<?php
   
// Only save settings actually used by the selected formatter.
   
$default_settings = field_info_formatter_settings($values['type']);
   
$settings = array_intersect_key($settings, $default_settings);
?>

Now, there is a work around :

<?php
/**
* Implements hook_field_formatter_info_alter().
*/
function field_ui_field_formatter_info_alter(&$info) {
 
$info['image']['settings']['display_limit'] = 0;
 
$info['image']['settings']['display_offset'] = 0;
}
?>

I can live with that, but then we should make sure we update the documentation in field.api.php. Thoughts ?

Category:bug» feature
Status:Needs review» Needs work

Ok, investigated how the modules in 7.x do this and they actually implement hook_field_formatter_info_alter() which makes sense, let's make sure we document this in the api.php so people know what todo.

Version:8.x-dev» 7.x-dev

Moving back to 7.x - I also though the tests was bogus, but it isn't, let's try to get this ok for 7.x first.

Status:Needs work» Needs review

Issue tags:+needs backport to D7

StatusFileSize
new6.98 KB
PASSED: [[SimpleTest]]: [MySQL] 39,718 pass(es).
[ View ]
new2.93 KB
FAILED: [[SimpleTest]]: [MySQL] 39,740 pass(es), 5 fail(s), and 2 exception(s).
[ View ]

D7 backport, including the D8 tests.

Status:Needs review» Reviewed & tested by the community

That is a straightforward backport. Looks good, applies and passes tests => RTBC

And for bonus points, we're going to want this for D7 project_issue, which in turn impacts the D7 port of Drupal.org. ;)

Means that this feature could be in the next Drupal 7 release and all the modules which depend on Field formatter settings module won't need that module as dependency.

Uh-oh ...

... Do we have a naming conflict between this patch and Field formatter settings? Given that the hook is named the same between the two, will anyone with Field formatter settings applied end up double alter()-ing their forms if they upgrade to a core release using this?

In the hook_update_n hook we have to disable and uninstall the other module right?

#60: We cannot disable a contrib module from core, but we can open up an issue on the contrib module to deprecate the module when 7.xx ships. Given that Dave Reid is the maintainer, I guess that will be no problem.

Oh sorry, absolutely not in the core but in the contrib modules which depend on that module. It's important to notify the maintainers from the modules which require it and Dave to close his (great) project.

I guess that if Dave wants to take it easy on the ~3000 users of the module, he could release a 7.x-1.1 or 7.x-2.0 version that checks core version before it does its magic:

- If installed core version < 7.xx, then work the same as 7.x-1.0.
- If installed core version >= 7.xx, then only display a warning/message of some kind (site status page perhaps?) to disable and uninstall the module.

Does that make sense?

Sounds good but I wouldn't put that message on the status page. I would check that in hook_init and display a message via drupal_set_message with a warning level.

There's an easier approach and that's simply won't fixing this issue for D7. The module exists and is stable. I guess it's Dave's call.

#65: Please see #57. It would make the life of D.org D7 easier without adding yet another module dependency ...

Not only for D.org D7 it is better because you don't have to install an extra module for this little functionality.

Ok, missed #57, it's just that it's sometimes that people will miss these kind of announcements, I'm ok with both :)

To avoid misunderstanding this means that we just have to wait for a D7 administrator who will commit #55?

Assigned:Unassigned» Dave Reid

Seems like it would be a good idea to get some feedback from Dave Reid here, since he is the maintainer of the Field formatter settings module.

Looking at that module's code, I'm also noticing that it does some things with Views, so I'm not sure it would actually be as simple as turning off that module if/when these hooks get added to core.

To be honest, if that module didn't exist, we'd probably just add the hooks to core. But it does exist, has 3,000 happy users, lots of other modules that depend on it, etc. Maybe this is a case where we should just leave well enough alone? :)

Okay, so in Drupal 7 there is no way to get this feature in. I can understand that you mention the Views thing. That feels like Imagecache in Drupal 6 :D

I will open a new issue with the "Views thing" for Drupal 8 of it's not in core yet.

Status:Reviewed & tested by the community» Needs review

Seems like we should move this back to "needs review" while we figure all that out.

I will open a new issue with the "Views thing" for Drupal 8 of it's not in core yet.

Interesting point - thanks!

...friendly bump ;)

So I would definitely but shutting down the field_formatter_settings module if this were accepted into core. I would have to wait until the next release of core in order to update the .info file of the module to specify that a version less than Drupal 7.2? is necessary to use the module and would error if you try to use the module with a higher version of core.

As for the hooks, I don't see any reason why having both the core and the contrib module invoking the same hooks.

For hook_field_formatter_settings_form_alter(), having it invoked twice means that the same form elements get written in. I haven't seen a use case where these form elements don't have hard-coded key values, so they would just get overridden on the second invocation.

For hook_field_formatter_settings_summary_alter(), having it invoked twice would mean that the summary possibly includes duplicated information. But it doesn't affect functionality and will not cause any bugs. This would be a good key to the user that they need to disable the module.

As well as the two hooks, the D7 contrib API module provides a helper function to get the formatter settings:

field_formatter_settings_get_instance_display_settings()

Some of the field_formatter_settings modules ditched their own helper functions in favour of this.
We'd need to include this in D7 core along with the hooks, otherwise modules will have to go back to implementing their own helper function again.

It's not an issue for D8, because entity_get_render_display() is available.

Category:feature» task

Since Drupal.org D7 upgrade needs this in order to optimally solve #1628044: Implement magic for the table of attachments on issues, which is a critical task, moving this to a task rather than a feature.

However, since just adding a dependency on http://drupal.org/project/field_formatter_settings in the meantime doesn't seem the end of the world, keeping it as just a "normal" task, rather than a major/critical one. If that's incorrect, feel free to bump accordingly.

Correct, it'd make life better if we had this, but we don't technically need it. Therefore, not major/critical.

Thanks,
-Derek

Issue tags:+Needs change record

Although this got committed way, no Change Notice was written. I discussed this with Swentel in Dublin at Drupal Dev Days, and I'll write the change notice with examples.

Version:7.x-dev» 8.x-dev

Here is a first draft of a D8 change notice for the two new hooks. Changing version to D8for now (can change back to D7 and reassign to Dave Reid once the change notice is agreed.)
----------

As of Drupal 8.x, two new alter hooks are available in Field API:

hook_field_formatter_settings_summary_alter()
hook_field_formatter_settings_form_alter()

The new hooks allow developers to alter the field formatter settings form in Field UI. A typical use-case is to extend a field formatter with a new setting, which can be used later when rendering the field, e.g. in hook_preprocess_field().

These hooks were previously provided in Drupal 7.x by the Field Formatter Settings API module in Contrib.

Usage

In this example, we will add a checkbox setting to a field formatter, and retrieve the setting in hook_preprocess_field().

Drupal 7

(requires Field Formatter Settings API module)

<?php
/**
* Implements hook_field_formatter_info_alter().
*/
function hook_field_formatter_info_alter(array &$info) {
 
// Add a setting to a formatter type.
 
$info['foo_formatter']['settings'] += array(
   
'mymodule_extra_setting' => FALSE,
  );
}
/**
* Implements hook_field_formatter_settings_summary_alter().
*/
function hook_field_formatter_settings_summary_alter(&$summary, $context) {
 
// Append a message to the summary when foo_formatter has
  // mymodule_extra_setting set to TRUE for the current view mode.
 
if ($context['instance']['display'][$context['view_mode']]['type'] == 'foo_formatter') {
   
$display = $context['instance']['display'][$context['view_mode']];
   
$settings = $display['settings'];
    if (!empty(
$summary)) {
     
$summary .= '<br />';
    }
    if (
$settings['mymodule_extra_setting']) {
     
$summary .= t('My setting enabled.');
    }
  }
}
/**
* Implements hook_field_formatter_settings_form_alter().
*/
function hook_field_formatter_settings_form_alter(&$settings_form, $context) {
 
// Add a 'mymodule_extra_setting' checkbox to the settings form
  // for 'foo_formatter' formatters.
 
if ($context['instance']['display'][$context['view_mode']]['type'] == 'foo_formatter') {
   
$display = $context['instance']['display'][$context['view_mode']];
   
$settings = $display['settings'];
   
$settings_form['mymodule_extra_setting'] = array(
     
'#type' => 'checkbox',
     
'#title' => t('My setting'),
     
'#default_value' => $settings['mymodule_extra_setting'],
    );
  }
}
/**
* Implements hook_preprocess_field().
*/
function hook_preprocess_field(&$variables) {
 
// Provide an extra variable to the field template when the field uses
  // a formatter of type 'foo_formatter'
 
if ($variables['element']['#formatter'] == 'foo_formatter') {
   
$entity_type = $variables['element']['#entity_type'];
   
$field_name  = $variables['element']['#field_name'];
   
$bundle      = $variables['element']['#bundle'];
   
$view_mode   = $variables['element']['#view_mode'];
   
$formatter_settings = field_formatter_settings_get_instance_display_settings($entity_type, $field_name, $bundle, $view_mode);
   
// make the setting available in the field template
   
$variables['mymodule_extra_setting'] = $formatter_settings['mymodule_extra_setting'];
  }
}
?>

Drupal 8

<?php
/**
* Implements hook_field_formatter_info_alter().
*/
function hook_field_formatter_info_alter(array &$info) {
 
// Add a setting to a formatter type.
 
$info['foo_formatter']['settings'] += array(
   
'mymodule_extra_setting' => FALSE,
  );
}
/**
* Implements hook_field_formatter_settings_summary_alter().
*/
function hook_field_formatter_settings_summary_alter(&$summary, $context) {
 
// Append a message to the summary when foo_formatter has
  // mymodule_extra_setting set to TRUE for the current view mode.
 
if ($context['formatter']->getPluginId() == 'foo_formatter') {
    if (
$context['formatter']->getSetting('mymodule_extra_setting')) {
     
$summary[] = t('My setting enabled.');
    }
  }
}
/**
* Implements hook_field_formatter_settings_form_alter().
*/
function hook_field_formatter_settings_form_alter(&$element, &$form_state, $context) {
 
// Add a 'mymodule_extra_setting' checkbox to the settings form
  // for 'foo_formatter' formatters.
 
if ($context['formatter']->getPluginId() == 'foo_formatter') {
   
$element['mymodule_extra_setting'] = array(
     
'#type' => 'checkbox',
     
'#title' => t('My setting'),
     
'#default_value' => $context['formatter']->getSetting('mymodule_extra_setting'),
    );
  }
}
/**
* Implements hook_preprocess_field().
*/
function hook_preprocess_field(&$variables) {
 
// Provide an extra variable to the field template when the field uses
  // a formatter of type 'foo_formatter'
 
if ($variables['element']['#formatter'] == 'foo_formatter') {
   
$entity = $variables['element']['#object'];
   
$view_mode = $variables['element']['#view_mode'];
   
$field_name = $variables['element']['#field_name'];
   
// get the field formatter settings...
   
$entity_display = entity_get_render_display($entity, $view_mode);
   
$field_display = $entity_display->getComponent($field_name);
   
// make the setting available in the field template
   
$variables['mymodule_extra_setting'] = $field_display['settings']['mymodule_extra_setting'];
  }
}
?>

Notes

  • In Drupal 7.x, the formatter $summary variable was passed into hook_field_formatter_settings_summary_alter() as a string. It was typically necessary to add a <br> to keep the summary display tidy.

    In Drupal 8.x, the $summary variable is an array passed by reference, so there is no need to add the <br> manually.

  • The function signature of hook_field_formatter_settings_form_alter() has changed in Drupal 8.x
  • In Drupal 7.x, field_formatter_settings.module provided a helper function to retrieve the field formatter display settings: field_formatter_settings_get_instance_display_settings().

    In Drupal 8.x, the field formatter settings can be retrived using entity_get_render_display() and EntityDisplayBase::getComponent().

@andrewmacpherson Can you create the change notice, looks good to me, then we can close this one as I'm pretty sure it's better to just keep the formatter settings module in contrib for D7.

Hi,
For drupal 7, in which module this https://drupal.org/node/945524#comment-7587155 will be integrated please?
Coming from: https://drupal.org/project/linked_field this hooks are necessary, right?

Thanks for your reply in advance! Greetings, Martijn

Title:Field formatter settings hooks in coreChange notice: Field formatter settings hooks in core
Priority:Normal» Critical
Status:Needs review» Needs work
Issue tags:+Needs change record

#81 has draft that should be posted

Issue tags:-Needs change record

#83 Summit: For Drupal 7, use the Field Formatter Settings module.

Issue tags:+Needs change record

d.o tag monster.

Priority:Critical» Major
Issue tags:-needs backport to D7

Change notifications are major

I added the change record from #81, with a minor change in the first sentence to make it clear the hooks are in Field UI API (rather than Field API).

https://drupal.org/node/2130757

Closing issue, per #82

Issue summary:View changes
Status:Needs work» Closed (fixed)

BTW, we should stop hijacking tags and add a "Needs change notification" status.

@klonos - that is a wonderful idea! "Needs change notification" has become a part of our mainstream workflow.

The best place to suggest this would be in the drupal.org infrastructure issuequeue.

Vvv

@klonos - that is a wonderful idea! "Needs change notification" has become a part of our mainstream workflow.

The best place to suggest this would be in the drupal.org infrastructure issuequeue.

Vvv

@klonos - that is a wonderful idea! "Needs change notification" has become a part of our mainstream workflow.

The best place to suggest this would be in the drupal.org infrastructure issuequeue.

Vvv

@klonos - that is a wonderful idea! "Needs change notification" has become a part of our mainstream workflow.

The best place to suggest this would be in the drupal.org infrastructure issuequeue.

Vvv

@klonos - that is a wonderful idea! "Needs change notification" has become a part of our mainstream workflow.

The best place to suggest this would be in the drupal.org infrastructure issue queue.

Okay that was weird. Sorry about duplicate comments. Timeouts on a flaky connection ;-(

Title:Change notice: Field formatter settings hooks in coreField formatter settings hooks in core
Issue tags:-Needs change record

Fixing title and tags.