🇭🇺Hungary @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!

@godotislate: I don't believe that is a problem, we are testing whether on form submission the entity gets the language, and it appears it does not (likely the third party setting is not saved).

Can you put this into an MR? That way tests would run on it too :)

The remaining fails are around #edit-seo-settings #edit-metatags-0-basic-title of course. I still did not find where this one comes from metatag, but access false-ing the parent does make this inaccessible apparently.

Would be good to get a clear answer from the XB team whether the field should stay and further altering should be put into place (as in #13 but that does not list all the items, see #14) or the field should be removed (which does sound like would be the cleaner solution IMHO).

I understand that @damienmckenna. I don't have an opinion either way, so I personally leave considering that to @lauriii and/or other code owners in this area of XB :) My main aim is to make metatag and XB work peacefully together, I don't have architectural opinions about this, trying to help with whatever is needed :)

gábor hojtsy → created an issue.

Very complete suggestion, thanks! From my visual review, it looks fine, however I don't use config split :) Can you get anyone else review / try it? It looks like it would not have negative side effects at least, but would be good to have another set of eyes/hands on it.

Due to a mismatch in when I checked the credit, the commit credit did not land with @penyaskito and @diegors unfortunately, sorry. The issue credit was properly set though.

gábor hojtsy → created an issue.

I'm not interested, but it is open source of course, so you can create other versions yourself.

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

Most of the calls changed are in static methods, those don't have a $this. Did you actually try if the change worked? Screenshot of it applying cleanly does not prove it works.

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

None of the fruits seemed low enough so released this with one other commit I already had :D https://www.drupal.org/project/upgrade_status/releases/4.3.8 → Thanks again!

Thanks all! I get the irony! :) Hope this helps. Will do a release too later today, but will check first if there are other low hanging fruits to include too.

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

gábor hojtsy → changed the visibility of the branch 3531991-experience-builder-has to hidden.

Had a zoom meeting with Lauri where I showed him the current state. XB has an opinion on what basic SEO fields should be shown and implements all of them as base fields (except the SEO title). So the metatag field is mostly used to wire in the token replacements as shown above in #17. I understand this could be in global config for this entity type. Lauri told me that keeping the field would still be better as it would give the option to create a custom, simpler widget for more complicated SEO settings in the future. I think the field could still be added then, but my aim is to solve metatags not working with XB, not to argue about architecture :)

So attaching a few lines of added code that alters out the metatag section of the form at the existing place where it moves the SEO title field. This works for me, although I don't have the SEO title field somehow in metatag 2.1.1 that I have, so not sure if that would be affected by the #access even though it is moved out of the group. I think for this stop-gap issue that is the remaining question.