🇪🇸Spain @penyaskito

In my case, described in #7 and #8, I discovered my issue is that I had two different exposed blocks with (different) exposed sorting options in the same page. As both use "sort_by" and "sort_order", one of them is gonna parse wrong values and throw that error.

I've created ✨ Views exposed sort identifiers are not configurable when also exposed Active in core that fixed it for me. Also ✨ Allow exposed form to preserve URL query parameters Postponed: needs info to be able to use this in BEF. So at the end it wasn't facets related.

Postponed on the core issue-

penyaskito → created an issue.

This:

- needs tests
- need upgrade path tests.
- needs updating provided views in all profiles (and recipes?).

Otherwise might be ready. Marking Needs review for getting feedback before working in tests.

penyaskito → created an issue.

Back to RTBC

@alexpott We don't recreate it: $importer->importContent($content, Existing::Skip);
We are just failing to detect it's existing. That's why the trash context is relevant.

Just remembered about $is_syncing. We don't want duplicated blocks.

Might need tests?

Postponed on ✨ When applying a recipe, we need to trigger an event pre importing content Active . No sense to work on this anymore if we might need to rename the class or whatever. Will serve as a POC it works.

@amateescu You are right. To be honest I think both should trigger events.

I have a working solution locally :-)

Just created ✨ When applying a recipe, we need to trigger an event pre importing content Active

penyaskito → created an issue.

When applying recipes and/or when importing default_content we should trigger an event.
Right now that only happens when a recipe has been already installed (we need an issue in core).

We need to subscribe to that event, and apply the ignore trash context as we already do for workspaces in TrashIgnoreSubscriber::onWorkspacePrePublish.

The problem I'm facing is that AFAIK, this context apply per request, and this content import could happen in batches. So that applied context is lost.

penyaskito → created an issue.

Not saying it won't happen, but smart_date provides 5 widgets.
It might be easier to actually get this into smart_date itself. Or use some custom code if you need it for a project.

