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.
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.
The MR!416 is the implementation of MR!409 for 1.1.x.
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:
- Create a Feed type to import users. (Just create an empty one, the important thing is to add the Feeds item field)
- Create a tab component in the users form display.
- 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
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.
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.