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

temkin created an issue. See original summary.

gbyte’s picture

You 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!

gbyte’s picture

Version: 8.x-1.x-dev » 8.x-2.x-dev

I see you tagged this with version 1.x; I'm changing to 2.x as there will be no more changes to 1.x.

gbyte’s picture

Category: Bug report » Task
gbyte’s picture

I 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?

  • gbyte.co committed 29d74c7 on 8.x-2.x
    Issue #2763855 by temkin: Entity overrides are stored in configuration
    
gbyte’s picture

Status: Active » Fixed

Entity overrides are now moved to the DB. Please do not forget to run /update.php.

Status: Fixed » Closed (fixed)

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