Hi,
I've noticed that entity overrides are stored in configuration. Is it a good solution? My main concern is that option to include/exclude specific nodes is available for site admins. To me it's a part of content management, not configuration management. Therefore prior to deploying new configs to prod environment we will need to export simple sitemap configs every time to make sure that admins didn't add another node to exclude list and we won't accidentally override that with dev configs. That's one more thing to worry about during deployment. Will it be better to move such overrides to a custom table?
Comments
Comment #2
gbyte CreditAttribution: gbyte as a volunteer and commentedYou have a good point there, I've been thinking of changing this for a longer time now. It's a bit cumbersome as it will require some small architectural changes and a good hook_update_n to move the existing configuration to the new table. I will look at it next, however I might take some time, as I'm busy with work right now. I'm happy to review patches any time however!
Comment #3
gbyte CreditAttribution: gbyte as a volunteer and commentedI see you tagged this with version 1.x; I'm changing to 2.x as there will be no more changes to 1.x.
Comment #4
gbyte CreditAttribution: gbyte as a volunteer and commentedComment #5
gbyte CreditAttribution: gbyte as a volunteer and commentedI just finished moving entity overrides to a custom DB table and wrote an updater which will take care of keeping the data. Before publishing, I wanted to hear your feedback regarding custom links: They also feel like they belong to a custom table instead of configuration, especially if there are thousands of them. However I can imagine a scenario where having them in config is much more convenient. What do you think?
Comment #7
gbyte CreditAttribution: gbyte as a volunteer and commentedEntity overrides are now moved to the DB. Please do not forget to run /update.php.