Block library content

Each base field already has an attribute telling if it is suitable for display building or not: FieldDefinition::isDisplayConfigurable() (more precisely: BaseFieldDefinition::isDisplayConfigurable()).

Checking each field against this method will be efficient to remove the fields we don't want without maintaining our own "black" list.

However, we will lose a few fields we want, like node:title, so we may need a "white" list instead.

Can you create an UI Patterns issue?

We can propose to annotate the source plugin definitions generated by EntityFieldSourceDeriverBase with a ui_hidden boolean attribute: true only for fields:

• with:isDisplayConfigurable() === TRUE
• some selected fields: "Label/Name/Title", "Authored on", "Authored by", "Changed by"... which ones exactly?

And then do the filter in BlockLibraryPanel.

(Layout Builder is doing such annotation with _block_ui_hidden but is not using it in UI)

Or, we can use the "standard" no_ui if it is not hiding them also for UI Patterns source selector for slots.

Are you OK with such proposal?

Ticket created #3624220: Add ui_patterns_source_choices hook

Tested with the current MR & https://git.drupalcode.org/project/ui_patterns/-/merge_requests/573

So, if my understanding is correct, we are keeping both:

• the fields with FieldDefinition::isDisplayConfigurable('view') === TRUE
• the fields with created & changed

So, I need to check:

• if it is not removing the fields also for #3546198: Add display_builder_entity_form sub-module
• if we are not removing too many fields, and if some other simple rules can be proposed

For example, would we want to keep the field marked with "⚠️" or "❓" ?

It is particularly sensible for Users entities. It would be hard to build a display with just changed, created & picture fields.

It is particularly sensible for Users entities. It would be hard to build a display with just changed, created & picture fields.

A solution may be to finally not rely on FieldStorageDefinitionInterface->isDisplayConfigurable('view) for base fields but to filter them out according to where they come from, like:

• the ones from RevisionLogEntityTrait::ownerBaseFieldDefinitions(): revision_created, revision_user, revision_log_message
• the one from EntityPublishedTrait::publishedBaseFieldDefinitions(): published
• those ones from ContentEntityBase::baseFieldDefinitions(): id, uuid, revision (Revision ID), langcode (Language)
• those ones from EntityFieldManager::buildBaseFieldDefinitions(): revision_default, default_langcode (Default translation), revision_translation_affected
• this one found from some entity types: weight (boolean)
• and path (URL alias), but i don't know where its is added

It is relevant in my opinion because we know those fields already, they are strictly defined in code (careful, they are sometimes aliased, see ContentEntityTypeInterface::getRevisionMetadataKey()).

So, we will get those results:

@mogtofu: is it good enough? It is already cleaner :)

I can init a MR if you are OK with the proposal.

Giving a quick try.

Hello Jean

What do you think about this proposal without ::isDisplayConfigurable()?

I am the one who proposed to use in #3 but I know believe it was a bad idea.

I didn't' inject new service but I reused the one already adding in the first MR.

What do you think?

Published: the code hides it which is right for Display Builder: status is not something to display. You missed it in your table.

I kept it in purpose, because i was picturing displays rendering the published status as an icon or a label.

Weight: 'weight' => 'boolean' never matches, term and menu link weight are integer. So Weight is still listed.

👌 It was done for reorderable entity types like Taxonomy Term, i will add a comment.

Language: langcode is hidden by its key, but preferred_langcode and preferred_admin_langcode on user stay, and other entities have their own. Hiding the language field type covers all of them.

Done in purpose too. preferred_langcode and preferred_admin_langcode are "business" fields, telling stuff about the user, not internal/technical fields to make the translation API work. I would advice to keep it, administrators building User entity displays are supposed to be knowledgeable site builders.

Crash: field_display_full and field_display_teaser are still listed. They are ui_patterns_source fields, the recursion crash of this issue. Hiding that field type covers them whatever their name.

👌 The logic address only base fields now, but i can add a check by type, which will be useful for this use case.

Possible fatal: $definitions[$field]->getType() assumes the base field exists. Using getFieldStorageDefinitions() with a null check avoids it, and also sees config fields.

👌 OK, will do

The test is still named testHideNotDisplayConfigurableFields.

👌 Ok, will rename.

Password: HIDE_CHOICE_ID only matches field:user:user:pass, the bundle-less field:user::pass (Views context) leaks. Hiding the password field type covers both, and any custom entity.

👌 Ok, this is the opportunity to merge the 2 mechanisms.

Per entity type: node: promote, sticky. user: init, mail. comment: thread, hostname, entity_type, field_name.

I would like to avoid checks by entity types, to not open the Pandora box. I will check comment entity type anyway.

Email is also personal data, so I would hide it by default.

Is it the scenario are we trying to avoid?

• Someone with "Administer account settings" and "View user information" permissions but not with "Administer users" or "View user email addresses permission wants to know the mail of an user
• They add the email field in a display and publish (they need to publish because they are working with a fake entity while building)
• They look in the user page to get the email
• They rollback the display to the previous state

As we are not opening something not possible before, then it's ok for me to not be so defensive.

I didn't see your comment and I have hidden email in my update: https://git.drupalcode.org/project/display_builder/-/merge_requests/429/...

Entity keys: id, uuid, revision, langcode, published, default_langcode, revision_translation_affected

All covered except published because I can picture uses case when we want to add a renderable (a chip, a macaron..) to show the content publishing status. But I may be wrong and it is easy to add.

Revision metadata keys (already includes revision_default)

Already the case, I guess.

Field types: password, path, language, ui_patterns_source

Done.

Per entity type: node: promote, sticky. user: init, mail. comment: thread, hostname, entity_type, field_name.

Mail hidden. Others kept.

Plus weight by name.

Covered.

Changed to 'weight' => 'integer'.

Oopsy. Thanks.

I can't believe I removed published base field in one of my commits 🤦