🇦🇺🏝.au GMT+10
Account created on 21 November 2008, almost 17 years ago
#

Merge Requests

More

Recent comments

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Just one comment on the MR, fine to self RTBC after that I think

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Thanks! Looks great so far, but needs an upgrade path (post_update function?) for existing Component config entities (anywhere else?) unless those are automatically regenerated with this new expression on cache clear.

They will autogenerate but I _think_ that will create a new component version, so any content pointing at the old version will likely get double escaped. We might want to do an update hook to update the version of any content pointing to that version.

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Credited @shitalb who also asked about this when the issue was private and was added there.

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Moved the private MR to this issue

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

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

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

larowlan created an issue.

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

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

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

@heyyo I've added some changes and additional tests to a new MR here.

The test shows we can recover from:

* Missing component
* New props (including new required props)
* Old props still present

Can you give it a test?

Thanks in advance!

So far so good w.r.t not needing an upgrade path.

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

larowlan changed the visibility of the branch 3532514-robust-generated-props-form to hidden.

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Pushed two extra commits to a new branch in 3470422-be-nice-for-sdc-developers-larowlan

I'm planning to use that approach in 🐛 Deleting or renaming SDC prop will break xb pages using old version of the component Active

Also includes tests (that will fail with the current code in the branch for this issue) for when the missing component has slots and there are child components in those slots.

To resolve that I was forced to go with the approach in 3470422-be-nice-for-sdc-developers-larowlan, which is why I think we need that here. It is a best-effort attempt but without the update path we'll need for 🐛 Deleting or renaming SDC prop will break xb pages using old version of the component Active

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Rather than rely on locale module's parsing of JS, we could also attempt .po extraction with a Vite plugin - the moduleParsed hook in rollup (which Vite uses for building for production) should afford us access to the AST where we could find calls to Drupal.t() in a cleaner fashion that the regex used by _locale_parse_js_file which has had issues in the past

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Pushed the tests per #30 - I don't think they make sense for JSComponents or Personalization so marked them as skipped. Went with a simpler approach than renaming because I think we'll need to alter definitions further in 🐛 Deleting or renaming SDC prop will break xb pages using old version of the component Active and this plumbing lets us do that.

Fixed phpstan while I was at it.

Removing myself from the assigned field because with the basis of these tests in place I can expand on other cases in 🐛 Deleting or renaming SDC prop will break xb pages using old version of the component Active , setting it back to @penyaskito

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

assuming @penyaskito is asleep I'll push a rough skeleton of the test in #30 so I can expand on it in 🐛 Deleting or renaming SDC prop will break xb pages using old version of the component Active

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Working on this on top of 💬 ComponentNotFoundException: Unable to find component Active

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

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

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Typehints?

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Would the primary use case for this be in controllers and form builders?

In which case I think a trait and adding that trait to FormBase and ControllerBase (that already have the request) feels reasonable.

The alternative is we add a new argument resolver to http_kernel.controller.argument_resolver and a HtmxHelper value object that can resolve from the current request.

That would allow people to typehint their controllers with `HtmxHelper $helper` and it would magically resolve like you can do for Request.

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

@ivnish thanks for updating this.

I'm not comfortable merging it without a review from someone who isn't me

I wrote the original patch and there is a security risk here - I'd like someone to validate my 'this is safe because' before I merge it - because if it's not we're in SQL injection land.

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Triggering an error now, and then returning FALSE without calling the access callback in D12 seems like the safest approach.

+1

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Mostly having everything in the one place for editors and not having to explain a new concept/disconnect to them between Page and Node

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

So traditionally we have one content type that is a 'landing page' that has no template and is a free-form starting point using components.
I think what you're saying is we're forced to use Page for that.
Is there scope for a content-type (node type) that isn't using a template but has its own Canvas field?

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

I think this is misunderstanding what the purpose of this issue was due to an out of date issue summary. The purpose here wasn't to fix a theming mismatch, though that's how this issue was initially opened as, it's that we're not wanting to support/maintain the concept of an individual node using Canvas other than via an exposed slot in the content template.

Ah that wasn't clear from the issue summary - thanks for the additional context.

You mean between now and when exposed slots are implemented?

Yes. I was under the impression that exposed slots were post 1.0 - is that not the case anymore?

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Note the theme template in #35 could live in Canvas module with a hook_theme for that suggestion that used 'base hook' => 'field'

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Coming in late here, but this severely hamstrings early adopters and for little gain outside of those using Olivero theme.

Work we had in progress now needs to patch or decorate to reverse this change.

We had already addressed these 'nuances' with a separate approach as follows that I think is more robust.

1) New template field--component-tree.html.twig with zero wrappers

{% for item in items %}
  {{ item.content }}
{% endfor %}

This does away with the > selector issues

