How to build single sitemap.xml that contains content grouped by type

Created on 7 March 2024, 9 months ago
Updated 5 April 2024, 8 months ago

Problem/Motivation

I'm trying to group the contents of the sitemap by type, so that e.g. all of the Blog content goes into a URL named e.g. blogs.xml, which is then listed inside the primary sitemap.xml.

I created a new "sitemap" called "Blogs", set one content type to use it, regenerated the sitemaps and now have a URL of sitemaps/blogs/sitemap.xml, which is not listed inside sitemap.xml.

Proposed resolution

Provide a way, or document a way, of grouping URLs into different sitemap containers.
Provide an option for all containers to be included in the primary sitemap.xml rather than only accessible from their own separate URLs.

Remaining tasks

Work out how to do this.

User interface changes

TBD

API changes

TBD

Data model changes

TBD

πŸ’¬ Support request
Status

Fixed

Version

4.1

Component

Documentation

Created by

πŸ‡ΊπŸ‡ΈUnited States DamienMcKenna NH, USA

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @DamienMcKenna
  • πŸ‡©πŸ‡ͺGermany gbyte Berlin

    What you are asking is possible. Have you read the documentation?

    SITEMAP VARIANTS
    It is possible to have several sitemap instances of different sitemap types with
    specific links accessible under certain URLs. These sitemap variants can be
    configured under admin/config/search/simplesitemap. The module comes with the
    default sitemap 'default' which is accessible under /sitemap.xml by default.
    There is also the 'sitemap index' variant which is disabled by default and which
    can be used to index all other variants. If there are multiple sitemap variants
    it may make sense to enable the sitemap index variant and make it available
    under /sitemap.xml by setting it as the default variant in the module's
    settings.

    Let me know if this helps.

    On a side note, I know I mentioned it a few times to you, but it makes sense to create support requests if unsure if a bug or feature exists. Also when creating bug or feature tickets, it doesn't make sense to tag a stable version of the module. I can't go back and add a feature to a past release - we only work on the dev version.

  • Status changed to Needs review 9 months ago
  • Open in Jenkins β†’ Open on Drupal.org β†’
    Core: 9.5.x + Environment: PHP 8.1 & MySQL 8
    last update 9 months ago
    32 pass
  • πŸ‡ΊπŸ‡ΈUnited States DamienMcKenna NH, USA

    Thank you for the prompt response.

    Part of the problem is terminology - "sitemap" vs "sitemap variant" vs "sitemap type", until you become familiar with what each term means in practical terms it's confusing to read the documentation. It's kind of like the "blocks" system in core - the same word is used for four or five different things, it's confusing until you gain more familiarity with the system.

    After fiddling with some settings I was able to achieve what I wanted, thank you for the pointer.

    I did work on some documentation to explain how to achieve the scenario I was after, along with a minor improvement to the SettingsForm. I think further changes could be done to make it the distinction more clear on what a "sitemap" means in any given scenario, again similar to the word "block" in core.

    I'll open a separate issue about changing the URLs, as I think there might be a bug there.

    And yes, I'll keep in mind that my requests have turned into support requests and will start there in future.

    Again, thank you for your time, I appreciate you.

  • Status changed to Fixed 8 months ago
  • πŸ‡©πŸ‡ͺGermany gbyte Berlin

    I'm closing this support request as fixed. If you don't mind, please create a new task issue with the documentation tag and create an MR instead of a patch. This massively helps reviewing and commiting.

  • πŸ‡©πŸ‡ͺGermany gbyte Berlin
  • Automatically closed - issue fixed for 2 weeks with no activity.

Production build 0.71.5 2024