Use page date() not modified() for sitemap's lastmod

[hughbris]

I think the $page->date() method makes more sense and falls back to modified when not set.

[hughbris]

I'm finding I need this when migrating a site from another system. I want to preserve the dates the content was last updated on the legacy site.

[Karmalakas]

I believe this PR would break every sitemap. That's why sitemap is based on modification date and not creation. I don't really get the problem. Why would you not want to tell indexers that your content was modified recently?

[hughbris]

I believe this PR would break every sitemap. That's why sitemap is based on modification date and not creation.

Creation? I don't think that's the purpose of the date in page frontmatter, rather it's to manually override the file modification date. But having checked the description provided in the docs, I see where you got the idea.

If you've never set date, it won't break anything because it falls back to the file's datestamp.

If it turns out I've been using this frontmatter property wrongly all this time, could this be overridden in the plugin with something similar to:

sitemap:
    lastmod: '2014-03-03'

.. just like you can with changefreq and priority?

I don't really get the problem. Why would you not want to tell indexers that your content was modified recently?

As mentioned above, I'm migrating a site and want to preserve content updated dates for both the page footer and the sitemap. There are probably other use cases.

[Karmalakas]

Now I'm a bit confused. I'll ask differently. How would this change affect sitemaps already in prod for other Grav users with different frontmatters and configs?

[hughbris]

Well I think it wouldn't affect them unless the site owner:

• has set date in their page frontmatter AND
• interprets date to be the creation date of the page (which could be right?? could one of the core maintainers comment on this please? the semantics are ambiguous to me)

You said it would "break" sitemaps, so your question should really be answered by you. Could you give an example of "different frontmatters and configs" and show how the sitemap breaks?

Really I'm looking for a way to override the crude file modification date so that I can reflect true content changes, of interest to indexers. If that's not what date is meant to indicate, then I'd like to have another way. This might have been best raised as an issue not a PR, but I was not expecting any controversy over this implementation :)

[Karmalakas]

Ah, I completely misunderstood. Now I get what you're after, but I still don't see how ->date() solves the issue. It just falls back to ->modified, doesn't it? Or if you can override date in frontmatter, isn't there a way to override a modified?

IDK.. For me it makes much more sense to use modified for lastmod, but that's for team to decide

[hughbris]

Fair enough, I think I'm going to park this and open an issue asking how I can override lastmod in the sitemap.

The problem with this PR that you've helped me see, is that I'm not really sure what a page's date frontmatter is supposed to mean. (modified? created?)