Minnesota, USA
Account created on 16 March 2010, almost 15 years ago
#

Merge Requests

Recent comments

🇺🇸United States mtift Minnesota, USA

Every little bit of polish counts. Thanks, all!

🇺🇸United States mtift Minnesota, USA

mtift made their first commit to this issue’s fork.

🇺🇸United States mtift Minnesota, USA

This seems like an excellent idea to me!

🇺🇸United States mtift Minnesota, USA

Add a troubleshooting section

🇺🇸United States mtift Minnesota, USA

Add a link to Drupal CMS

🇺🇸United States mtift Minnesota, USA

Add some more info about configuring Dashboards

🇺🇸United States mtift Minnesota, USA

Add some basic instructions to create a Dashboard

🇺🇸United States mtift Minnesota, USA

Add a basic install link

🇺🇸United States mtift Minnesota, USA

Move basic usage after installation

🇺🇸United States mtift Minnesota, USA

Looks good to me, too. Nice little addition.

🇺🇸United States mtift Minnesota, USA

mtift created an issue.

🇺🇸United States mtift Minnesota, USA

mtift created an issue.

🇺🇸United States mtift Minnesota, USA

This looks like the correct approach to me, too. Thanks, @plopesc!

🇺🇸United States mtift Minnesota, USA

Update the formatting

🇺🇸United States mtift Minnesota, USA
🇺🇸United States mtift Minnesota, USA

I probably should also mention that (at this point) we are working closely with the Drupal Starshot leadership team. They are defining the scope of work 📌 [META] Track 11: Dashboard page for post installation and login Active and we are working to implement it. My guess is that those other dashboard implementations have different requirements.

🇺🇸United States mtift Minnesota, USA

Good idea, @thejimbirch.

First, I agree it would be good to mention these other modules on the project page and I started a list in the description of this module. We have had some discussions with maintainers of other dashboard modules (e.g., https://www.drupal.org/project/dashboards ) and we are definitely open to working together. That said, some of those modules take a different technical approach, so directly incorporating features might be more difficult.

Second, this module grew out of a core idea 🌱 Enhance user experience with customizable dashboards Active and is being built and maintained in a way that might make it a candidate for Drupal core, in addition to Drupal CMS (Starshot). Those modules that you mentioned provide functionality that goes beyond what we might include in core, such as Bootstap or Matomo integration.

🇺🇸United States mtift Minnesota, USA

mtift created an issue.

🇺🇸United States mtift Minnesota, USA

Making this view optional seems like a good idea to me. On the other hand, now that we have Recipes in core, we might want this to be included in the module as a Recipe (or part of a recipe) in the module and included, for example, with a "content editor" Dashboard.

🇺🇸United States mtift Minnesota, USA
🇺🇸United States mtift Minnesota, USA

mtift created an issue.

🇺🇸United States mtift Minnesota, USA

Looks even better in camelCase!

🇺🇸United States mtift Minnesota, USA

Good call. I added the change record.

🇺🇸United States mtift Minnesota, USA

Going forward, the process for validating these config actions will need to be sorted out. It's not clear (to me at least) how strict they should be, or if a recipe should be applied when the config action refers to things that don't (yet?) exist. But this issue is probably not the place to have that conversation.

This plugin works to do something like this (with the minimal profile installed):

name: 'Place a block'
config:
actions:
block.block.whatever:
place_block:
id: minimal_test
theme: default
region: sidebar_second
weight: -10
plugin: system_powered_by_block
visibility: { }

The tests cover other situations, and the PlaceBlock class does a lot of checking already.

This looks great to me. Nice work, @madclu!

🇺🇸United States mtift Minnesota, USA

Makes sense to me. In conversations at DrupalCon and the recent Starshot webinars (Zoom) meetings I think pretty much everyone who mentioned this initiative called it "Recipes." I don't hear people saying "Distributions and Recipes" so it make sense for the name to match what people are saying.

🇺🇸United States mtift Minnesota, USA

I'm pretty sure the intention of the change (with the commit message "Example") was to demonstrate a test failure.

🇺🇸United States mtift Minnesota, USA

mtift created an issue.

🇺🇸United States mtift Minnesota, USA

That was it. Thank you @smustgrave!

FWIW, this looks good to me, too.

🇺🇸United States mtift Minnesota, USA

@alexpott I don't see any comments. Did you add them on https://git.drupalcode.org/project/drupal/-/merge_requests/7910?

🇺🇸United States mtift Minnesota, USA

This one makes sense to me. All of the reply & redirect issues have been addressed per https://www.drupal.org/node/3452650 . The deprecation messages and tests make sense. The feedback has been addressed.

However, I applied the MR on a standard install for 11.x with config inspector and got all green checks, but it shows "1 errors" and I'm not quite sure what that is referring to:

🇺🇸United States mtift Minnesota, USA

So if "every config entity type MUST allow NULL to be set on any class property corresponding to a top-level config entity property" would the implication be that:

  protected array $settings = [];

Gets interpreted as:

  protected array|null $settings = [];

That seems confusing to me.

🇺🇸United States mtift Minnesota, USA

Yes, yes, yes! I fully support this proposal. +1

🇺🇸United States mtift Minnesota, USA

mtift made their first commit to this issue’s fork.

🇺🇸United States mtift Minnesota, USA

mtift created an issue.

🇺🇸United States mtift Minnesota, USA

Since I'm doing issue queue maintenance, it was suggested that I mark a credit for myself. So I'll do that here.

Production build 0.71.5 2024