Settings have no affect on the field if it is in a Paragraph bundle

I experienced the same issue using paragraphs module.
See my patch.

Looks good!

Some patches cannot be applied together, or make other patches obsolete.

The patch from #2 seems to make #2735633: Text fields empty after saving a form #6 obsolete, as it fixes that issue as well.

On the other hand, it cannot be combined with the patch from #2728477: 500 error on add taxonomy term form submit #2, so I combined those two in a new combined patch. I hope it still makes sense.

A new (dev-)release would be highly appreciated, to clean up all these conflicting patches.

This is not how we handle patches on d.o. Since this still applies, this stays RTBC. If this not the case anymore, we have to work on this.

I see what happened, annoying, sorry about that.

@rolfmeijer no worries. Do you want to try fixing the tests so we can get this committed?

I already had a go, but with no success yet. But I will absolutely try again.

Updating the patch in #2 to apply to the current field widget names.

#12 is working for me. Thanks!

I found a bug where this patch throws an error when a block entity doesn't have the method Drupal\block_content\Entity\BlockContent::getTargetEntityTypeId() when managing Custom Block fields which use the Drupal\field_ui\Form\FieldConfigEditForm. I patched #12 to check if the entity exists and it has the getEntityTypeId() method since the first block of the if statement works fine in this scenario. This probably isn't the most elegant solution, but I thought I'd share the patch as a crude fix to the bug.

Oops, bug in 14 is my mistake, shouldn't have messed with the config edit form. Here's a slimmed down version of 12 that should avoid that.

Works for me.

+1 RTBC
Code makes sense. Works as advertised.

+1 RTBC. Patch works for me, thanks.

+1 RTBC - definitely fixes the issue.

+1 RTBC. Patch in #15 fixes the issue for me too.

+1 RTBC Patch from #15 is working as expected

#15 works for me too. Great work.

