🇪🇸Spain @penyaskito

This doesn't looks like the right solution but avoids all the preprocess warnings:

diff --git a/src/ClientSideRepresentation.php b/src/ClientSideRepresentation.php
index 4637364..2f0d636 100644
--- a/src/ClientSideRepresentation.php
+++ b/src/ClientSideRepresentation.php
@@ -49,6 +49,11 @@ final class ClientSideRepresentation implements RefinableCacheableDependencyInte
     }

     $build = $this->preview;
+    // If it's a block, the preprocess won't have the necessary info and will
+    // throw lots of warnings.
+    if (isset($build['#theme']) && $build['#theme'] === 'block') {
+      $build['#configuration'] += $build['#configuration']['default_settings'];
+    }
     $default_markup = $renderer->renderInIsolation($build);
     $assets = AttachedAssets::createFromRenderArray($build);
     $import_map = ImportMapResponseAttachmentsProcessor::buildHtmlTagForAttachedImportMaps(BubbleableMetadata::createFromRenderArray($build)) ?? [];

This has new tests, removes xb_visible_when_disabled, and behaves the same way as HEAD.
The only issue is that JavaScriptComponent is singled-out:

    $require_status_true = match ($xb_config_entity_type->getHandlerClass('access')) {
      ContentCreatorVisibleXbConfigEntityAccessControlHandler::class => FALSE,
      XbConfigEntityAccessControlHandler::class => ($xb_config_entity_type->id() !== JavaScriptComponent::ENTITY_TYPE_ID),
      default => throw new \LogicException(),
    };

This means that Pattern probably should have had the xb_visible_when_disabled flag too.
NR for confirmation.

LGTM!

Not sure it's a strict requirement, but we might want to track 🐛 Disable additionalProperties in slots, props in SDC json schema Active

wim leers → credited penyaskito → .

penyaskito → created an issue.

@jessebaker Will this still be true with 📌 Selecting multiple components Active ?

wim leers → credited penyaskito → .

wim leers → credited penyaskito → .

This was not catched on the tests. The select "clears" visually, but the data is stored and posted correctly, and after publishing and refreshing the page you can see the values you selected.

The cause is the options are casted as ints in parseValue at function-utils.js. when the values on the select are strings. It happens too in field_xbt_daterange_datelist.
Not sure how to fix this visually AND on the stored data, which requires ints. But hope this helps.
We would need some way to ensure in Cypress that the value selected is actually visible too. We are actually forcing the hidden select.

    // Radix renders these as a hidden element with a button to trigger, so
    // we have to use force.
    cy.get(`@${key}`).select(String(value), { force: true });

but we need to check the button label is changed too to the right value I guess?

Even if the test is passing, when I select a value the select box "clears". We should show the selected option.
I'm guessing this is caused by the change in 📌 Add e2e test and confirm support for date range date list widget Active , as @isholgueras reported this worked for him.

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

Should be green now, great catch @tedbow!

penyaskito → created an issue.

(We can check in tugboat for this MR: https://mr59-be4pskurppwvqfqo7pjfutudyzyllyze.tugboatqa.com/en/admin/str..., login as admin/admin)

I think it makes sense to just wrap in a $dashboard->access('view') check.

It could look weird if you don't have access to a given dashboard that won't be linked, but I guess we can live with that.

Just found that we don't have any test for the listing, so might be a good opportunity to add one.

You sure? there's an extra 2

> 3.2222? Then write it again: 3.22222

penyaskito → created an issue.

Fixed everything from Wim review, added change record draft.

#20 suggestion is great, I'll fix that.

Thanks! Added 🐛 Property constraints validation adding errors to the field element instead of just the property Active for exploring other widgets.

penyaskito → created an issue.

Fixed feedback, thanks!

OK, I'll stop messing around. It's already fixed, just we can't resolve threads.

NW per https://git.drupalcode.org/project/drupal/-/merge_requests/11220#note_49.... We should accept that suggestion, then IMHO we should be good to go.

This happened in #2470952: Path deletion should be removed in path module after content translation removal →

Which you can workaround when these issues land, if I'm not wrong:

https://www.drupal.org/node/3496786 →
https://www.drupal.org/node/3497308 →
https://www.drupal.org/node/3493962 →

We still need to cover #6 tho.

> I don't think that's a good idea, that could be tens or hundreds of thousands of revisions.

Also, I might have some contrib/custom module modifying that message, so we shouldn't touch existing messages at all.

Reviewed the code, checked the test coverage, this looks safe to me.

Added an end-to-end test (as a kernel test). This is ready from my POV.
The test failure is happening in HEAD too.

Per #28, #29, close won't fix. At this point events don't provide any benefits than hooks don't cover already.
Thanks everyone who worked here.

Thanks!

balintbrews → credited penyaskito → .

Easy enough to fix in the browser and test on tugboat :-)

