🇦🇺Australia @larowlan

wim leers → credited larowlan → .

poker10 → credited larowlan → .

wim leers → credited larowlan → .

Too heavy a reliance on e2e tests makes the test suite slow and brittle

FYI if we make this a production requirement, we should add a hook_requirements warning people with jsonapi module and assertions enabled that their performance will go through the floor because of that module's response validator.

I've been asked to audit sites for performance and found that combo in production 😱

Thanks, I'll try to get to this sometime this week

I realise I'm in the minority, but I still feel this is a mistake, we're going against best-practice in the FE world. Registering my thoughts for posterity. Hope I'm wrong.

This is where my approach of adding a component source plugin to the config entity came from. We add one for each type (Block, paragraph, SDC) much like media types. Maybe we revisit that?

I think you'd need to look to the date module in D7 for that.

Hi
Thanks for this.
I don't think a bespoke email delay system for workbench email is the correct approach to this.
A generic email delay module would be a better solution.

Thanks again for the patch. There's also some hard-coding of nodes here, which isn't how the module works (it supports all entity-types).
That also makes this ineligible for inclusion in the module.

Thanks

Lee

larowlan → created an issue.

pameeela → credited larowlan → .

griffynh → credited larowlan → .

Shouldn't the url also include entity type and id?

Rather than this being automated, what about an import wizard from the list builder as an action link? When we support blocks that could also be included

I think with some refactoring of theme manager (eg adding methods as extension points) , we could subclass it and not need to duplicate much
But it would require a spike to identify those extension points

I also think storing the link between a react component and a form element plugin should happen via form element plugin definitions. The setializer can read that to work out what should be formatted for hyperscriptify and what should not

This means in the future we can allow modules to opt in their custom elements. The hard coded mapping in the JS could be replaced with a mapping of lazy imports we could share via Drupal settings

This requires changes to vite config for the UI and the use of import maps, but we would need to do that anyway to support UI extension

I can work on a spike on this when I'm back

Symfony setializer defines two interfaces, NormalizerInterface and SerializerInterface. The first one is for turning objects into arrays, the second one is for turning arrays into strings. Eg there's an XmlSerializer, a JsonSerializer. We'd just have a XB template setializer for turning render arrays into a string in our bespoke manner

FWIW search api overcomes these issues using data source plugins, you can index multiple bundles (and even multiple entity types) to the same index. Each field is a combination of property path and data source id. That gives you the root data type. Fields helper even has a filter by data source method which is similar to the isSupported

I concede that the multiple properties syntax is more verbose

I realise it's a strong word, I'm trying to convey that the current approach is not suitable for production sites

I've toned it down

larowlan → created an issue.

larowlan → created an issue.

larowlan → created an issue.

benjifisher → credited larowlan → .

Agree we should try to fix this asap - do we have steps to reproduce though?

Thanks Wim, I'll pick this up again after vacation

If we can make this work, sounds great!

I think this is reasonable.
I wonder how we go about testing it.

Clarifying that this was logged privately to the security team who approved for it to be public

Indeed, fixed thanks

pameeela → credited larowlan → .

This all good @Chris Matthews? I made a D11 release a few weeks back

pameeela → credited larowlan → .

hestenet → credited larowlan → .

hestenet → credited larowlan → .

hestenet → credited larowlan → .

hestenet → credited larowlan → .

hestenet → credited larowlan → .

hestenet → credited larowlan → .

hestenet → credited larowlan → .

It's a pity we can't have MSW wire up to cy.intercept and have the best of both worlds

smustgrave → credited larowlan → .

Are you using a custom template here?

https://www.previousnext.com.au/blog/ensuring-drupal-8-block-cache-tags-...

https://www.drupal.org/project/aggregator/releases/2.2.2 →

https://www.drupal.org/project/aggregator/releases/2.2.2 →

Yep, let's ship it, cutting another release

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

Please see https://git.drupalcode.org/project/aggregator/-/merge_requests/20/diffs - thanks!

Plus one for this - but looks like there's a new fail on PHPUnit next minor? https://git.drupalcode.org/project/entity_print/-/pipelines/242319 is passing in HEAD

Looks great, but let's do PHPStan while we're here - thanks!

larowlan → created an issue.

https://www.drupal.org/project/interval/releases/8.x-1.14 → is packaging now 💪 🏎️

Thanks @TomTech - I'm tagging 8.x-1.14 now

Thanks, can do - are you able to create an MR?

larowlan → created an issue.

There's no logo here yet, so should this be back in the project browser queue?

Thanks for this - there's some linting fails in the new file if you could resolve those - thanks!

Either we add a hook_update_last_removed and remove this hook or we drop support for 10.1

Or both

Yay finally

Also cutting a d11 release

And added a scheduled task so we can catch this sooner when core breaks our stuff next time

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

larowlan → created an issue.

larowlan → created an issue.

Committed to 11.x and backported to 10.4.x and 11.0.x
Waiting for a second opinion about 10.3.x, leaving at RTBC

https://www.drupal.org/project/entity_print/releases/8.x-2.15 →

thanks folks

larowlan → created an issue.

I wonder if we could add a property attribute e.g #[Theme\Variable] and put that on constructor Params and have the theme hook variables inferred

Between the constructor, a factory method, the theme definition and the build method, there's a lot of boilerplate around the variable names

I also wonder if the method that does the build could auto fill # keys from properties with attributes so if you don't need any logic these get passed through to the render array automatically

I can spin up a new issue (or two) for both those ideas if this isn't the best place for it

Luke.Leber → credited larowlan → .

Committed to 11.x and then backported to 11.0.x/10.4.x/10.3.x after confirming with catch

Thanks folks 🚀

d11 here we come, 21 modules down, 38 to go

Looks like we missed https://www.drupal.org/project/jsonapi_menu_items/releases/1.2.6 → , fixed now

Cut https://www.drupal.org/project/a11y_autocomplete_element/releases/1.0.5 →

+++ b/js/a11y-autocomplete.js
@@ -11,7 +11,7 @@
-      if (pillsContainer.querySelector(`[data-option="${option.value}"]`)) {
+      if (pillsContainer.querySelector(`[data - option = "${option.value}"]`)) {
         return;

this is not the correct fix and will break functionality
We shouldn't be using phpcs against JS files

Thanks, great addition!

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

Hi
The first two sound like a perfect use case for our original feature flag... a module that you install/uninstall.
The third one makes me feel a bit icky. I would prefer selective preprocess hooks over a global twig extension.

LR

larowlan → created an issue.

Brought in the value objects and a normalizer. Will continue tomorrow

larowlan → created an issue.

Are these commit messages auto-generated and random?

Na, I'm just having fun with portlandia quotes

#189544: Allow administrator to edit account without email address (regression: accounts can be created without email addresses also) →