Config entities shipped with simple_sitemap are missing certain fields, which makes them incompatible with recipes in certain situations

I don't see how adding entity keys to configuration that do not exist in the entities themselves solves any problem; rather this seems to be a strange workaround. Neither sitemap nor sitemap type entities have a language code, because a language code does not make sense. Sitemap type entities don't have a status as there is nothing to unpublish. These are custom entity types for a reason - we don't need everything a node entity provides.

I have not used recipes yet but only taking under account your description, this seems to be more of a problem on their side. Please correct me if you feel I'm wrong.

Neither sitemap nor sitemap type entities have a language code, because a language code does not make sense. Sitemap type entities don't have a status as there is nothing to unpublish.

They do, actually -- all config entities (well, anything that extends ConfigEntityBase) do. It's defined in the base class. And in fact, one of the shipped entities explicitly has status: false in 4.x HEAD. There's no way to remove the field unless you change the entity type classes to not extend ConfigEntityBase, but that would create more problems than it would solve.

I have not used recipes yet but only taking under account your description, there seems to be more of a problem with those.

This is an accurate assessment. Recipes are currently too strict about comparing the active config with the config coming from a recipe (which includes any extensions installed by that recipe). That's a problem that needs to be fixed, but it's a complex issue that I've only begun to work on as a recipe system maintainer. Until that's fixed, though, Simple Sitemap cannot be used with recipes that need to be idempotent (which is, frankly, all of them). Adding missing properties that Simple Sitemap itself may not use, but is in fact responsible for because it extends ConfigEntityBase, seems harmless. Especially because, if you install Simple Sitemap on a brand new plain Drupal and run drush cex, you'll see that those entities have langcode and status. They're there no matter what you think about their usefulness, so the default config might as well reflect that reality. ;)

I just ran into this working on the SEO recipe for Drupal CMS/Starshot.

I updated the config files to match the order of what Drupal exports.

I have changed the status back to Needs review as @phenaproxima has provided additional information to the maintainers.

Just as an FYI, this issue is likely to block inclusion of Simple Sitemap in Drupal CMS. :-\

Changing category to task as this is not a bug in my book.

Just as an FYI, this issue is likely to block inclusion of Simple Sitemap in Drupal CMS. :-\

And we don't want that to happen, do we? :)

I updated the config files to match the order of what Drupal exports.

Looking at the MR diff config/install/simple_sitemap.sitemap.default.yml seems off - ID is changed from 'default' to 'index'

Please fix that and also look at the sub modules, especially simple_sitemap_engines. Does making a recipe with that module create a similar issue?

Thanks, I'll make sure to merge that in a timely fashion.

Self-assigning to fix this with test coverage, including all submodules. :)

Off topic, but on the topic of simple_sitemap_engines: To whoever is responsible, maybe it would make sense to include simple_sitemap_engines with its IndexNow functionality into such a Drupal CMS receipe.

Alright - should be all set.

Here's the commit which added failing test coverage (all the modules are accounted for): https://git.drupalcode.org/issue/simple_sitemap-3468413/-/pipelines/263538

And here's the commit which fixed it, to be sure it won't regress in the future: https://git.drupalcode.org/issue/simple_sitemap-3468413/-/pipelines/263542

Anything else needed here?

That was quick. Looks good, thanks!

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