🇭🇺Hungary @Gábor Hojtsy

gábor hojtsy → created an issue.

gábor hojtsy → created an issue.

Posted at https://www.drupal.org/about/starshot/initiatives/ai/blog/seven-essentia... →

I checked how can pathauto be disabled on xb pages in xb-demo. However, it looks from pathauto's simple config that only nodes are enabled for patterns:

enabled_entity_types:
  - user
punctuation:
  hyphen: 1
verbose: false
separator: '-'
max_length: 100
max_component_length: 100
transliterate: true
reduce_ascii: false
case: true
ignore_words: 'a, an, as, at, before, but, by, for, from, is, in, into, like, of, off, on, onto, per, since, than, the, this, that, to, up, via, with'
update_action: 2
safe_tokens:
  - alias
  - path
  - join-path
  - login-url
  - url
  - url-brief

Also this is the only thing that has a pathauto pattern entity:

However when I went to the Pathauto settings page, XB pages seem to be enabled for pattens but no way to disable them:

Where is this enforcement coming from?

Discussing this with Lauri he indicated

I don't think [this] is a must have. You could just disable pathauto for XB pages and rely on the XB built in path generation

Is that possible to configure in Drupal CMS?

Made a change to cover @poker10's suggestion from #4. I think this covers all feedback now?

gábor hojtsy → created an issue.

gábor hojtsy → created an issue.

Unfortunately this person did not come back with updates. Now we have 💬 Request: Moderate Arabic Group Active where a new maintainer was appointed. Closing as outdated.

There was also #2788937: Arabic language moderators are not active → but the person did not come back after waiting for answers. Gave you all the admin roles in the Arabic group, this allows you to add more moderators.

Attached patch for composer patching needs (eg. in xb-demo).

I think some form of this needs to go to XB to make it viable on a site. Not the fix as-is, although it is nicely compartmentalised outside of the normal XB flow to show it is a workaround. Will leave it to maintainers to triage though :)

@mglaman suggests this is caused by pathato being enabled, and indeed, I have pathauto in xb-demo. I don't know if @pameela has pathauto, but I assume she was testing with Drupal CMS 2.x which has it.

When pathauto is installed, this hook is useful to work around this per @mglaman:

  #[Hook('xb_page_presave')]
  public function ensurePathautoSkipped(Page $page): void {
    $page->get('path')->first()->set('pathauto', PathautoState::SKIP);
  }

BTW there is also the problem of path aliases (new or changed) not being saved :/ 🐛 Page path alias is not actually saved Active

BTW there is also the problem of path aliases (new or changed) not being saved :/ 🐛 Page path alias is not actually saved Active

gábor hojtsy → created an issue.

I also ran into this while testing path aliases. This is how it currently (last tagged release) looks when you try to save an XB page with a path alias without a leading slash:

There does seem to be alias validation, when I enter invalid path alias, it does report an error:

valthebald → credited gábor hojtsy → .

kristen pol → credited gábor hojtsy → .

kristen pol → credited gábor hojtsy → .

I think 🌱 Merge the standard and minimal profiles into something in between Active may be roughly the same as this, the goals at least are very much overlapping :)

Flesh out how this relates to core strategy a bit more.

https://new.drupal.org/drupal-cms/launcher is currently available for Windows too. The wording of the suggested text makes it sound like Windows is fine to run on non-production, but maybe making that more explicit would be better. Otherwise it sounds a bit odd. This would be a stronger statement about support IMHO. That Windows is not supported for production does not say where is it supported :)

It is recommended to use Linux or a similar operating system for hosting Drupal websites. Windows is only supported for development environments, not for running sites live in a production environment.

This would explain the validity of https://new.drupal.org/drupal-cms/launcher more than the current proposed text IMHO, which only implies it.

The webform related problem was diagnosed by the XB team as related to the block form validate/submit handlers not being called, because when the autocomplete shows up, it returns the right value, but on save it does not save the converted internal machine name. That is dealt with in 📌 ComponentSourceInterface::submitConfigurationForm and validateConfigurationForm are never called Active (but is not yet working).

jQuery 4 RC1 is out now! Opened 📌 Update to jQuery 4 RC1 Active .

