🇵🇹Portugal @lolgm

lolgm → created an issue.

@pianomansam Thanks for the quick feedback.
I sent the proposed solution to MR.
In the next few days I will not be able to implement the tests, I will try to do it as soon as possible, if anyone wants to help I would be grateful.

lolgm → changed the visibility of the branch 2.x to hidden.

lolgm → created an issue.

lolgm → made their first commit to this issue’s fork.

The attached patch contains the proposed solution.

lolgm → created an issue.

The attached patch contains the proposed solution.

lolgm → created an issue.

The attached patch contains the proposed solution.

lolgm → changed the visibility of the branch 8.x-1.x to hidden.

lolgm → created an issue.

The patch from comment #297 installed without errors but when using the site I got a WSOD screen with the following error:

The website encountered an unexpected error. Try again later.

TypeError: layout_builder_entity_view_alter(): Argument #3 ($display) must be of type EntityViewDisplayInterface, Drupal\layout_builder\Entity\LayoutBuilderEntityViewDisplay given, called in /var/www/html/web/core/lib/Drupal/Core/Extension/ModuleHandler.php on line 552 in layout_builder_entity_view_alter() (line 138 of core/modules/layout_builder/layout_builder.module).
Drupal\Core\Extension\ModuleHandler->alter() (Line: 305)
Drupal\Core\Entity\EntityViewBuilder->buildMultiple() (Line: 239)
Drupal\Core\Entity\EntityViewBuilder->build()
call_user_func_array() (Line: 113)
...

This appears to be happening because the patch removes the import of Drupal\Core\Entity\Display\EntityViewDisplayInterface in the layout_builder.module file.

Attached I leave the patch from comment #297 with the import mentioned above.

Reroll #43 to 1.13.

The attached patch contains the proposed solution.

lolgm → created an issue.

MR !22 solved the problem.
Thanks @b_sharpe.

The problem I reported in #6 was also resolved by MR !7895.

I confirm the problem.
I did a standard installation of Drupal 10.3.0, configured the plugin in the visual editor and disabled all HTML restrictions.
For me the classes that are being removed are "bs_grid" and "row".
I verified that the field is being saved in the database with the expected HTML.
I don't understand much about plugins for CKEditor, but it seems to me that the problem is with the HTML loading by JS.

I believe this issue is related to 🐛 Secondary tabs design is distorted on block view page Active .

I believe this issue is a part of 🐛 Secondary tabs design is distorted on block view page Active .

If it really is, I believe this is a duplicate.

Steps to reproduce

1. Do a standard installation of Drupal (10.3.0 || 11.x-dev)
2. Create a new view for the nodes and enable the default block.
3. Edit the view you just created.
4. Add a contextual filter on the display Block (block_1) of "Content: ID"
5. While configurating the contextual filter, activate the option "When the filter value is NOT available" -> "Provide default value" and select the type "Content ID from URL"
6. Save the contextual filter changes.
7. Save the view and reload the page.
8. Has you can see the display tabs have been deformatted.

As far as I tested, this happens whenever "Provide default value" is used in the contextual filter of a block.

I believe this problem is also related to:
🐛 Views fieldset labels do not render css when adding entity reference. Needs review
🐛 [regression] missing css file in views ui admin UI Active

I think I explained myself badly.

The breaking change I mentioned is in relation to the previous patches in this issue, that is, the block MultipleMenuBlock (multiple_menu_block) which is under development and will be added in this issue.

In this new patch that I suggested, the MultipleMenuBlock will undergo a change in its configuration, so if someone is going to test this new patch on the same instance that tested one of the previous ones, they will have to configure the block again to update its config.

That said, I don't think an update hook is applicable here as it only concerns changes to the component under development.

Patch #42 is incomplete, this is the patch with changes #41.

Patch of changes described in #41

@weseze Thanks for the feedback.

Using this functionality I found two use cases where the implementation was incomplete.

1st - When a node is present in more than one menu, it is not possible to "prioritize" a menu to be the active one.

2nd - When the current node is not present in any menu, and if the option "Hide on pages not included in menu" is not activated, the expected behavior is to render the default menu, however the default menu in the multiple block is the first menu from the configuration list, may not be the intended default.

These two limitations occur due to the block configuration format being just a table with select, not sortable.

In this way, I converted the selection table into a table with the option of dragging, so that it is now possible to select the menus you want and classify them in order of "priority".
Therefore, the first menu selected will also be the default menu if there is no active menu on the current node.