This is still needs a proper resolution.

a) Add a new restricted permission for language.negotiation_url route, flagged with "restrict access".
b) Flag "administer languages" as "restrict access".
c) Change nothing, but document this in language.permissions.yml?
d) Do nothing.

I tempt to think that c is the right one.

Agree this would be testing core, which is not our purpose.

penyaskito → created an issue.

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

function experience_builder_config_schema_info_alter(array &$definitions): void {
  // This allows these blocks to be placed for now, but really the schema
  // should actually be FullyValidatable.
  // @todo Fix this in core or solve this another way in https://www.drupal.org/project/experience_builder/issues/3484666
  $types = ['block.settings.system_menu_block:*', 'block.settings.views_block:*'];
  foreach ($types as $type) {
    if (isset($definitions[$type])) {
      $definitions[$type]['constraints']['FullyValidatable'] = NULL;
    }
  }
}

📌 Define `props` in the context of Block components Active was fixed, but we never did anything with this @todo. Is it time to remove this alter?

Added the related issue where this will be fixed in core.
The comment from @ultrabob is the right workaround in the meantime.

Someone took the time to write more concrete steps for the workaround here: https://www.drupal.org/project/social/issues/3410322#comment-15710653 🐛 Impossible to translate "ago" on the list of private messages Needs work

This is the wrong approach.

You need to translate your view/form mode formatter/widget settings with config translation, not translating a dynamic string with interface translation.

See 🐛 Entity view/form mode formatter/widget settings have no translation UI Needs review for the proper solution. Marking this as duplicated.

As a workaround you can mangle with your yml config files and import them.

I've not been able to reproduce this.

• dashboard 2.x
• layout library 8.x-1.0-beta5 (last release, current HEAD)

do we need tests for this one?

For testing:

Log in having some dashboards.

1. Press Alt + K. Shows the coffee bar.
2. Write a dashboard id. Show show it and link to the dashboard.
3. Write a dashboard label. Show show it and link to the dashboard.
4. Write ":dashboard". Should show only the dashboards.
5. Verify doesn't show any dashboard you don't have permissions to.

@mondrake ghost of drupal past explained another way to reproduce the bug, more realistic, which is not influenced by what connection holds. Added another unit test for covering that.

So even if what you suggest would work in that case (and I hope we can start doing that all over core), wouldn't work on this one.

Updated issue summary to reflect more clearly what we are doing here.

I didn't want to delete such a great writing of alternatives from @pdureau, but moved to the bottom of the IS for clarity.

type hinting? yes. But we would need to wait for 12.x then?

it’s technically possible, quite improbable, that's why I marked this as minor.

penyaskito → created an issue.

You should be able to get a debug backtrace to identify the offending module/config.

I'd look first at your Drush version, or your services.yml file.

Agree. The benefit of having events vs hooks was concepts separation and ability to unit test. This is not true anymore with the new OOO hook system.

I would mark this as closed (won't fix), but I think is worth giving credit to the people that worked on this (which only core maintainers can do). So marking as RTBC for getting a maintainer attention.

That MR is straight copypaste from LayoutBuilderEntityViewDisplay and works as expected. This needs tests tho.

Marking this as duplicated for now. Giving credit there.

So now that 11.1.6 has been released, the icon shows properly with 2.0.0, but not with 2.x-dev.
So I'm gonna revert this for now and postpone it to revisit when 11.2.0 is released.

penyaskito → created an issue. See original summary → .

Trigger summary update.

🏓I forgot about openapi until now, added that 🙈

wim leers → credited penyaskito → .

Back to NR.

Rebased.
Thanks to
defaultValue.tz(tz);

we don't need

-    // We need to set the timezone in the running browser too.
-    Cypress.automation('remote:debugger:protocol', {
-      command: 'Emulation.setTimezoneOverride',
-      params: {
-        timezoneId: 'Australia/Sydney',
-      },
-    });

anymore, so removed. This passes for me locally.

Hope this convinces Wim now :)
Remember that if this is committed we need to mark it as posponed on 📌 Allow XB to be used on all node types Active

Great!

An option could be having on DashboardListBuilder:

  public function buildForm(array $form, FormStateInterface $form_state) {
    $form = parent::buildForm($form, $form_state);
    foreach ($this->entities as $entity) {
      $form[$this->entitiesKey][$entity->id()]['label'] = [
        '#type' => 'link',
        '#title' => $entity->label(),
        '#url' => $entity->toUrl('canonical'),
      ];
    }
    return $form;
  }

