Jump to:

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.

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.

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.

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.

@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/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.

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.

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.

... 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?

#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.

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? :)

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.

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.

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().

/** * 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.