Attention!!!
This is a breaking change.
To be able to make this change, the format in which the selected menus were being saved in the block configuration changed, according to my tests, the only problem is having to configure the multiple menu blocks again.

I found two problems in patch #17.

1st Problem

The module currently allows the use of terms with white space (e.g. “Dummy Example”), after testing the patch I can no longer get the expected behavior.
It seems to me that the problem is in the regex that is used to split the terms:
$exploded_arguments = preg_split('/[,+ ]/', $argument);
This contains a blank space, thus giving rise to this unexpected behavior.

2nd Problem

The contextual filter "Has taxonomy term ID" has an option to "Allow multiple values", which is deactivated by default, however the patch ignores the option and always accepts multiple values.

The attached patch provides a proposed solution for these two problems.

lolgm → made their first commit to this issue’s fork.

I created !MR22 for version 1.11, based on previous patches.
I also implemented a proposed solution to the block title, problem referred in #27 and #28.

lolgm → changed the visibility of the branch 3089134-ability-to-display to active.

lolgm → changed the visibility of the branch 3089134-ability-to-display to hidden.

lolgm → changed the visibility of the branch 8.x-1.x to hidden.

lolgm → made their first commit to this issue’s fork.

The MR!416 is the implementation of MR!409 for 1.1.x.

lolgm → made their first commit to this issue’s fork.

no_ui property

From what I can see, the no_ui property in the field annotation is only used to prevent this from being listed when creating a new field in entities (/admin/config/people/accounts/fields/add-field).

Field form display configuration

The only way I know to prevent a field from appearing in the form's display list is to define the entity's base fields.
Eg. bellow: Defining the fields of the Feed entity (feeds_feed), if I didn't want the title field to be displayed in the form display setDisplayConfigurable('form', FALSE)
https://git.drupalcode.org/project/feeds/-/blob/8.x-3.x/src/Entity/Feed....

/**
  * {@heritdoc}
  */
public static function baseFieldDefinitions(EntityTypeInterface $entity_type) {
  $fields = [];
  ...
  $fields['title'] = BaseFieldDefinition::create('string')
   ->setLabel(t('Title'))
   ->setDescription(t('The title of this feed, always treated as plain text without markup.'))
   ->setRequired(TRUE)
   ->setDefaultValue('')
   ->setSetting('max_length', 255)
   ->setDisplayOptions('display', [
     'label' => 'hidden',
     'type' => 'string',
       'weight' => -5,
     ])
     ->setDisplayOptions('form', [
       'type' => 'string_textfield',
       'weight' => -5,
     ])
     ->setDisplayConfigurable('form', FALSE);
     ...
} 

That being said, it is completely useless in this case...

Feeds item widget

Although I don't see any use case where the feeds item field would be exposed, I think it would be the simplest solution.
Since this field stores internal feed processing information, would it be a good solution to have a readonly option in the widget?

@MegaChriz Thanks for the quick help.

@jnicola Thanks for the patch.

This problem makes it impossible to translate form display configurations of entities that have the Feeds Item field.
For more detailed information, I explained in comment #282
#2546212-282: Entity view/form mode formatter/widget settings have no translation UI →

Here's some help if anyone else comes across this problem.

I have a D9.5 website where I have patch #219 installed and Feeds, Field Group modules.

I encountered a very awkward situation when using this patch:

1. Create a Feed type to import users. (Just create an empty one, the important thing is to add the Feeds item field)
2. Create a tab component in the users form display.
3. Create a translation for this previously created component (/admin/config/people/accounts/form-display/default/translate/{LANG}/edit)

When visiting the form display in the original language I can see that the original label remains as expected and by changing the site language to my secondary language the translated element is also correct.
So far everything is as expected, however, when I return to the form display in the original language, the tabs component label, previously translated, remains with the translated label. Exporting configs, you are able to see that it was actually replaced in the original language.

I came to the conclusion that this is happening due to the problem of a missing widget in the Feeds item field.
It can easily be fixed by adding the patch from the issue:
🐛 Moving "feeds item" field in form display to non-disabled causes PHP error Active

lolgm → changed the visibility of the branch 11.x to hidden.

lolgm → changed the visibility of the branch 11.x to active.

For those who are having problems with placing the delta filter on fields, for example the author field shown by @antongp in comment #2 ( #3182978-2: Sort Reference view by last name of first Contributor → ), you can see more about this problem in issue 🐛 Reference multivalue base fields are missing the "delta" views field Needs review .

Any suggestions for the proposed fix?

lolgm → changed the visibility of the branch 3412267-reference-multivalue-base-2.0.x to active.

