gábor hojtsy → changed the visibility of the branch 3534466-integrate-with-search to hidden.
gábor hojtsy → made their first commit to this issue’s fork.
I didn't know xb was also a problem, hm. My assumption was that if we rename the demo repo it will cause problems for people looking for the old name / systems like drupal forge that offer it as a demo. But it may be redirecting based on https://docs.github.com/en/enterprise-cloud@latest/repositories/creating..., so that may be a better / cleaner solution. That said, I don't think I can do the rename, it is @phenaproxima's repo.
Added the hook to PageHooks.php with the new OOP format instead of procedural. :) Moving to Page component too. And adding as a Drupal CMS release blocker, since picking a metatag media image does not work without this fix in Drupal CMS.
gábor hojtsy → made their first commit to this issue’s fork.
I think for Canvas being consistent with what Drupal does elsewhere on admin pages that look exactly like all the other content admin pages is the best direction. When/if Drupal CMS wants to change that it can :)
This did not only get a manual test, but also automated test, so I think that should be good :)
I also manually reviewed the diff and it looks good to me.
I believe this is the part that is related to the issue:
- behavior_desktop: '5'
- behavior_tablet: scroll
- behavior_mobile: scroll
+ behavior_desktop: '6'
+ behavior_tablet: '6'
+ behavior_mobile: '3'I like the other updates too, which are also very timely: better sample quotes, not linking to example.com, etc. :)
I did not test manually but on patch review it looks good.
Pam pointed out this can be worked around in Byte for now by either removing this section or configuring it to not scroll. So I opened 🐛 Remove "Trusted by world class experts" or remove the scroll setting on it Active which if fixed reduces the criticality of this issue.
gábor hojtsy → created an issue. See original summary → .
I added an MR form of the suggested change to expedite review / inclusion of this.
gábor hojtsy → made their first commit to this issue’s fork.
Neither the phpstan nor the playwright fails are related to this issue, so I think the (basic) MR is ready for review :) If we want to keep the widget in a selective form, we'll need to start from a more strict place, because the lots of advanced elements are too much that appear without this patch :)
gábor hojtsy → changed the visibility of the branch 3531991-experience-builder-has to hidden.
gábor hojtsy → changed the visibility of the branch 0.x to hidden.
📌 Experience builder has limited built-in metatag features, disable advanced form fields there as initial stop-gap Active is pulled from a live use of Drupal Canvas on a service :)
@yoroy, you gave so much to Drupal and had a profound impact on many of us. I learned from you through our repeated exercises how simplifying is almost always possible to the extent where something is still super useful vs. being elaborate and versatile and thus confusing which is what Drupal usually would have done by default :D Even with simplifying text, your persistence fuels me that I can still find a simpler way to say something, which even when I almost give up turns out to be true at the end :D Thank YOU!
Duh that was for XB :D Here is the one for Canvas. Sorry for the noise.
Updated patch with Darren's fix (thanks!).
gábor hojtsy → created an issue.
Patch for composer patches.
Moving to Canvas.
Patch for Canvas for composer patching. I merely do this to maintain xb-demo, not to take sides in what is the best solution.
Also update title and issue summary.
Moving to Canvas.
@catch: you are making solid points IMHO. There is also the situation where the site template developer/creator needs to customize the theme, in which case a fork or runtime dependency is needed. I think if it is a fork, then the user still would not know that it is on them to keep that up to date later with major versions. If it is a runtime dependency then the user can't quite use it as a starterkit, since that can't flatten the dependency automatically. What do you think of that situation?
Thanks all!
gábor hojtsy → created an issue.
gábor hojtsy → created an issue.
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-briefAlso 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 → .
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.