jQuery 4 RC1 is out now! Opened 📌 Update to jQuery 4 RC1 Active .

gábor hojtsy → created an issue.

Makes total sense IMHO.

To clarify "marked as validatable by config schema", FullyValidatable is an opt-in flag to stricter validation, see https://www.drupal.org/node/3404425 →

Tried the latest MR in xb-demo. I unapplied the change to the block to make it a select box, so it is back to needing this fix, then applied this fix. Unfortunately when I try to enter something in the webform autocomplete that is not quite correct (eg. I start typing to wait for autocomplete to return), I get a red error in place of the form saying it did not render. I tried looking in the console logs but no useful data there. I tried reloading but it got into an "undo last action" loop.

The logs have these:

Referrer https://xb-demo.ddev.site/xb/xb_page/1/editor/component/ded7bed0-4370-41...
Message AssertionError occurred during rendering of component ded7bed0-4370-4186-bb97-2ec6490cf548 in Page Awesome Demo Experience Builder (1), field components: Cannot load the "webform" entity with NULL ID.

followed by

AssertionError: Cannot load the "webform" entity with NULL ID. in assert() (line 262 of /var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php).

#0 /var/www/html/web/core/lib/Drupal/Core/Entity/EntityStorageBase.php(262): assert()
#1 /var/www/html/web/modules/contrib/webform/src/Plugin/Block/WebformBlock.php(259): Drupal\Core\Entity\EntityStorageBase->load()
#2 /var/www/html/web/modules/contrib/webform/src/Plugin/Block/WebformBlock.php(112): Drupal\webform\Plugin\Block\WebformBlock->getWebform()
#3 /var/www/html/web/core/lib/Drupal/Core/Block/BlockPluginTrait.php(188): Drupal\webform\Plugin\Block\WebformBlock->blockForm()
#4 /var/www/html/web/core/lib/Drupal/Core/Block/BlockBase.php(36): Drupal\Core\Block\BlockBase->traitBuildConfigurationForm()
#5 /var/www/html/web/modules/contrib/experience_builder/src/Plugin/ExperienceBuilder/ComponentSource/BlockComponent.php(377): Drupal\Core\Block\BlockBase->buildConfigurationForm()
#6 /var/www/html/web/modules/contrib/experience_builder/src/Form/ComponentInputsForm.php(114): Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent->buildConfigurationForm()
#7 [internal function]: Drupal\experience_builder\Form\ComponentInputsForm->buildForm()

Line 259 in WebformBlock is the middle of this:

  protected function getWebform() {
    return $this->entityTypeManager->getStorage('webform')->load($this->configuration['webform_id']);
  }

so if this gets NULL, that does not fulfill what the code expects assuming the default config for the block which is:

  public function defaultConfiguration() {
    return [
      'webform_id' => '',
      'default_data' => '',
      'redirect' => FALSE,
      'lazy' => FALSE,
    ];
  }

Is this considered in the code/XB?

Added the statement to the issue summary :)

Answering myself based on the rule linked, PHP 8.5.0 is at alpha now with a beta expected August 14, 2025 and stable somewhere in November 2025: https://www.php.net/supported-versions -- later PHP versions will not yet be stable when Drupal 12 reaches beta, so it will be PHP 8.5.x for sure for Drupal 12.

Is PHP 8.5 the eventual minimum version of Drupal 12, or is this an interim step?

This currently moves down the dependency to layout_discovery. Is that a module that stays around in core? (There are a lot more criteria of course, but it is also not depended on by Experience Builder or UI Suite that I could find at least).

Woot, so great to see this bug fixed :) I think it was time well spent (pun maybe intended :P)

gábor hojtsy → created an issue.

gábor hojtsy → created an issue.

@mikemadison: For example with PHPStan, you can ignore errors or whole files and directories: https://phpstan.org/user-guide/ignoring-errors#excluding-whole-files, so you would run your tool in CI with configuration that ignores the test files of Upgrade Status. (You would probably want to ignore tests of contributed and core modules in general to speed up your CI, even if you want to keep checking tests of your own custom modules).

As a Drupal core product manager, I agree this would be a generally good feature to have. 'Administer node published status' sounds like a better name indeed.