lolgm → changed the visibility of the branch 3412267-reference-multivalue-base-2.0.x to hidden.

lolgm → changed the visibility of the branch 3412267-reference-multivalue-base to hidden.

lolgm → changed the visibility of the branch 3412267-reference-multivalue-base to active.

lolgm → changed the visibility of the branch 3412267-reference-multivalue-base to hidden.

lolgm → created an issue.

Correction regarding patch #4.

Twig 3 no longer supports the for format:
{% for .... if ... %}

The attached patch fixes this.

@MukhtarM I'm having a problem with the patch.
It seems to me that something went wrong with the combination of patch #3 and #18.
The code below is referencing a plugin that does not exist in the current patch.

if (!empty($field['field']['id']) && $field['field']['id'] === 'date') {
  $field['field']['id'] = 'views_date_format_sql_date';
}

Could we remove this one?

I'm using D10.1 and patch #22 is working as expected, however, I'm getting the following warning:

Trying to access array offset on value of type null views_date_format_sql.views.inc:34
Undefined array key "field" views_date_format_sql.views.inc:34

The attached patch fixes this problem.

I have the same problem.

After investigating a little, I noticed that when the validation messages for the mandatory fields of the form are shown, all open dialogs (level 1 and level 2) are replaced with the form that gave an error, which means that all open dialogs have the same content.

It seems to me that this problem is happening due to some problem updating the dialogs/forms with AJAX.
However, I was unable to identify the origin of this problem.

I have the same problem.

After investigating a little, I noticed that when the validation messages for the mandatory fields of the form are shown, all open dialogs (level 1 and level 2) are replaced with the form that gave an error, which means that all open dialogs have the same content.

It seems to me that this problem is happening due to some problem updating the dialogs/forms with AJAX.
However, I was unable to identify the origin of this problem.

I created MR !3 with my suggested resolution.
I believe that for this question it is best to use the once function from the core/jquery.once library.

lolgm → made their first commit to this issue’s fork.

Thanks a lot for the help.
Unfortunately the issue #8 patch didn't work.
It seems to me that even with that condition it is not working for BaseFieldDefinition and BaseFieldOverride fields.
Perhaps the best solution is to directly check the type of FieldStorageDefinition, this way we guarantee that we filter only the expected fields.
Example below:

function field_permissions_entity_field_access($operation, FieldDefinitionInterface $field_definition, $account, FieldItemListInterface $items = NULL) {
  $context = ($operation == 'view') ? 'view' : 'edit';
  if (!$field_definition->isDisplayConfigurable($context) || empty($items) || !is_a($field_definition->getFieldStorageDefinition(), '\Drupal\field\FieldStorageConfigInterface')) {
    return AccessResult::neutral();
  }
  $access_field = \Drupal::service('field_permissions.permissions_service')->getFieldAccess($operation, $items, $account, $field_definition);
  ...
}

It seems to me that the problem is being caused by the change implemented in issue 🐛 Invalid context for call to FieldDefinitionInterface->isDisplayConfigurable() Fixed .

function field_permissions_entity_field_access($operation, FieldDefinitionInterface $field_definition, $account, FieldItemListInterface $items = NULL) {
  $context = ($operation == 'view') ? 'view' : 'edit';
  if (!$field_definition->isDisplayConfigurable($context) || empty($items)) {
    return AccessResult::neutral();
  }
  $access_field = \Drupal::service('field_permissions.permissions_service')->getFieldAccess($operation, $items, $account, $field_definition);
  ...
}

This alteration causes the unexpected behavior of allowing the entity's base fields to be validated by the getFieldAccess function, however this is not prepared to receive this type of fields, hence the error reported above.
My suggestion is to check if it is a base field of the entity. If it is, we should not process it with the module's permissions service.
Example below:

function field_permissions_entity_field_access($operation, FieldDefinitionInterface $field_definition, $account, FieldItemListInterface $items = NULL) {
  $context = ($operation == 'view') ? 'view' : 'edit';
  if (!$field_definition->isDisplayConfigurable($context) || empty($items) || $field_definition->getFieldStorageDefinition()->isBaseField()) {
    return AccessResult::neutral();
  }
  $access_field = \Drupal::service('field_permissions.permissions_service')->getFieldAccess($operation, $items, $account, $field_definition);
  ...
}

Or maybe the solution should be implemented at the root of the problem?
Drupal\field_permissions\FieldPermissionsService::fieldGetPermissionType()

I would like to know your opinions about this.

Merge request 3 contains the solution proposed in the issue description.

lolgm → created an issue.