XSLT stylesheet does not display custom elements

[pbiron]

Description

The XSLT stylesheet only displays the <loc> and <lastmod> elements (and <lastmod> is proposed to be removed in #145).

Should the stylesheet be modified to display additional columns If a plugin adds additional child elements of <url> (e.g., <priority> or something in another namespace)?

While the content rendered by the stylesheet will not affect sitemap consumers, users/site owners/etc might want to see the additional content (if only to verify that custom elements they've added to the sitemaps are actually there).

Describe the solution you'd like

Adding column headers to the table for all child elements of <url> that appear anywhere within the sitemap is not hard (using a convention like uppercase the first letter of any element name that is not <loc>, <lastmod>, <changefreq> or <priority>).

Outputting the element content in the correct columns if, say, a <foo> child exists for 1st, 3rd, 5th <url> elements and a <bar> child exists for the 2nd, 4th, 6th <url> elements is not so easy.

I'm pretty good at XSLT so I can probably figure out how to do it, but want to make sure it would be desirable before I spend any time on it.

This would definitely be low priority, but would be nice to have.

[pbiron]

This is my attempt to address the question asked by @svandragt on slack about the use case for this functionality.

Suppose a site owner updates to WP 5.5 and hears that it now includes native support for sitemaps. So they deactivate whatever sitemaps plugin they used prior to 5.5 and view the posts sitemap in their browser. They are disappointed because they only see the URL column; whereas the sitemaps plugin they previously used additionally had Change Frequency and Priority columns (and of course, the corresponding children of <url> in the sitemap :-).

The site owner does a little bit of research and finds out that, in good WP fashion, plugins can extend the core sitemaps. So, they go looking and find the my-cool-core-sitemaps-extensions plugin, which purports to add <changefreq> and <priority> to the posts sitemap (and the relevant admin UI for setting values for those...either global defaults or specific to individual posts). They activate that plugin and use it's admin UI to setup the values for <changefreq> and <priority>.

When the site owner then views the sitemap in their browser again, they do not see additional columns for Change Frequency and Priority and are likely to think that my-cool-core-sitemaps-extensions doesn't work (i.e., that it's not actually adding the elements to the sitemap), since what they see in their browser is no different than it was before they activated the plugin.

One reaction to the above might be that it is up to the plugin that adds the additional elements to the sitemap to supply it's own XSLT (using the existing core_sitemaps_stylesheet_content filter) to render columns for the additional elements. That could work.

But further suppose the site owner also activates the yet-another-cool-core-sitemaps-extensions plugin which adds even more extension elements (for the sake of argument, suppose these are in an extension namespace) to the sitemap. If that plugin uses core_sitemaps_stylesheet_content to supply it's own XSLT then the XSLT supplied by my-cool-core-sitemaps-extensions is no longer there and the columns it was adding are no longer displayed, which again, is likely to make the site owner think that something is broken.

Therefore, I think the XSLT supplied by core sitemaps needs to be able to render custom columns. The PR in #153 is my (first) attempt to provide that functionality.

Yes, the XSLT in that PR is more complex than what currently exists, no doubt about that:

• some of that extra complexity is the result of XSLT being a declarative programming language...it just has a different way of structuring programs (than languages like PHP/JS)
• some of it is just the verbose XML syntax it uses
• much of it is due to the fact that browsers only implement XSLT 1.0, a 21 year old verison of the language; it could be greatly simplified if it could use features available in XSLT 2.0 (probably not much to be gained by using XSLT 3.0)!!
  • imagine what WP core would be like if it still had to be written in PHP 3 (which was released about the same time XSLT 1.0 was).
• but most of the extra complexity is simply that it provides a lot more functionality.

As I mentioned in slack, I think of it like WP_List_Table allowing plugins to add custom columns. WP_List_Table is more complex than it would be if it didn't allow plugins to add custom columns (the extra complexity there is probably not as great as in the XSLT, but I think the analogy still holds).

Maybe there are other ways of providing that extra functionality that would make the XSLT more maintainable by those not so fluent in XSLT (which I admit is a big consideration). In fact, I've already started think of some alternatives!

But in the end, I think providng this functionality (or something close to it) is really important because not doing so is going to make site owners think that the plugins they activate to extend sitemaps aren't working, it's as simple as that.

I hope this helps.

[pbiron]

I'm now fairly certainly I have an alternate way to structure the XSLT to fully support custom columns that is MUCH easier than that in #153, and only slightly more complex than the existing XSLT.

The more I thought about the analogy with WP_List_Table and `manage_posts_columns', the more I realized that what's in #153 solves a much more general problem than we actually have. So, give me another day or so to polish up the new approach and I'll do another PR.