If you're going to add this as a config option for the module without advanced notice (like announcing and waiting a release cycle), I agree it will be least disruptive for existing users to have the default setting match current behavior.
If you notify users between releases that the change is coming in an upcoming release, ensuring it's visible on the module description page, then changing the default behavior from what it is now should reduce the risk that any users are caught off guard by the change and then it becomes the standard behavior.
hestenet → credited r.aubin → .
Changing status because currently I'm unable to add a sub page guide.
I've started the process of stubbing out module docs here. We'll need a maintainer to link them to the module once they have been reviewed and approved:
https://www.drupal.org/docs/extending-drupal/contributed-modules/contrib... →
hestenet → credited r.aubin → .
Looks good @pfrilling
I agree with the proposed categories in #4, but we might consider "Automation" given it's in the name of the module and once configured will perform an action without further input.
I agree with @bhogue's suggestions in #4
I agree with SEO and Administration tools. It looks like "Site Structure" is struck out currently, but I think keeping that as the 3rd category (or maybe even ranked 2nd) makes sense. It's an extension of your content model, defining how it gets exposed to end users by URL.
1. SEO
2. Site Structure
3. Administration tools
@zetagraph - I added one comment on your MR if you can take a look when you have a moment
Looks good, thanks!
@rkoller, was the intent of this issue to reduce the allowable character length of this input or the visible width of the input field?
Adjusting the width of the input based on viewport size so it doesn't end up really wide would be nice, but is a separate thing from the allowable input character length. Also, the WCAG section you referenced pertains to blocks of text, not form inputs, so I don't think that should apply here and the input's maxLength shouldn't be different for users with different viewport sizes.
The open MR that @Tabestan put together addresses just the maxLength not the input's physical size.
griffynh → credited r.aubin → .
Reviewed, looks good!
Added to dev
@pfrilling looks good and tested. Definitely helps make it clear to site builder what fields are affected on the display forms. Thank you!
r.aubin → created an issue.