Change Frequency not updated when nodes have comments

Oh hah, yah I think I accidentally removed this as a part of getting the individual priorities and inclusion working. Setting as an alpha blocker.

No problem. I had forgotten that I had commented this out in order to get the higher priority stuff working first. Now I can come back to this and get it working right with tests. :)

Hey folks, using this on www.mothersclick.com and it's working great with all of our data.

Our SEO firm, iProspect sent in this recommendation...

It’s also highly recommended for a site like MothersClick, where content can change throughout the day every day, to revise the change frequency to “daily.” It looks like some URLs have “never” or are blank in that field, so just wanted to notify you of that in the case these can be updated. It seems that posts will be updated as comments are added for the existing URLs with data in that field, however, so that’s great.

Once the bug with comments changing the node frequency are addressed, that will address the last point.

The first one though is intriguing -- what about sites that want to force a frequency change for certain types of posts (whether by node type or category type). Seems like a simple setting addition but could add a lot of flexibility depending on the SEO campaign for a site.

Otherwise the new 6.x-2.x-dev is working great!

Related, the "frequency" option should also be stored with xmlsitemap_custom too. Be great to not only save the priority, but the frequency with each link that is added through this interface.

@m3avrck: Custom links now have a configurable changefreq value.

Working on this as it's the last major alpha blocker. I want to release damnit! :)

Please try the latest code. It seems to be working just fine. Not sure why I didn't really test it until now. :/

I tested with adding node revisions and adding comments.

I tested it just now. The sitemap shows the date of the node save rather than the date of the most recent comment. I have also noticed that my admin/build/modules page does not display any of the comment settings mentioned in the documentation about adding nodes to your sitemap. I updated to the most recent commit just now and tested again with no fix. I noticed that the "XML sitemap node" modules has a weight of 0 while "XML Sitemap" has a weight of 1. Is that my problem? I tried making them 2, but that didn't update it, so I changed it back. I also tried "Enable developer mode to expose additional settings." but didn't notice any changes.

Also, when I go to admin/settings/xmlsitemap/edit/1 it says "There are currently no XML sitemap contexts available." Is that a problem? It also says that when I try to add a new sitemap.

1. Did you regenerate your sitemap after saving the new comment? Is the comment published? Did you also check the data in {xmlsitemap} to see if the 'lastmod' value changed?
2. Documentation is for the 1.x version and needs to be updated.
3. Don't change the weights. They're set up exactly as they should be.

@#10:
That's not a problem. It just simply means there aren't any contexts (like language, domains, etc) available. You can still press 'Save'. You shouldn't be able to have two sitemaps if you don't have any contexts available since they'd be exactly the same.

I did everything that you mentioned except check {sitemap}. I was using an outdated version of 2.x-dev from about march, so I updated just now and suddenly it does appear to be updating, only now it's setting the date to today's date for any nodes that have comments. Is that by design?

Hmmm false alarm. It hasn't updated at all, I was looking at the wrong post. I will check {sitemap}.

OK, I checked the xmlsitemap table and found that the lastmod node(s) in question has not been updated. I must be doing something wrong, because this is working for everyone else, right?

I guess I should update the status, since I have provided the info you requested. The problem still persists. Any more ideas how I can troubleshoot the issue?

Are the comments published?

Yes, definitely. There are hundreds of comment on several nodes that are published, yet aren't updating their respective nodes lastmod in the xmlsitemap table.

What does the following query return for you (making sure to replace [node-id] with the problematic node ID)?
SELECT c.timestamp FROM comments c WHERE c.nid = [node-id] AND c.status = 0 UNION ALL SELECT nr.timestamp FROM node_revisions nr WHERE nr.nid = [node-id]

Also try the query excluding the UNION ALL SELECT and beyond.

It returns the most recent comment's timestamp and the node's timestamp:

1273645370
1272912314

Without the union it returns just the most recent comment's timestamp:

1273645370

Any more ideas? I'm at my wit's end.

I'm surprised this issue isn't bothering anyone else. Is no one else noticing this same behavior?