griffynh → credited gábor hojtsy → .

Added to the menu structure

This is caused by 📌 ComponentSourceInterface::submitConfigurationForm and validateConfigurationForm are never called Active apparently because Webform uses Drupal\Core\Entity\Element\EntityAutocomplete which has a validateEntityAutocomplete which is where the mapping happens. That is defined as an #element_validate on the element which is never called. We could potentially mark this as a duplicate of that one but maybe good to keep a use case specific issue around, especially with the "webform" name where people will encounter it.

Persistent of the field was fixed in 0.6.0, but the problem of the autocomplete not working still stands. That is now down to 🐛 Autocomplete machine name handling does not match to machine name Active which is caused by 📌 ComponentSourceInterface::submitConfigurationForm and validateConfigurationForm are never called Active , so we can consider this one issue fixed.

Sorry for the noise :D Was not very robust with select default for newly placed blocks. This will avoid an error when you newly place a webform component in XB.

With this the default value will also be good.

Also storing the select list patch here for those that need it to make webform work ASAP, although the bug around the autocomplete is in XB not in webform.

Text looks fine. For reference it would appear once at this place, where I drew the jiggly lines.

https://www.drupal.org/core-gates → would define what does the developer tooling gate mean :)

Opened 📌 Add a developer tooling topic to Drupal core Active but that is not where the meat of the description would go based on the structure of the governance there, it would go into the gates definitions, which are d.o docs.

gábor hojtsy → created an issue. See original summary → .

A better gif, sorry for the noise :D

Ben tells me this is a different issue, so reverted to what it had before I took it over, so this problem is still being tracked. Adding back the reference though to make sure that is not forgotten.

I'm running into this in 🐛 Autocomplete machine name handling does not match to machine name Active with the webform block.

Webform uses Drupal\Core\Entity\Element\EntityAutocomplete which has a validateEntityAutocomplete() which is where the mapping happens. That is defined as an #element_validate on the element. I tried the proposed fix in #4, that did not seem to help (change anything at all with what it did).

gábor hojtsy → created an issue.

I tried that, thanks, but that did not seem to change anything.