2) Simple hook to clobber out display fields that aren't controlled by manage display

<?php

declare(strict_types=1);

namespace Drupal\some_module\Hook;

use Drupal\Core\Entity\EntityTypeInterface;
use Drupal\Core\Field\BaseFieldDefinition;
use Drupal\Core\Hook\Attribute\Hook;

/**
 * Defines hooks for node fields.
 */
final class NodeFieldHooks {

  #[Hook('entity_base_field_info_alter')]
  public function entityBaseFieldInfoAlter(array &$fields, EntityTypeInterface $entity_type): void {
    $hide = ['created', 'uid'];
    if ($entity_type->id() === 'node') {
      foreach ($hide as $field) {
        if (\array_key_exists($field, $fields)) {
          \assert($fields[$field] instanceof BaseFieldDefinition);
          $fields[$field]->setDisplayOptions('view', ['region' => 'hidden']);
        }
      }
    }
  }

}

For us this made the display in the preview match the saved node output without hamstringing the ability to use Canvas to make node based landing pages.

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Testing this against the body field for a markup input, I get a 500 error 'Missing host entity'

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

One thing I noticed is this doesn't work for the media widget

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

The number of e2e fails indicate this needs work

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Found something spurious that might explain the transient nature of this - possible race condition

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

larowlan created an issue.

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

FYI this no longer works anymore.
There was no e2e tests added here and in manual testing:

* sparkline never shows the edit form, it just spins
* image gallery will render with the 3 example values, but as soon as you edit it, it will only ever show the first item selected (even if there are multiple images selected)

Testing with a simple multi-value string shows the same result, only ever the first value is saved.

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Semantically title is the same as aria-label

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Committed to 11.x

Confirmed the existing change record has been updated for the new options.

Nice one folks.

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

I think other user groups have their own project
Eg Melbourne Meetup has a project and uses issues there to assign credit for attendees

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Committed to 11.x and published the change record.

Nice work

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Wrong issue queue?

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Left a review on the MR

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Thanks, I'll cut a 1.2.0 release and add the above to the docs page

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

This one needs a reroll now after 📌 Support dynamic forms using HTMX Active

Fine to self RTBC

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10
🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Seems fine to me, can we have a test attribute in the existing tests that uses this feature and some asserts that it works?

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Hey @joao.ramos.costa - I'd like to get a green pipeline first - https://git.drupalcode.org/project/component_blocks/-/jobs/1779488

will see if I can make that happen here

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Tagging 8.x-1.0-beta6, thanks!

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Committed to 11.x

Published the change record.

Thanks folks.

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

pushed a start on a test but playwright isn't playing nicely locally

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

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

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Indeed is fixed in HEAD

Thanks for the kind words!

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Committed to 11.x

Left the change record as a draft until 📌 Support dynamic forms using HTMX Active is in

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

📌 DX object to collect and manage HTMX behaviors Active is in so this can be re-rolled and the todo resolved.

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Couple of comments on the MR, great work!

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Just one question on the MR

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Confirmed that https://www.drupal.org/node/3539472 has notes about headers per request in #47

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Left a minor question about test coverage on the MR

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Left a comment on the MR

In the original issue @tim.plunkett expressed similar concerns about a fixed list of plugin IDs. I share that concern and have proposed an API addition to resolve that.

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

I don't see any tests that call ::validate and ensure the constraint validator works

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

larowlan created an issue.

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Rebased this off 1.x and added an 'experience_builder.entity' in gathered contexts if it exists.

We'll likely need /xb/api/v0/config/component to also support entity type and ID so we can populate contexts to dynamically filter the available components.

E.g. we won't have field blocks from Page available on Nodes.

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

This definitely blocks any sort of LB update path.
Unfortunately without this it also means we (PNX) won't be able to start using this on client sites.

I think this is probably the next piece in the puzzle after 📌 Add support for layout plugins Active and 📌 Make block.settings.inline_block:* fully validatable Active in a path towards an LB in place update

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Left some questions on the MR

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Rebasing off 1.x

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Updated the CR to make it clear that password.options is optional.
Added docs to core.services.yml and default.services.yml

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Thanks, creating a new release

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

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

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Moved the requirements checking logic to a new private method which enabled me to reduce the cyclic complexity/nesting.

As this was just moving things around I think I'm still ok to mark this as RTBC. So doing so.

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

I will create a 3.0.0 release
Thanks all

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

I updated the change record to add an example of setting the parameters via a services.yml file
Fixed a couple of typos in the MR.
Going to try to simplify the hook_requirements a bit

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

Seems reasonable to me.
Can you provide a snippet of docs for the additional settings that I can add to the project page on merge?

🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

There is already hook_mail_alter in core, that should suffice here
Thanks for working on a patch

Production build 0.71.5 2024