Just for my own information, is this the intended behavior by design?

Gosh, I hate to keep beating a dead horse, but I'm facing using another solution to update my sitemap. Is there anyone that can confirm whether or not this is a bug or a feature?

Not sure about the alpha-blocker part but I just added a comment to a node and the frequency is still showing "yearly." And this is on 6.x-2.0-beta1.

I didn't feel comfortable deleting the "alpha blocker" tag. I'm on 6.x-2.x-dev and I am experiencing the same issue. Thanks for confirming!

Changing to "release blocker"

I imagine it's something in this line, but I haven't really tested it. It's not really my area of expertise.

Contents of /contributions/modules/xmlsitemap/xmlsitemap_node/xmlsitemap_node.module
Fri May 28 18:14:20 2010 UTC (7 weeks, 4 days ago) by davereid
Branch: DRUPAL-6--2

(line 197)

$query = db_query("SELECT c.timestamp FROM {comments} c WHERE c.nid = %d AND c.status = %d UNION ALL SELECT nr.timestamp FROM {node_revisions} nr WHERE nr.nid = %d", $node->nid, COMMENT_PUBLISHED, $node->nid);

I'm still around, just have been very busy. I've tried to help figure out why this wouldn't be working but I haven't been able to come up with an answer, sorry.

subscribe

@webavant: You you manually run that query with a node ID that you're having problems with? What are all the timestamps it returns?

I'll reiterate that changefreq is *just a suggestion* to search engines. It's not taken literally and will *not hurt* your site if they are incorrect.

Correct. Rather than run the query again, I'll go ahead and link to the previous post where I reported the query results. I tried the query on several nodes and the timestamps were invariable always the original post date, and not the most recent comment date, or any comment date for that matter. The sitemap consistently showed the original post date for lastmod. You're not having the same problem? I haven't updated the module in a couple of months, but I'm still using 2.x-dev.

EDIT: Oh gosh, I think I may have been looking at things wrong with that query. I'm going to run the query again and report back.

Okay, I just updated to current and ran the query on a node with several comments, which returned:

1281808141
1281858626
1281877525
1281878213
1281568814

Should it be returning only the first value, the timestamp of the most recent comment? My sitemap is still displaying the node's original post date, and not the comment's timestamp as the lastmod.

EDIT: I'll reiterate that I'm concerned about the "lastmod" than the "changefreq", although updating both would be nice. Do I need to create a new issue?

@undoIT: Whether they do or not, this module can submit as soon as it sees a change, so the frequency is somewhat immaterial because the search engines see the update date and come back to index the updated pages.

AHHH I can finally see what's going on here. It looks like changefreq is getting calculated correctly if it's returning those resutls. However, the 'lastmod' value is always using the $node->changed, which is not updated when a comment is added. We should instead be using the MAX() value from that list.

That sounds right. I guess I should have posted a new issue originally. I'll step out of the discussion and allow the 'changefreq' argument to continue, as don't have much of an opinion about it.

@undoIT: I've filed a feature request for the taxonomy sub-module here #893282: Support lastmod and changefreq values for taxonomy terms to keep it separate from this discussion.

I have committed a fix to CVS to address the lastmod value not updating when comments are added to nodes.
http://drupal.org/cvs?commit=412014
http://drupal.org/cvs?commit=412016

I want to double check back on the original issue: "One node is listed as yearly, even though I just saved it. Change frequency should be reset to always after saving node, even if there are comments." This statement is not true. The changefreq is an average of all your node revision timestamps and published comment timestamps. If you saved a node over three years ago and it's had two new comments, the average time between those changes is still yearly. Note that the proper 'lastmod' value will be shown now though, which is a helpful indicator to search engines when the page actually changed and if it needs to be reindexed or not.

So it's my belief that this is now addressed, everything else has separate issues filed, so I'm marking as fixed.

Cool! This fixes the issue in my mind. The lastmod is now displaying as expected and the changefreq seems to update accordingly, displaying a more frequent interval for nodes with recent comments. Thanks!