I'm not exactly sure about this, but I'll throw it out there for consideration.

The current workflow of any module that implements hook_xmlsitemap_links() seems to be the following:

"If anyone did anything that even might have been remotely related to what I care about (for example, saved a settings form, or posted a node) then delete all of my links records from the xmlsitemap table and completely regenerate them from scratch."

This might work okay on a site with 100 nodes, but it definitely does not work on a site with 100,000. It's a lot of wasteful processing because really, you only need to worry about which specific settings pages were clicked on (and, moreover, which settings were changed) and which specific node was inserted/updated/deleted, and whether or not your module needs to react to that.

So what if we added a 'reindex' column to the xmlsitemap table that could be toggled on/off by individual modules and indicated "this row of the table is out of date" so that if I'm xmlsitemap_node.module, for example, I can simply check for a) new nodes since the last time I regenerated the sitemap, and b) out-of-date rows that need to be updated, and act accordingly.

Comments

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented

The concept seems interesting. I need to understand how the code would evolve from there.

Could be useful if each modules could make explicit the relation between them? I mean, the first lines of hook_xmlsitemap_links() could be executed from a single module (OK, this is the best I can think of at this hour :-)).

The custom hook should probably be removed, and the modules should write in a single database table. This would also mean that each module would use a standard Drupal hook to populate the table, and in most the cases they would deal with a single entity at time.

Anonymous’s picture

Anonymous (not verified) commented

I've mixed feelings on this subject. One of which is why do we need so many tables? Can't the individual module control the data in xmlsitemap table instead of having a table per module that is then combined into xmlsitemap?

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented

To use a single central table is what I thought to do (the hidden branch already does that, even if the code needs to be updated).
I think the topic here is a little different, and it can be used indifferently from the tables used.

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented

If the modules would be able to access the database table, then they would be able to update the database row, rather than flagging it as requiring to be updated.

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented
Status: Active » Fixed

I added a way for the modules to report the status of a link they added. This should be enough in most the cases. It's something optional that the modules can implement if they need it; if they don't implement it, the code will work as before.

I am changing the status of the report. Feel free to reopen it if you have more questions.

Status: Fixed » Closed (fixed)

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