🇦🇺Australia @larowlan

wim leers → credited larowlan → .

This is blocked on 📌 Split model values into resolved and raw Active , 🐛 "There are no users matching '' error message appears after reloading the editor page Active and 🐛 ComponentValidator ignores the set validator and creates a new one Active

Pushed some code that includes a cherry-pick (Squashed) of 📌 Split model values into resolved and raw Active and 🐛 "There are no users matching '' error message appears after reloading the editor page Active that is working on the backend if the core patch from 🐛 ComponentValidator ignores the set validator and creates a new one Active is applied

On the frontend - current status is the autocomplete value (e.g Some node title (3) doesn't validate with ajv as a uri and hence the field is invalid. I have written a transform to translate this to a uri (entity:node/1) but transforms aren't applied until after the field value validates so we might need to revisit that. Started looking at ajv keywords which are a schema extension that adds support for transforms - but these don't work on strings, only on nested data/objects (because the string is passed by value when we call jsonSchemaValidate)

kristen pol → credited larowlan → .

This is blocking for adding autocomplete support to link field widgets in Experience Builder

Seems reasonable.
I imagine the unit test will be difficult to unpick in the future - its a shame we couldn't modify a functional test to test the real thing - but we can deal with that in the future

larowlan → created an issue.

I wonder if filehash module solves issue 2

Addressed that thanks!

🐛 ComponentValidator ignores the set validator and creates a new one Active prevents us from being able to do this using the APIs provided by justinrainbow/json-schema

larowlan → created an issue.

I think I have a way to work around #6 in the meantime

Now there's the answer in #13 there is no distinction now (I think).

This needs to go back to needs work as we should be able to remove a lot more of the FALSE items in this list with custom field overrides.

📌 Allow 6.x version of justinrainbow/json-schema Active is going to be needed here because it uses filter_var to validate URLs and that means entity:node/3 doesn't validate as a valid URI.

https://github.com/jsonrainbow/json-schema/pull/800 is what fixes this upstream but it's only in the 6.x branch.

Yes that's correct

Added 📌 Allow 6.x version of justinrainbow/json-schema Active for adding support for both 5.x and 6.x at the same time

larowlan → created an issue.

Adding ✨ [PP-1] Make link widget autocomplete work (for uri and uri-reference props) Postponed which also requires the 6.3.1 version - the fix in https://github.com/jsonrainbow/json-schema/pull/800 is needed to support entity:node/3 style URIs in experience builder

Do we have a follow up to update justinrainbow/json-schema as this has been fixed upstream now

What's the core bug? Is "core" referring to Drupal core, or some other meaning of "core"?

I guess the first question is - should we be able to map dynamic prop sources in XB to computed fields in Drupal.

If the answer is yes, then I think we need a core issue to flag those comment fields as computed - but we also need an override in XB to add the string semantics (aka the format key from JSON schema) to that we can ascertain what sort of value they hold.

Can you clarify if the expectation is that you can setup dynamic prop sources against computed fields?

Added child meta 📌 Discover cases where is no 1:1 map between field, prop and widget values Active

larowlan → created an issue.

Repurposing this as a parent meta for tracking widget support.

Adding 📌 Multiple fields widget should fully work in the contexual form Active , 📌 Get Options as buttons in Page Data form working Active as additional children

larowlan → created an issue.

larowlan → created an issue.

larowlan → created an issue.

larowlan → created an issue.

This is now green, adding parent meta

Adding parent Meta

The blocker is in

Yep it's a real fail
Closing the contextual link list used to place focus on the trigger but that isn't happening now.
Tried a few things but they all end up in a loop
Will revisit this week

Added the service provider

There were some underscore references left behind. Got rid of those because they're not needed in 2025 - we have native methods

Spot checked some tests locally and its looking good

smustgrave → credited larowlan → .

hooroomoo → credited larowlan → .

📌 Get Options as buttons in Page Data form working Active fixes this

Merged forces with 📌 Get Options as buttons in Page Data form working Active

Ok, new tests are passing 🙌

I think this is small enough to get in without disrupting multi-value.

And then we can tackle the remaining widgets in individual issues with smaller scope.

Got around #5 and media library tests are still passing
The key thing we need to save is the form_build_id, nothing else matters

I have gotten past the issue in #4 now

But then we hit a new issue because this gets modified by OptionsWidgetBase::elementValidate which in turn sees the new value (array) get stored in autosave so that when we publish, we end up with the same issue as #4 😭

I think this will likely require some special casing of options_buttons and anything that subclasses OptionsWidgetBase

Before I go down that route I will revisit why we store the updated entity form fields in autosave, it was for Media but perhaps there's a middle ground where we don't have to.

green now

Removed support for password with an explicit test

Fixed the issue spotted by @longwave

Thanks, committed to 11.x

sounds like this might need to run _before_ trash module?

@skessler and the converse, you can use scaffolding to prevent fingerprinting .txt files like MAINTAINERS.txt from being added. If we change that to MAINTAINERS.md and someone updates, they may be leaking information they didn't intend to.

Plus one from me but with a caveat - @mstrelan discussed some of the issues with nightwatch with me during the week (he's been doing a deep dive on random fails 💙) and flagged that a lot of the tests are doing module installs and role creation via the browser which is obviously slow. Ideally we don't repeat that same mistake and instead have more setup scripts that do this via the API.

This is green

7 e2e fails feels like real things

Postponed 🐛 Component transforms need to be per sourceType, not per component prop Active on this

📌 Split model values into resolved and raw Active needs to go in first because without that we always use the sourceType from the config entity

🐛 Component transforms need to be per sourceType, not per component prop Active for the critical found in the final test fail

larowlan → created an issue. See original summary → .

I'll hoist my work into your branch 👍️

FWIW we used #attached csp_hash support from the CSP module to allow-list the inline JS
There's a lot of great stuff in that module that probably belongs in core as an API

@heyyo mentioned this in 📌 Improve backend API when lots of components Active

From slack

It looks like a POST request, why we need to post anyhting to backend when just loading the page ?

The only open thread is to open a dedicated issue, this is green and ready for review

Annotated the MR

Two open threads, one to file a dedicated issue for the data corruption issue and another to review the use of empty

griffynh → credited larowlan → .

griffynh → credited larowlan → .

Welcome to the team @dieterholvoet - goes without saying but please use one issue per commit for transparency sake.

Thanks for coming onboard

Let me just confirm with @acbramley the other maintainer

Looks good to me

Here's a concrete example use-case - https://www.previousnext.com.au/blog/creating-cards-section-layout-builder

A 'cards' component that has a slot for cards and props for title, intro text and read more link.

You want to prevent adding anything other than card-like components into the slot.

Just to reiterate from above, there's a UX implication here as well as a visual identity one.
One of the issues with LB is the overwhelming amount of component options and restrictions can yield a much leaner experience.
In terms of implementations in the FE, in decoupled LB we were sending restrictions with block metadata and using them to control dropzones - if you visit https://project.pages.drupalcode.org/decoupled_lb/?path=/story/component... and click the ➕ then try to drop the Umami disclaimer into the two col layout you see it doesn't let you.

We should be able to do something similar here hopefully

fubarhouse → credited larowlan → .

Committed to 11.x - thanks!

The module sends an email and needs a subject

Can you elaborate on the use case for hiding the subject?

Committed to 11.x, thanks

We had at one point code that auto created a media entity based on example URIs but remove it because it relied on the magic in findTargetForProps finding a file with the exact uri of the example, which wasn't very precise with things like FileExists::rename.

I feel we're going to keep coming up against this issue.

I'm trying to think of creative ways to get around this.

As I see it the issue is stemming from when an SDC component documents an object as the $ref: json-schema-definitions://experience_builder.module/image we automatically apply a certain storable prop shape that assumes a media entity

But we need flexibility to be able also handle the default value.

We have 📌 Split model values into resolved and raw Active for some of this but I don't know if its going to solve this issue.

I'm spending today on both this and that to try and propose a solution.

We have a default content import solution in core that is used by recipes.

It has support for files in \Drupal\Core\DefaultContent\Importer::copyFileAssociatedWithEntity

We don't yet have support for exporting (still requires contrib default_content module) but perhaps we could depend on default_content module and do the actual exporting of the media/file entities as part of config export/save of patterns.

We could then listen to the 'missing content' event in config sync and run the import?

Longer term we could work with the Recipes initiative to add the exporter bits of default content to core.

Re #22 sorry, will focus on this today

Hey 👋

The contents of the file can be imported via copying it's content and pasting it in the 'single import' form from admin/config/development/configuration/single/import after selecting 'View' as the configuration type and then 'aggregator_rss_feed' as the view - just leave the UUID from the existing one.

If you're using drush, you could also copy the contents of that file into your exported .yml file - again leaving the UUID from the existing one.

The drush approach would allow you to visit admin/config/development/configuration and see a diff between the two files - or you could also do this with git if you were using source control for your configuration files.

In terms of what changed - https://git.drupalcode.org/project/aggregator/-/commit/620743b3e053a660e... is the only change which is:

• Adding a sort
• Ensuring empty items aren't output

LR

Opened 📌 EntityFormController should load auto save state if it exists Active but we might be talking about different things
From your GIF I wonder if that's re-rendering the initial state rather than Drupal not taking into account the saved state in the form.
IE a frontend issue rather than a backend one.

Will tackle both over there if they're related.

larowlan → created an issue.

kristen pol → credited larowlan → .

Ah yeah we don't consider auto save state in the form controller

I'll open an issue on Monday

There's some test fails here because I didn't update the tests to include the 'Article author's password' as a source.

I'm thinking this is a red flag that we shouldn't support password fields ever.

Thoughts?

larowlan → created an issue.

Got to the bottom of the issue ✨ Add an "Include image in display" checkbox to the image field Needs review

Basically FileItem sets a 'display_default' setting to FALSE which ends up in form state because \Drupal\file\Plugin\Field\FieldWidget\FileWidget::formElement sets a #default_value drawn from that.
But because this field is not visible, in \Drupal\file\Plugin\Field\FieldWidget\FileWidget::process it is set to TRUE.
And the code that processes the hidden field in \Drupal\Core\Form\FormBuilder::handleInputElement refuses to set a value in form state because a value already exists and was set from the #default_value.

So that is a bug in ImageItem - we already have an override so I'll add the fix there but opened a concrete core issue - 🐛 ImageItem::defaultStorageSettings should override display_default Active

String data needs the StringSemantics constraint in order to match against formats etc, so added those to password item props.

The comment_last_name field is computed, so marked that as unsupported (core bug).

Also updated the comments for path fields because the whole field item list is computed.

Looks like this was pretty simple in the end, sorry for being the one who introduced the install in beforeEach

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

benjifisher → credited larowlan → .