From what I see src/Element/RenderSafeComponentContainer.php is where the logging comes from which catches all throwables:

  public function renderComponent(array $element): array {
    $context = new RenderContext();
    $element['#children'] = $this->renderer->executeInRenderContext($context, function () use (&$element, $context) {
      try {
        return $this->renderer->render($element['#component']);
      }
      catch (\Throwable $e) {

So I think re-throwing it will still make it end up here and caught wholesale.

Unfortunately we hit this right away when integrating webform with XB. As explained in the issue summary entering the machine name in the block prop works, but not the autocomplete. Unfortunately it is loaded back as a Title (machine_name) so when/if you edit it you need to remember to edit it back to machine name only.

I opened 🐛 Autocomplete machine name handling does not match to machine name Active for that but is a duplicate.

gábor hojtsy → created an issue.

Demo video about the bug attached

gábor hojtsy → created an issue.

gábor hojtsy → created an issue.

kristen pol → credited gábor hojtsy → .

BTW the testimonial component has the same problem, you may want to fix it here to be a div for the quote not a p too or open a new issue :) That at least is conceptually easier since the quote is not conceptualised as a "paragraph" :)

Current:

After changing to div:

The "problem" was that the template has a real HTML paragraph element for this component. Paragraphs can't contain other paragraphs or lists, so the paragraph naturally ends when you enter a list. Then the styling does not apply to that anymore. Once the wrapper is a div, not a paragraph, this is solved. Not semantically very nice but quickly fixed it :D

BEFORE

AFTER (added another list too):

gábor hojtsy → made their first commit to this issue’s fork.

I think its not an 80% use case module. The general consensus earlier was that it is little maintenance but looks like its not quite true. Quoting the other issue:

One of the biggest challenges with the current Telephone module is that it's just a glorified textfield. It has no option to normalize the telephone number - either for the purpose of validation or formatting.

I don't think its worth doing that investment in core given it is not an 80% use case AFAIS. Removing tag as a product manager.

Combined patch for xb-demo until later tagged version includes this.

Based on that updated understanding I proposed an update to the XB error at 🐛 DX: Block plugin full validatability message may be misleading, add concrete next steps Needs review which just got merged. So that explains clearly that we need to add FullyValidatable after all.

gábor hojtsy → created an issue.

gábor hojtsy → created an issue.

Ok I was misguided. FullyValidatable does not mean what the name suggested to me it meant. That config inspector says a tree is entirely validatable does not mean it is FullyValidatable, because FullyValidatable is a strict validation opt-in flag, not a status indication of the validatability of a tree. So it is something that must be explicitly added and is not deduced. In short it means that all values are required by default under the key where it is specified and all keys of a mapping must be present.

More at https://www.drupal.org/node/3404425 →

So yeah we do need to opt in to the strictly validated for webform blocks to show up in XB, sorry for the prior confusion.

Isn't FullyValidatable deduced from the data structure being fully validatable? We would only need to specify it if we want to work around parts of the data structure not being validatable and we want to force it?

While XB does tell us the webform block config is not validatable, it does not tell us why. If you place a webform block and check it with config inspector, nothing under its setting is impossible to validate. (The top level of webform's settings says validatable).

In @wim.leers words:

XB doesn’t use Block config entities
It uses BlockPluginInterfaces aka block plugins
So XB stores a subset of what Block config entities store: only `

settings:
  type: block.settings.[%parent.plugin]

aka block.block.*:settings
See \Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent::checkRequirements() :

$data_definition = $this->typedConfigManager->createFromNameAndData('block.settings.' . $block->getPluginId(), $settings);

But this part is already entirely validatable as proven by config inspector (see screenshot). If we need to add FullyValidatable manually to config trees that are already fully validatable, that sounds like a lot of extra things to do, and it will potentially lead to problems if new not validatable keys are introduced accidentally, which the workaround will paint over and hide.

Made diff permanent for composer patching until a release of webform includes the fix.

Re #13, basically this was missing in my MR compared to #13. I don't think this should be committed as-is but this does make metatag work with XB and not emit any scary widgets :)

      $form['metatags']['widget'][0]['advanced']['#access'] = FALSE;

Also adding the current diff file for composer patching purposes.

This is intended to cause a fatal error, that is what is being tested that Upgrade Status does not collapse on scanning a module with a PHP fatal error in it :) So not sure what you mean here? If we would comment out that line it would not cause the fatal error that we need.

gábor hojtsy → created an issue.

That said, if people want to invest time into this, I don't think it is a problem at all to change this. So removing the needs product manager tag.

Drupal CMS is the primary thing promoted now on drupal.org. From DrupalCon Vienna (2025 October) onwards that will include Umami-like things (known as site templates) that are built-out demo sites of sorts but more complete and include contributed projects and Experience Builder. So the age of Umami is pretty much over at that point as it is unfortunately. I think ideally it is moved to contrib and could flourish as a site template built on XB (keeping the recipes, photos and all that people took so much precious time building). In that light I think investing time into making the core Umami demo better is not necessarily the best thing to do.

There is 📌 Make Umami a testing profile (not shown to users) in preparation of moving to contrib Active and 📌 Deprecate and remove the Umami demonstration profile from core, make it a contributed site template Active .

Updated version of #21 for composer patching :)

Makes sense. Ideally it would not even be needed if the autocomplete would properly hold the value in XB. Rolled that part back in interest of moving this forward :) I think the block validatability changes are noncontroversial :)

I meant to move it to RTBC as the core committer looking at this could consult the security team too :)

I think the UX reviews are properly resolved by simplifying the form. The main thing I see is this needs a proper security team review. It makes confusing two executable paths very easy on the UI and thus makes it easier to run arbitrary executables via Drupal. In the UX review it was raised that some validation could stop it from saving arbitrary executables as valid values, but that still does not rule out excuting things that were placed on the server. I imagine that may be out of scope of the Drupal security coverage, but that is best said by the security team. Otherwise I think this looks good.

Needs work then :)

gábor hojtsy → made their first commit to this issue’s fork.

Ok this now makes phpstan and cspell happy and makes a dent in phpcs :) Good enough for me.

gábor hojtsy → created an issue.

2.0.x now passes gitlab :)

That works beautifully, thanks!