Not working for me :( I am getting error:
Notice: Undefined index: #entity in better_formats_filter_process_format() (line 70 of /.../docroot/modules/contrib/better_formats/better_formats.module).
Error: Call to a member function getEntityTypeId() on null in better_formats_filter_process_format() (line 71 of /.../docroot/modules/contrib/better_formats/better_formats.module)
Notice: using Drupal 8.3.0-rc2
Sorry, looks like RTBC now, i didnt cleared cache after applying patch.

Just to confirm the patch in #15 is working for me

I found another bug with patch #15. It's similar to #14 and occurs, if the element has no key $element['#entity'] For further informations have a look at https://www.drupal.org/node/2862994

Attached you can find an updated patch to handle this.

+1 RTBC Patch from #27 is working great.

Prior to applying the patch in #27 I had the same issue with all formats showing, regardless of setting, when being used in paragraphs.

After applying the patch only the formats selected show, or are removed entirely when only a single one is selected.

Thanks, moving to RTBC.

Patch #27 also works on my side.

Thx!

+1 RTBC
Patch #27 works for me on core 8.4.2.

Thank you!

I found a related bug, it's additionally failing inside of entity browser forms:
https://www.drupal.org/project/better_formats/issues/2948527

Here's a slightly altered patch that removes the instance check on the formObject. I found a related bug where it was failing this instance check.

It seems when testing if it's an instance of a content entity form it fails on forms that import content entity forms, such as inline entity form, or entity browser forms.

-  if ($form_object instanceof Drupal\Core\Entity\ContentEntityForm) {
-    $entity = $form_state->getFormObject()->getEntity();
+  if (!empty($element['#entity']) && !empty($element['#field_name'])) {

I don't think this instance check is necessary, since we're earlier setting $element['#entity'] and $element['#field_name'].

It looks like the namespace of FilterFormatAccessTest has changed, this patch updates patch 33 with the new namespace.

I still found a situation, where on a new entity within an inline entity form within an entity browser that allows adding new entities, it wasn't firing because $element['#entity'] wasn't set.

This is problematic:

if ($form_object instanceof Drupal\Core\Entity\ContentEntityForm) {
-    $entity = $form_state->getFormObject()->getEntity();

as inline entity forms and entity embed forms, etc don't use the entity from the field definition.

This patch moves much of the configuration from better_formats_filter_process_format and moves it to better_formats_element_info_alter.

This reduces the amount of code a bit and I think makes it easier to understand what is going on. I have tested this on fieldconfig pages, on non-inline entity form fields, inline entity field forms and entity_browser forms.

By removing this:
$entity = $form_state->getFormObject()->getEntity();
Where you're determining the entity from the form object

and replacing it with the entity from the field definition,

$entity = $context['items']->getEntity();

it will remove the risk of the wrong entity being referenced.

Thanks for the latest patch (#36), it did solve the Paragraphs issue, but introduced - unexpectedly - a different one.

The call to FieldDefinitionInterface::getDefaultValue returns a nested array. The value returned by array_shift($default_values); in the latest patch returns an array that looks like this:

[
  summary: '',
  value: '',
  format: '',
]

As a result, any subsequent access to $element['#better_formats']['default_value'] will not work as expected, since a string literal is expected (and not an array object).

The provided patch solves this issue, modifying the previous patch minimally (check interdiff).

patch #37 is causing a warning:

Notice: Only variables should be passed by reference in better_formats_field_widget_form_alter() (line 39 of modules/contrib/better_formats/better_formats.module).
better_formats_field_widget_form_alter(Array, Object, Array) (Line: 501)

I think this line needs to be broken up so a variable is passed into array_shift, since it takes variables passed by reference:
$default_value = array_shift($field_definition->getDefaultValue($entity));

Thanks for the latest patch (#37), I have updated it slightly to fix the notice mentioned above.

Sorry I noticed one issue with my last patch (#39), where I wasn't setting $element['#better_formats']['default_value'] = NULL, but rather a $default_value variable that doesn't exist yet.

Ur right about the warning, my bad.
Looking at the interdiff, I would like to point out that:

+          if (!empty($default_value[0]['format'])) {
+            $element['#better_formats']['default_value'] = $default_value[0]['format'];
+          }

1. ifblocks, especially nested ones are less readable, I would stick to sth more 'flat' like #37.
2. Hardcoding an array element's index is not great practice. array_shift() would offer a better approach, even if it adds an extra step.

Ok, based on the feedback in #41, I've changed it back to closer to 37, but fixing the warning.

The patch works for my project and I could only find some nitpicks, but nothing blocking so RTBC on my end.

1. +++ b/better_formats.module
   @@ -10,6 +10,41 @@ use Drupal\Core\Form\FormStateInterface;
   + * Implements hook_field_widget_form_alter().
   + *
   + * @param $element
   + * @param \Drupal\Core\Form\FormStateInterface $form_state
   + * @param $context
   

   This should either be just the "Implements hook_field_widget_form_alter()." or fully describe the variables.

2. +++ b/better_formats.module
   @@ -10,6 +10,41 @@ use Drupal\Core\Form\FormStateInterface;
   +  if ($field_definition instanceof ThirdPartySettingsInterface) {
   

   Returning early would remove some levels of indentation and improve readability.

   e.g.:

   if (!$field_definition instanceof...) {
     return;
   }
   
   $bf = ...;
   if (empty($bf)) {
     return;
   }
   
   element['#better_formats']...
   ...
   

3. +++ b/better_formats.module
   @@ -10,6 +10,41 @@ use Drupal\Core\Form\FormStateInterface;
   +    $bf = $field_definition->getThirdPartySettings('better_formats');
   

   This variable name would be more readable if it were named after what it is. i.e. $better_formats_settings or since we're allowed to camelcase now $betterFormatsSettings

4. +++ b/better_formats.module
   @@ -10,6 +10,41 @@ use Drupal\Core\Form\FormStateInterface;
   +        $element['#better_formats']['entity_type'] = $entity->getEntityTypeId();
   +        ¶
   +        $default_value = $field_definition->getDefaultValue($entity);
   

   Nitpick: Some extraneous whitespace here.

Just hiding some files.

Here's a patch updated based on the feedback in #43.

Looks good to me :)

Thanks for working on this issue. I can confirm #45 corrects the issue.

Hopefully this can be committed soon.

Committed. Thanks to everyone.