🐛 Wrong redirect after Dashboard layout edition Active would definitely help here. Once you save, you are redirected to the dashboard canonical url instead of the listing.

The toolbar caching is definitely an issue, can you create a separate one? We've been mostly focusing on the new navigation.
The idea is that the toolbar/new navigation "Dashboard" link gives you the entry point to all the dashboards.

For the original error:

Warning: Undefined array key "base" in Drupal\views\Plugin\views\query\QueryPluginBase->getEntityTableInfo() (line 302 of core/modules/views/src/Plugin/views/query/QueryPluginBase.php).
Drupal\views\Plugin\views\query\QueryPluginBase->getEntityTableInfo() (Line: 1391)
Drupal\views\Plugin\views\query\Sql->query() (Line: 1493)
Drupal\views\Plugin\views\query\Sql->build() (Line: 1381)
Drupal\views\ViewExecutable->build() (Line: 1451)
Drupal\views\ViewExecutable->execute() (Line: 1514)
Drupal\views\ViewExecutable->render() (Line: 133)
Drupal\views\Plugin\views\display\Block->execute() (Line: 1690)
Drupal\views\ViewExecutable->executeDisplay() (Line: 81)
Drupal\views\Element\View::preRenderViewElement() (Line: 61)
Drupal\views\Plugin\Block\ViewsBlock->build() (Line: 173)
Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent->renderComponent() (Line: 306)
Drupal\experience_builder\Plugin\ExperienceBuilder\ComponentSource\BlockComponent->getClientSideInfo() (Line: 220)
Drupal\experience_builder\Entity\Component->normalizeForClientSide() (Line: 214)
Drupal\experience_builder\Controller\ApiConfigControllers->Drupal\experience_builder\Controller\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 212)
Drupal\experience_builder\Controller\ApiConfigControllers->Drupal\experience_builder\Controller\{closure}() (Line: 224)

For the other error

ViewsData.php:127, Drupal\views|ViewsData->get()
QueryPluginBase.php:302, Drupal\views\Plugin|views|query|QueryPluginBase->getEntityTableInfo()
Sql.php:1391, Drupal|views\Plugin|views|query|Sql->query()
Sql.php:1493, Drupal\views\Plugin|views|query|Sql->build()
ViewExecutable.php:1381, Drupal\views|ViewExecutable->build()
ViewExecutable.php:1451, Drupal|views|ViewExecutable->execute()
ViewExecutable.php:1514, Drupal\views| ViewExecutable->render()
Block.php:133, Drupal\views\Plugin|views|display|Block->execute()
ViewExecutable.php:1690, Drupal\views\ViewExecutable->executeDisplay()
View.php:81, Drupal\ views|Element| View :: preRenderViewElement()
ViewsBlock.php:61, Drupal\views|Plugin|Block|ViewsBlock->build()
BlockComponent.php:173, Drupal\experience_builder\Plugin\ExperienceBuilder|ComponentSource\BlockComponent->renderComponent()
BlockComponent.php:306, Drupal\experience_builder\Plugin\ExperienceBuilder|ComponentSource\BlockComponent->getClientSideInfo()
Component.php:220, Drupal\experience_builder|Entity|Component->normalizeForClientSide()

For the preprocess warnings:

block_theme_suggestions_block()
call_user_func_array() (Line: 355)
Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}() (Line: 307)
Drupal\Core\Extension\ModuleHandler->invokeAllWith() (Line: 354)
Drupal\Core\Extension\ModuleHandler->invokeAll() (Line: 379)
Drupal\Core\Theme\ThemeManager->buildThemeHookSuggestions() (Line: 220)
Drupal\Core\Theme\ThemeManager->render() (Line: 446)
Drupal\Core\Render\Renderer->doRender() (Line: 203)
Drupal\Core\Render\Renderer->render() (Line: 120)
Drupal\Core\Render\Renderer->Drupal\Core\Render\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 119)
Drupal\Core\Render\Renderer->renderInIsolation() (Line: 52)
Drupal\experience_builder\ClientSideRepresentation->renderPreviewIfAny() (Line: 214)
Drupal\experience_builder\Controller\ApiConfigControllers->Drupal\experience_builder\Controller\{closure}() (Line: 593)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 212)
Drupal\experience_builder\Controller\ApiConfigControllers->Drupal\experience_builder\Controller\{closure}() (Line: 224)
Drupal\experience_builder\Controller\ApiConfigControllers->normalize() (Line: 89)

This will even more relevant when ✨ Enum vales do not have translatable labels Active is supported, as the context strings usage will likely increment a lot once SDC components can be translated.

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

I could reproduce this by putting an image component, adding a new image to the media library, and trying to publish it.