🇬🇧United Kingdom @Dan.Ashdown

Dan.Ashdown → created an issue.

This reason this was an issue for us was that this overwrote our normal page title altering.

Dan.Ashdown → created an issue.

Dan.Ashdown → created an issue.

Thanks @fago, updated

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

doh! thanks @fago

Thanks for the feedback @fago! Updated to document the parameter and support BC.

I've also moved it to an MR.

Dan.Ashdown → created an issue.

This is a duplicate of https://www.drupal.org/project/lupus_decoupled/issues/3353654 🐛 Frontpage ce-api request with query params returns not found Fixed

Dan.Ashdown → created an issue.

Dan.Ashdown → created an issue.

Dan.Ashdown → created an issue.

fago → credited Dan.Ashdown → .

Closing as this is actually part of https://www.drupal.org/project/lupus_decoupled/issues/3354572 🐛 Views: Fix rendering rows to leverage the CE generator Fixed

Dan.Ashdown → created an issue.

Dan.Ashdown → created an issue.

Dan.Ashdown → created an issue.

Dan.Ashdown → created an issue.

Dan.Ashdown → created an issue.

fago → credited Dan.Ashdown → .

fago → credited Dan.Ashdown → .

fago → credited Dan.Ashdown → .

Replaced by https://www.drupal.org/project/lupus_decoupled/issues/3340520#comment-14... 📌 Views support Fixed

Replaced by https://www.drupal.org/project/lupus_decoupled/issues/3340520#comment-14... 📌 Views support Fixed

Outstanding feedback still to be addressed.

1. https://www.drupal.org/project/custom_elements/issues/3333832#comment-14... 📌 Support Views Closed: won't fix
2. https://www.drupal.org/project/custom_elements/issues/3333832#comment-14... 📌 Support Views Closed: won't fix
3. https://www.drupal.org/project/lupus_ce_renderer/issues/3333827#comment-... 📌 Support Views Closed: won't fix
4. https://www.drupal.org/project/lupus_ce_renderer/issues/3333827#comment-... 📌 Support Views Closed: won't fix

Dan.Ashdown → created an issue.

Thanks for the feedback @fago

I've updated the MR to render other blocks. See the new screenshot showing a system block and a global content block.

Having 1 large iframe would be better for that, also speed would improve. As you say though that would mean replicating all the LB interactivity within Vue. I.e. the drag and drop, contextual links, moving blocks between page sections etc which would need to broadcast this back to the parent frame, which would require a bunch of glue code to work with Drupal's LB JS. Personally I think that would be lovely but not an insignificant undertaking (I think this is what you mean that Franz is working on?). I think that could come later?

We're using Tailwind so don't have the issue of needing dom hierarchy for styling but appreciate that a lot of sites will need this. What do you think about adding another URL parameter on the iframe src that allows you to add additional View templates.
i.e. the Vue template is currently /node/_node/layout/_uuid/_.vue The _.vue currently represents the view_mode. If instead we had /node/_node/layout/_uuid/_view_mode/_.vue The _.vue would be the default, but you could add annother template e.g. /node/_node/layout/_uuid/_view_mode/sidebar.vue which contained the appropriate wrapping divs and classes etc. This could be supported by a hook in lupus_decoupled_layout_builder_preprocess_block() that allowed the template name to be set based on the block data?

Thoughts?

nuxtjs-drupal-ce PR: https://github.com/drunomics/nuxtjs-drupal-ce/pull/117

Dan.Ashdown → created an issue.

Sounds good @fago, will action the above feedback from you both.

fago → credited Dan.Ashdown → .