hestenet → credited mtift → .
hestenet → credited mtift → .
hestenet → credited mtift → .
penyaskito → credited mtift → .
volkswagenchick → credited mtift → .
Every little bit of polish counts. Thanks, all!
lostcarpark → credited mtift → .
This seems like an excellent idea to me!
penyaskito → credited mtift → .
Add some more info about configuring Dashboards
Add some basic instructions to create a Dashboard
Looks good to me, too. Nice little addition.
Looks good to me!
This looks like the correct approach to me, too. Thanks, @plopesc!
Update the formatting
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.
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.
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.
hestenet → credited mtift → .
hestenet → credited mtift → .
hestenet → credited mtift → .
hestenet → credited mtift → .
Looks even better in camelCase!
Good call. I added the change record.
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!
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.
I'm pretty sure the intention of the change (with the commit message "Example") was to demonstrate a test failure.
That was it. Thank you @smustgrave!
FWIW, this looks good to me, too.
@alexpott I don't see any comments. Did you add them on https://git.drupalcode.org/project/drupal/-/merge_requests/7910?
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:
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.
Removing the reference to book module
Yes, yes, yes! I fully support this proposal. +1
penyaskito → credited mtift → .
minneapolisdan → credited mtift → .
volkswagenchick → credited mtift → .
I think I got them all
Since I'm doing issue queue maintenance, it was suggested that I mark a credit for myself. So I'll do that here.
volkswagenchick → credited mtift → .
volkswagenchick → credited mtift → .
I don't see any code changes here
volkswagenchick → credited mtift → .