Fallback patterns and enabling/disabling custom patterns

[Alexnortung]

Feature request

Summary

Currently you have to create a pattern in the database to use a pattern. This means that you have to set up the patterns locally and in production unless you use other tools such as config sync. I think it would give a better developer experience to have a fallback pattern field which can be configured directly on the pluginOptions preferably next to the enable option in the interface.

I also think it should be possible to disable the custom patterns, such that the fallback pattern is the only one being used and cannot be changed by users who don't know what they are doing.

Related issue(s)/PR(s)

This might resolve the problem in #54

[boazpoolman]

I agree having a fallback pattern could be nice.
Also to indeed prevent #54.

Though I wouldn't want to replace the pattern creation in the admin panel completely.
Adding the patterns through the admin panel allows for better validation and all-in-all better user experience.
So a user would still rely on tools such as config sync to handle their config migration.
Just like you would for permissions, roles and other settings.

[Alexnortung]

Great, I think we are on the same page :)

[boazpoolman]

This issue was fixed with this PR and released with version 1.0.0-beta.6.

[Alexnortung]

@boazpoolman nice addition, however I was thinking of a way to do this individually on each content type. Like when you enable url alias for a content type such as "page" you would also get a pattern input field to create a fallback pattern. This pattern could just be saved in the pluginOptions of the content type.
I hope it is okay that I reopen this issue, let me know if it should be a new issue instead :)

[boazpoolman]

Yeah. That sounds like a good next step.

Re-opening the issue is fine! :)