Overview

In #3454125-53: Implement temporary design system for the DrupalCon Barcelona demo, it became apparent that the ComponentPropsForm suddenly was being rendered in the new default theme!

This broke the live updating that #3462441: Contextual form values need to be integrated with Redux: start with single-property field types added.

Proposed resolution

  • Hardcode the theme to stark (see #4) using a ThemeNegotiator for XB API routes.
  • Follow-up to ensure that whichever theme we hardcode is checked during installation and is not uninstalled — i.e. remains available. (Longer term: do allow the theme to be changed?) (Not doing: #5.)

User interface changes

None.

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:

Comments

Wim Leers created an issue. See original summary.

wim leers’s picture

Issue summary: View changes

Can't get any core theme so far to break it. Perhaps there really was something exceptional about https://www.drupal.org/project/demo_design_system? 🤔

We'll have to figure out what.

lauriii’s picture

I don't think we should spend time figuring out what in that theme is breaking this. Regardless of the reason, we should ensure the forms are rendered with a theme that is known to work. I'm wondering if we should use Stark for this? Or maybe we could use a hidden theme specifically created for this so that it's not visible through the UI.

lauriii’s picture

do allow the theme to be changed?

Why would we allow that? I don't see why would anyone do this.

wim leers’s picture

Title: Changing default theme can break HTML forms generated by XB API routes » Changing default theme can break HTML forms generated by XB API routes: always negotiate the Stark theme
Issue summary: View changes

Yay for #4 and #5. Great.

I'm wondering if we should use Stark for this?

Let's do this. And then let's get @bnjmnm to sign off on it.

wim leers’s picture

utkarsh_33 made their first commit to this issue’s fork.

utkarsh_33’s picture

Assigned: utkarsh_33 » Unassigned
Status: Active » Needs review
wim leers’s picture

Assigned: Unassigned » bnjmnm

@utkarsh_33: there's 2 nits to address, but they aren't commit-blocking.

I did find this doesn't actually quite work yet though, for subtle/tricky reasons, and I'm not quite sure how to proceed. I think @bnjmnm has ideas around this: https://git.drupalcode.org/project/experience_builder/-/merge_requests/1...

utkarsh_33’s picture

Addressed feedbacks.

wim leers’s picture

👍 Still needs final review from @bnjmnm.

wim leers’s picture

Issue tags: +blocker

Stressing the importance

bnjmnm’s picture

Brute force Stark as a dependency is fine.

wim leers’s picture

Assigned: bnjmnm » Unassigned
Status: Needs review » Reviewed & tested by the community

Great! I wasn't entirely confident that this made sense from a semi_coupled.engine POV — so great to have your +1 😊

wim leers’s picture

Assigned: Unassigned » tedbow

Needs final sign-off from a BE reviewer. It's late in the European day, so asking @tedbow.

wim leers’s picture

Assigned: tedbow » Unassigned

Actually … I think @bnjmnm's sign-off alone is more than sufficient. No need to succumb to CODEOWNERS as an iron first.

This helps accelerate #3454125: Implement temporary design system for the DrupalCon Barcelona demo, so bypassing approval for this MR…

  • Wim Leers committed 656f7095 on 0.x
    Issue #3469686 by Wim Leers, utkarsh_33, lauriii, bnjmnm: Changing...
wim leers’s picture

Status: Reviewed & tested by the community » Fixed

Status: Fixed » Closed (fixed)

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