Add configuration import

I have added configuration and an install file to update the Alert Styles select list.

Here's what it looks like now:

I think I understand. Are you saying that config/install in uswds_alert will squash the settings (or the config/install in sitewide_alert)?

I think there is a possibility. There is a chance of one thing clobbering the other. Uncharted territory for me. We probably have to do some testing with a site that has a mock existing setup of sitewide_alert and then see what happens when uswds alert is installed after that.

I've got a bunch of thoughts, but I don't think any of them should block merging. This functions as intended.

• Alert Message field is not required. This seems weird, having an empty alert doesn't seem like a valid use case. But this is probably something we can't/shouldn't mess with because it comes from the Sitewide Alert module?
• On Form Display and Display, is it possible for us to make the field_heading come before message on install? Or is that too complicated because we're adding fields to existing type? It's a simple enough configuration change to make after install, but more asking for my own education about best practices in module architecture.
• i just noticed that Sitewide Alert has a Display Order setting in the configuration. Makes me once again question whether adding the weight field is correct for MVP if there's already a system for ordering alerts built into the base module
• Another thing that's probably not our monkeys or our circus, but why are the Structure settings (Form Display/ Display etc.) for Sitewide Alerts under Configuration/User Interface rather than under Structure? Is this a limitation of modules, or just a choice the authors of Sitewide Alerts made?

Display Order field in configuration

Another question about field machine names. What's best practice for naming fields? I know on the VA we would title our fields very specifically to their context. So the Heading field might be field_alert_heading rather than field_heading.

My understanding is that if two fields have the same name they share some settings and so being specific avoids potential collisions with other fields that someone may have. field_heading seems like it could be pretty common.

Requiring message

I agree about Alert Message not being required seems odd. I wouldn't want to make it required, though, given that we're using that pre-existing field, so that we are backwards compatible.

Order of Heading

We should be able to add Heading before Alert Message without issue.

Display order

I think we can still use Weight and only when it's the same as the another weight do we use the Display Order setting. We can add that to the help text for weight Weight.

Configuration

Where the config page shows is set in the routing file. I'd leave it be.

Field name

Given that this is a field on a custom entity type rather than a node, we're only going a conflict if we add another heading field to it.

Discussion from meeting today:

• What happens if someone is already using a Sitewide Alert and has added their own field_heading?
• We will test to make sure nothing breaks
• Christian will merge this ticket as is

Automatically closed - issue fixed for 2 weeks with no activity.