See hook_sam_allowed_widget_types_alter (https://git.drupalcode.org/project/sam/-/blob/1.0.x/sam.api.php?ref_type...) as a way to do that.

Search e2e passed on CI. Failures look like random connection mysql failures in a different test.

I fixed the existing test. Not sure if we need to add more or is this enough?

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

Works for me on the console, and code-wise looks clean! Thanks!

I'll make an exception and merge this myself, as Drupal CMS code freeze for rc1 is happening today.

+1 to RTBC.

penyaskito → created an issue.

penyaskito → created an issue.

I'm not sure if this was telephone and was renamed to telephone_default in core, or if it was telephone for the contrib module.
To be safe I added a new id instead of replacing the existing one.

penyaskito → created an issue.

...and tugboat looks great. Green light to commit.

penyaskito → created an issue.

Looks great now.

penyaskito → changed the visibility of the branch 3490079-style-recent-content to hidden.

Neat!

This looks great!
A minor issue I found is by cloning the media view to a block when we have dark settings and accent in Gin.
We probably need to override the ".dashboard .views-view a" color in gin.
See screenhot.

Aside of this detail looks great.

Adding the patched issue as related.

re Facets release: https://drupal.slack.com/archives/C3E9QDZ5M/p1733317648598519

As much as I would like this:

This is great for _linear_ updates. You have one website, with one upgrade path. Not sure how this translates when you have several versions as a "product" has. E.g. Upgrading from 10.3 to 11.1, jumping 10.4.

One of the cons of the actual system mentioned is catching up with numbering when a MR is in progress. Timestamps might solve this in some cases, but not when those are interrelated, which will happen quite frequently if they are part of the same module. So don't think it would solve this.

I'm not sure if this would change how updates are executed when there are several modules, if needs to change. All from module A, then all from module B? All based on timestamp sorting? What happens in the edge case two bundles have the same timestamp?
Can be problematic, but I guess this is solved in Laravel world with their bundles, I just never faced it.

Even if I love how Laravel works for this matter, not sure if it translates well for Drupal. But I'd love we could do OOO for updates.

I'm pretty sure we don't want to remove the manual sorting feature.

In case you want that for a custom project, you can use a custom module with a form_alter.
You probably will want to

unset($form['terms']['#tabledrag'])

too aside of removing the weight column.

Before we work on this, we should wait for ✨ Allow other modules to include their own Navigation blocks during installation Active .
If that lands it would simplify a ton the work needed for this.
If it doesn't, we should use that MR code as a reference.

This is a Drupal CMS stable release blocker for the search filters recipe 📌 Add recipe for search facets Active , as we don't want any patch. I think that's an optional recipe, so might be just "Drupal CMS release target" instead. Feel free to recategorize.

Facets is in beta. My head hurts after discovering I need to do quite some work for upgrading a site from beta1 to beta4.

Do we expect a stable release for January? Is this something we discussed with their maintainers?

Per @pameeela:

Just FYI, we are just one day away from a commit freeze for the RC release of Drupal CMS on Monday, and from there, we won't be able to add any major new features until after version 1 is released on Jan 15.

So I'm sad this might need to wait.

LGTM then.

Wondering if there should be an issue for adding the 'plugin.manager.config_action' service to core.services.yml to allow autowiring or if this was intentional.

This is not strictly speaking a Drupal CMS blocker as there are workarounds, but definitely is a nice to have.

pameeela → credited penyaskito → .

This would be super useful for a bunch of modules. Not having this logic in navigation means having to duplicate it elsewhere (dashboard that I'm aware, potentially workspaces, environment indicator, etc).

Added some comments, but nothing should be blocking. New feature has test coverage.

Hope this can make it to 11.1.

I see Block Content is not installed by default. Not sure if that was overlooked?
If it wasn't, then we definitely need to remove the shortcut.

penyaskito → created an issue.

penyaskito → created an issue.

RTBC, checked it out, ddev rebuild worked as expected, no problems found on quick manual testing.

Not sure if we want to pinpoint dashboard to alpha2, but it's ok if it's safer.

Thanks a lot, @bronzehedwick!

This looks ***awesome***. Didn't expect dark mode to be honest.

That's the one I just renamed to Dashboard, and I intended to have as "Dashboards".

I think the confusion comes from the original report, which was about the navigation item. But we are hiding that now because we will have the "Dashboard" block on the top of the navigation (the one which is already in Drupal CMS, but can't be in every default installation until a RTBC core issue is committed).

I overlooked this, and I like it. Bumping.

I tried to rebase the latest PR but had no luck, too outdated and I wasn't following that closely.
My svelte foo is none. But with the available docs for handling svelte in project_browser I got really close.

I think we still need a block providing a curated set of 3 local recipes to install.
That block is designed to be on the Welcome dashboard.

With that block:

• Should the install happen on the dashboard itself? Not sure.
• Should it follow the "add to cart" pattern? My guess is not, as you only have 3 recipes to install.

I think I might be able to give this is a try if someone helps with the rebase, or if I start from scratch a new MR.

Verified no warnings locally when running the tests.

The diff is tricky because of encoding issues?, but I verified with git diff 6cdb4a9..c45354c --word-diff

Apparently we fixed this in 📌 Resolve warning in tests for numeric argument Closed: duplicate , but actually not.
DrupalCI didn't complain.

penyaskito → created an issue.

I didn't even notice there was a branch here (there was no MR)

I rebased that (the "Default dashboard" is gone now, we will use its title).
I'm closing 🐛 Fix title for admin listing Active as a dupe.

Dupe of 🐛 Multiple dashboard behavior Active

Right now you could say that all dashboards live together now.

But it was already requested (one of the first requests when we started planning on dashboard 2 years ago to be honest): ✨ Dashboards should have the ability to customize path (alias) Postponed

I also find it weird that you get into "Dashboard" (admin/structure/dashboard) and see a listing with a singular heading.

Maybe I'm just overthinking this, if you feel it's important we can change it and revisit after its exposed to a larger userbase.

penyaskito → changed the visibility of the branch 3450629-create-a-mini-browser to hidden.

I created 🐛 Fix title for admin listing Active overlooking this one.

I think the Navigation top-link being "Dashboard" is right, as it gives you access to your main Dashboard. You _might_ have access to multiple Dashboards, but is your "plane cockpit" entry point.

Then in admin/structure you will have "Dashboards", as this is where you can configure your different dashboards. This is consistent with e.g. "Contact Forms" (plural) in the same menu, while the user tab for the contact form is "Contact" (singular)

Does this make sense?

penyaskito → created an issue.

Found that line :-)

Would we want to add it also to the installer?

For the record, 📌 Merge drupal_cms_dashboard into the starter recipe Active . So the Drupal CMS dashboard won't be an independent recipe.

Unless you want everything in drupal_cms_starter, you will need to manually require the dashboard module and create your own dashboards. It shouldn't be hard to get that config from a drupal_cms installation though if you need that.

We hope dashboard will be widely adopted and recipes will emerge for different usecases.

This worked perfectly and has test coverage. Thanks everyone!

penyaskito → created an issue.

The Drupal CMS blocks are on the Drupal CMS recipes already based on the latest designs.
We still don't have default blocks in dashboard, and I think that's fine.