Hello,

When using Global field Render Entity : Site Settings in views, an ID must be set to reference the Site Settings entity you want to display. Fine.

But I found that if you sync your config from a local dev to a staging website, it is not the node ID that is saved in the views .yml but the UUID and it is not the same from one website to another. It is true that the node ID could also not be the same...

So I think, has for the block, it could be a good idea to use a machine name to identify the Site Settings entity in views, and this way it stays the same from a website to another.

Thank you for your attention and time

David.

CommentFileSizeAuthor
#12 3046958-feature-demo.mp411.3 MBid.conky

Issue fork site_settings-3046958

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

anou created an issue. See original summary.

anou’s picture

anou
Primary language French
Location Collonges au Mont d'Or
commented
Title: Use machine instead of UUID for reference » Use machine name instead of UUID for reference in views
anou’s picture

anou
Primary language French
Location Collonges au Mont d'Or
commented

Maybe this issue is the "why" we do not have, and also maybe the solution to have, a machine name for custom entity: https://www.drupal.org/project/drupal/issues/2685749

I also do not understand why we fill the text field with the ID and the views record is with the UUID ?

scott_euser’s picture

scott_euser commented

This makes sense! Would be happy if anyone is willing to contribute a patch with appropriate hook updates

id.conky made their first commit to this issue’s fork.

id.conky’s picture

id.conky commented
Version: 8.x-1.13 » 2.0.x-dev
Assigned: Unassigned » id.conky
Status: Active » Needs work

id.conky changed the visibility of the branch 3046958-use-machine-name to hidden.

id.conky changed the visibility of the branch 3046958-use-machine-name to active.

id.conky opened merge request !66

id.conky’s picture

id.conky commented
Assigned: id.conky » Unassigned
Status: Needs work » Needs review

Rewriting/altering core's Entity area plugin (Rendered entity - Site Setting) not reasonable, as it mainly depends on EntityRepositoryInterface::loadEntityByConfigTarget and EntityInterface::getConfigTarget which are hardcoded to use uuid.

I decided to resolve that another way by creating completely new plugin which have configurable site settings bundle and render all entities with selected view mode.

Regarding hook updates - I don't like the idea to force migrate users who use core solution with hardcoded entity id's as this definetly will break something, especially when site setting type have "Multiple" option enabled.

My test view with that plugin exports to configs like that:

...
header:
  rendered_site_settings:
    id: rendered_site_settings
    table: views
    field: rendered_site_settings
    relationship: none
    group_type: group
    admin_label: ''
    plugin_id: rendered_site_settings
    empty: false
    bundle: sample_setting
    view_mode: default
    bypass_access: 0
...

Need community/maintainer testing & review.

scott_euser’s picture

scott_euser commented

Thanks Bogdan (and nice to see you again!). Could you add a screenshot of what/where you mean so I can understand what to check better?

Thanks,
Scott

id.conky’s picture

id.conky commented
Component: Miscellaneous » Code
StatusFileSize
new 3046958-feature-demo.mp411.3 MB

Hey Scott,
Thanks for reply and nice to see you too :)

I've attached video with demo of new plugin for views area that add's ability to render site setting entities in any region like header, empty results, etc.
The configuration is pretty simple - just select site setting type and it will render all entities from that bundle.
The difference beteen core solution that under the hood it store site setting bundle id, so when feature deployed across different environments the ID linking doesn't become broken (as mentioned in issue description).
That trick would work just fine in scenarios when only one site setting enity exists in selected type.

As an adition - maybe it make sense to add ability to choose site settings by group in configuration form?

scott_euser’s picture

scott_euser commented
Status: Needs review » Reviewed & tested by the community

Thanks! I gave this a test run and can see on config import that the `entity_site_setting_entity` hits the uuid whereas the `rendered_site_settings` now doesn't care about the entity being the same in local or prod but bases it on the site setting type itself now. So LGTM!

+      header:
+        entity_site_setting_entity:
+          id: entity_site_setting_entity
+          table: views
+          field: entity_site_setting_entity
+          relationship: none
+          group_type: group
+          admin_label: ''
+          plugin_id: entity
+          empty: false
+          target: 29d5d5e3-8a85-46be-a8a9-716879e02480
+          view_mode: teaser
+          tokenize: true
+          bypass_access: false
+        rendered_site_settings:
+          id: rendered_site_settings
+          table: views
+          field: rendered_site_settings
+          relationship: none
+          group_type: group
+          admin_label: ''
+          plugin_id: rendered_site_settings
+          empty: false
+          bundle: person_events_speaking_heading
+          view_mode: default
+          bypass_access:

  • scott_euser committed 111fa3b1 on 2.0.x authored by id.conky 
    feat: #3046958 Views area plugin that uses site settings machine name...
scott_euser’s picture

scott_euser commented
Status: Reviewed & tested by the community » Fixed

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.