change frequency option for nodes

earnie, there is still no solution for 7.x-2.0-rc1.

So that link is useless for 7.x

I tried to use the hook below in my custom demo module, to alter links "changefreq" feature for my custom content type:

function demo_xmlsitemap_link_alter(&$link) {
  if ( $link['subtype'] == 'cust_cont_type' ) {
      $link['changefreq'] = XMLSITEMAP_FREQUENCY_WEEKLY;
  }
}

But the sitemap.xml output remains the same.

Can somebody give my a hand with that ?

The purpose is to be able to override the XML sitemap default definition of the "XMLSITEMAP FREQUENCY" for at least content types.

Coz, according to my personal expirience, by default, it (changefreq) depends on node "created", node "changed", or last comment added.

Which is often not enough, especialy if you have dinamic content for pages, that you want search engines to pay attention to.

Following your advices I:

- altered my custom "demo" module weight field in system table with phpmyadmin. It used to be 0, so I changed It to 5. Xmlsitemap weight field is equal to 1.

... then I

- cleared all caches
- regenerated the sitemap at admin/config/search/xmlsitemap/rebuild

demo module has the same hook:

function demo_xmlsitemap_link_alter(&$link) {
  if ( $link['subtype'] == 'cust_cont_type' ) {
      $link['changefreq'] = XMLSITEMAP_FREQUENCY_WEEKLY;
  }
}

But still no effect. I mean there's lots of links at sitemap.xml with "monthly" frequency, where it's expected to be "weekly" now.

Although, I must say, when I check the "changefreq" field value in xmlsitemap table of those altered by my hook nodes, that have "monthly" frequency at the sitemap.xml output, their values ARE NOW weeklies (604800)

P.S.
Maybe we need to look for a different approach, any suggestion ?

I solved it with:

function demo_xmlsitemap_link_alter(&$link) {
  if ( $link['subtype'] == 'cust_cont_type' ) {
    $link['lastmod'] = 0;
    $link['changefreq'] = XMLSITEMAP_FREQUENCY_MONTHLY;
  }
}

Where do you put this code?

In a custom module.

This isn't fixed? There's no option for node update frequency and the XML sitemap generated uses yearly by default:

<changefreq>yearly</changefreq>

Has the ability to change the frequency been added? I have a lot of pages that say yearly.

cleaner patch.

All of the patches in this issue have failed, and there is still no solution??

I have pages that are set monthly, yearly, and there's no rhyme or reason behind it. Aside from manually updating the database with the proper value, how can this be achieved??

I really think this module needs attention, as there is no proper alternative. If function suggested in #5 elaborate it a little more as to which file we need to insert this function into or what name we should give to the file where we need to insert this function, it will be very helpful.

I agree this module needs attention for this features.
Is very important to be able set the frequency for node.

This would need to have the same logic that we do with status_override and priority_override to indicate that the user has overridden the calculated value. Otherwise this value will not 'stick' for people when the sitemap links are regenerated.

The proposed patch only works once when you save the node form and never do any node_save() via code, which is an impossible situation to have in Drupal 7.

I attach this just for info to others looking around (for logging infos): http://drupal.stackexchange.com/questions/6084/how-can-i-set-frequency-o...

We have an old site with Drupal 6 and some older version of this module and are working on a new site. I was so hoping that in the years that passed since we set up that old site some improvements on the module have been made.

While it's possible to set priority for content types and nodes, it's still not possible to set frequency for content types / nodes, which is sad as I (and surely many other users) consider this functionlaity as an important one.

Can't this functionality get applied in the same way the priority setting is being handled?

Edit:
As far as I understand, currently the value is date based, i.e. is being calculated on the dates created / modified, right? Not sure what the actual problem is, but maybe two options could be introduced:
"Use date absed calculation for the frequency"
"Use manually defined frequency"

Depending on which one is activated, either the current one, or the second / new one (similar to priority) is being used.

I think I have something workable. Tests have to be done still though.

I've added change frequency override fields to the bundle type and other forms, just like the priority and status override fields.
When overriding the change frequency, it doesn't calculate a new value anymore, but just uses the selected value.

The patch in #13 was more a 'hack' to get something workable for nodes. I think this is as mentioned in the previous comments.

Updated the patch with translatable-change frequency options in the forms. It also adds the selected value in the summary.

I'll leave it at 'Needs work' since the tests aren't updated yet :)

Missed fixing a weird description...

#27 works!. Im using version 7.x-2.0-rc2+1-dev

update simple test cases on #27

add check changefreq_override when rebuiding links to avoid ignoring override.

Don't we need something to change the changefreq for nodes when generating them? I'm running into a problem with this bit, keeps setting the wrong changefreq on generating the link. Implemented hook_xmlsitemap_element_alter() for this. And might it be nice to also show the changefreq at admin/config/search/xmlsitemap/settings on the content tab? Patch and interdiff attached.

The wrong changefreq is due to the current's link changefreq value is always used when generating the link without the alter bit. The content type is set to 1 week, but the links always show up as 1 month, even while the table entry lists 604800 and the node is not overriding anything, just using content type defaults. With the alter bit, the defaults are correctly loaded and if the node is overriding, the correct value is used. And we need to fix the tests, cause it is not working correctly with #31. Steps: Setup site with xmlsitemap. Set content type xmlsitemap changfreq to 1 week. Create 2 nodes. 1 overridden, the other in default state. Now generate the sitemap.

Build links with default frequency if it is not given.

With #35 the settings stick. Terence, can you please also look into using interdiffs? Makes reviewing changes a bit easier. Thanks!

Has the patch been applied to any development or release version of the Drupal 7 module? Thanks.

@ #40 dmkelner
If it was, then this issue would have been updated with the commit message. See this example.

I tried to apply patch via git but it doesn't work

git apply -v --directory=sites/all/modules/xmlsitemap change_frequency_option-1811692-35.patch

Checking patch sites/all/modules/xmlsitemap/xmlsitemap.admin.inc...
Checking patch sites/all/modules/xmlsitemap/xmlsitemap.generate.inc...
error: while searching for:
if ($save_custom) {
$query->condition('status_override', 0);
$query->condition('priority_override', 0);
}

return $query->execute();

error: patch failed: sites/all/modules/xmlsitemap/xmlsitemap.generate.inc:545
error: sites/all/modules/xmlsitemap/xmlsitemap.generate.inc: patch does not apply

What's wrong?
(I don't have an opportunity to use command patch -p1 < change_frequency_option-1811692-35.patch on the server)

I didn't have an opportunity to use command patch -p1 < change_frequency_option-1811692-35.patch on the server, so I tried to use command git apply -v --directory=sites/all/modules/xmlsitemap change_frequency_option-1811692-35.patch but in this case I got errors

$ git apply -v --directory=sites/all/modules/xmlsitemap change_frequency_option-1811692-35.patch
Checking patch sites/all/modules/xmlsitemap/xmlsitemap.admin.inc...
Checking patch sites/all/modules/xmlsitemap/xmlsitemap.generate.inc...
error: while searching for:
if ($save_custom) {
$query->condition('status_override', 0);
$query->condition('priority_override', 0);
}

return $query->execute();

error: patch failed: sites/all/modules/xmlsitemap/xmlsitemap.generate.inc:545
error: sites/all/modules/xmlsitemap/xmlsitemap.generate.inc: patch does not apply
Checking patch sites/all/modules/xmlsitemap/xmlsitemap.install...
Checking patch sites/all/modules/xmlsitemap/xmlsitemap.js...
Checking patch sites/all/modules/xmlsitemap/xmlsitemap.module...
Checking patch sites/all/modules/xmlsitemap/xmlsitemap_menu/xmlsitemap_menu.module...
Checking patch sites/all/modules/xmlsitemap/xmlsitemap_node/xmlsitemap_node.module...
Checking patch sites/all/modules/xmlsitemap/xmlsitemap_node/xmlsitemap_node.test...
Checking patch sites/all/modules/xmlsitemap/xmlsitemap_taxonomy/xmlsitemap_taxonomy.module...
Checking patch sites/all/modules/xmlsitemap/xmlsitemap_user/xmlsitemap_user.module...
Checking patch sites/all/modules/xmlsitemap/xmlsitemap_user/xmlsitemap_user.test...

What's wrong? Did I do something wrong?

I didn't have an opportunity to use command patch -p1 < change_frequency_option-1811692-35.patch on the server, so I tried to use command git apply -v --directory=sites/all/modules/xmlsitemap change_frequency_option-1811692-35.patch but in this case I got errors

$ git apply -v --directory=sites/all/modules/xmlsitemap change_frequency_option-1811692-35.patch
Checking patch sites/all/modules/xmlsitemap/xmlsitemap.admin.inc...
Checking patch sites/all/modules/xmlsitemap/xmlsitemap.generate.inc...
error: while searching for:
if ($save_custom) {
$query->condition('status_override', 0);
$query->condition('priority_override', 0);
}

return $query->execute();

error: patch failed: sites/all/modules/xmlsitemap/xmlsitemap.generate.inc:545
error: sites/all/modules/xmlsitemap/xmlsitemap.generate.inc: patch does not apply
Checking patch sites/all/modules/xmlsitemap/xmlsitemap.install...
Checking patch sites/all/modules/xmlsitemap/xmlsitemap.js...
Checking patch sites/all/modules/xmlsitemap/xmlsitemap.module...
Checking patch sites/all/modules/xmlsitemap/xmlsitemap_menu/xmlsitemap_menu.module...
Checking patch sites/all/modules/xmlsitemap/xmlsitemap_node/xmlsitemap_node.module...
Checking patch sites/all/modules/xmlsitemap/xmlsitemap_node/xmlsitemap_node.test...
Checking patch sites/all/modules/xmlsitemap/xmlsitemap_taxonomy/xmlsitemap_taxonomy.module...
Checking patch sites/all/modules/xmlsitemap/xmlsitemap_user/xmlsitemap_user.module...
Checking patch sites/all/modules/xmlsitemap/xmlsitemap_user/xmlsitemap_user.test...

What's wrong? Did I do something wrong?

These patches are always rolled from the module folder. This is all explained in detail at multiple pages.
Also: they are rolled against HEAD for the branch version (see top right).

So this will work:
$ git clone --branch 7.x-2.x https://git.drupal.org/project/xmlsitemap.git
$ cd xmlsitemap/
$ wget https://www.drupal.org/files/issues/change_frequency_option-1811692-35.p...
$ patch -p1 --dry-run < change_frequency_option-1811692-35.patch
checking file xmlsitemap.admin.inc
checking file xmlsitemap.generate.inc
checking file xmlsitemap.install
checking file xmlsitemap.js
checking file xmlsitemap.module
checking file xmlsitemap_menu/xmlsitemap_menu.module
checking file xmlsitemap_node/xmlsitemap_node.module
checking file xmlsitemap_node/xmlsitemap_node.test
checking file xmlsitemap_taxonomy/xmlsitemap_taxonomy.module
checking file xmlsitemap_user/xmlsitemap_user.module
checking file xmlsitemap_user/xmlsitemap_user.test

For any additional questions, ask these in the forum, on IRC, contact me personally, but please do not pollute issues with these questions. If it would fail, the test status would also show this, and it shows success.

Well, I really tried to ask the question in the forum but it doesn't show my post.
Patch was applied successfully, but in this case after I got an error with sitemap generation, when I try rebuild sitemap
http://i.imgur.com/o3I2l87.png
http://i.imgur.com/B9DkoqV.png

@Heidel: Sorry, but Mollom ate your posts. I've published them and confirmed your account.

@dddave but I still can't find my posts in the forum, why?

@Heidel: Should be fine now. Deleted the dupe though.

how to change the frequency from yearly to daily for the content without applying the patch #12 in xmlsitemap is it possible trough admin to change the frequency.

Hi,

I've patched this for 7.x-2.3 so it won' t work on dev versions since the other patches keep failing.

Reuploading patch from #35 to prevent people from reviewing the wrong patch.
As soon as the current patch is tested a bit more we can mark it as RTBC and get the maintainers to commit it. Thanks!

If you want patches against development versions for a project version/tag (1.2 for example) to work, download the module with Drush make via a makefile, then the patch is applied and a useful version is added to the module's info file based on the git revision/tag provided in the makefile. (or roll a custom patch you can maintain locally, also possible with makefiles).

A re-roll of #53 but with an incremented Hook_update_N number to avoid collision with a patch applied earlier. (Issue 1670086 - Patch #50)

It appears that the IDEA editor (likely PHPStorm) did not generate the patch in the way that git normally generates it, so Testbot couldn't figure out how to apply it.

I'm not entirely sure how to get PHPStorm to generate patches in the way that Testbot expects; however, if you are interested, I blogged about my own best practices for generating patches and interdiffs (which uses the command-line) last year.

This is a straight re-roll, so no interdiff is needed.

Hopefully, Testbot will be able to apply this one. Setting back to "Needs review" to trigger Testbot to re-test it.

Looks like that worked \o/

Reviewing comments, some comments/questions:

#10

This isn't fixed? There's no option for node update frequency and the XML sitemap generated uses yearly by default:

#11

Has the ability to change the frequency been added? I have a lot of pages that say yearly.

#16

I have pages that are set monthly, yearly, and there's no rhyme or reason behind it. Aside from manually updating the database with the proper value, how can this be achieved??

This is covered by the patch.

#19 @Dave Reid

This would need to have the same logic that we do with status_override and priority_override to indicate that the user has overridden the calculated value. Otherwise this value will not 'stick' for people when the sitemap links are regenerated.

I believe it's very close, please confirm.

The proposed patch only works once when you save the node form and never do any node_save() via code, which is an impossible situation to have in Drupal 7.

Is this still valid?

#56 seems to apply ok, tests are supplemented with the new option, seems to work ok, so i wonder if we can get some more reviews and update the status to RTBC or Needs work? (with motivation) so we can wrap this up :) Thanks!

I had to apply #56 manually, git failed because the code base has moved on since. That said, the patched module works cleanly in my hands and will go into production shortly.

Can't comment on Rob C's other unresolved items above.

Thank you for the patch in #56.
I was able to apply the patch easily.
After basic testing, the patch appears to running properly.
These features really need to be in the official version of the module.

patch #56 worked for me.
Just a little problem : in the generated Sitemap, the value "Change Frequency" for the nodes seems to be translated (in my case "weekly" becomes "hebdomadaire").

Patch #56 worked for me as well, but it would be nice if everyone could export the default 'changefreq' values by features / strongarm like priority and in-/exclusion.

patch #56 worked for me.

But i have the same problem of #61, in my case the string is translated in Spanish wich ends up in a lot of errors on google console.
Any clue of how to solve this?

Thank you.

@ #61 frommarcq & #63 gauladell

Please provide more information about your environment. I'm running multiple sites in Dutch/German and i do not experience any issues like you describe. Also validate (trace) where this is used in code, cause from a quick review of the patch in #56 + your comments we can't figure out why without some more details regarding your setup.

This patch is in use on multiple platforms for some time now, and i believe it's about time we get this (long overdue) feature committed. Sure it's possible we missed something while this patch evolved, so please provide additional info or get some help debugging this on your environment, would really like to wrap this up.

Just to let y'all know, back in 2015, Google's John Mueller was asked in a video hangout if Priority and Change Frequency play much of a role in sitemaps these days. His response was "Priority and change frequency doesn’t really play that much of a role with Sitemaps anymore."

YouTube @29:35

I was asked to make the patch on #56 work for taxonomy terms, which it was not doing. #56 allows the values to be set and saved per vocabulary, but does not add the custom values to the generated xmlsitemap.
I have rerolled that patch with an additional change related to taxonomy terms. The code isn't original. I merely copied and modified the hook_xmlsitemap_element_alter() that was added to xmlsitemap_node into xmlsitemap_taxonomy.
I assume that if this same result is wanted for user or menu entities, copying and modifying this same hook into those modules would have the same results, but I didn't test that.

When are this module's maintainers going to get these essential and important feature modifications into the dev and/or release builds for this module?

Bump, can we officially get this feature please :)

Don't you just *love* when it takes 5 years to release a small feature :)

I've tested last patch (if you want to do it too, don't forget to run: drush updb).

I'm not going to go through the code in details. I've tested, it works. Just commit it, and if / when people will complain in certain cases, let them place those cases here (or in other issues) and let's fix those.

Let's move forward. 5 years.

Heads up: the 7.x-2.x branch changed last month. The patch won't apply at all anymore. (coding standards and more have been fixed)

So we need a reroll + see 'Remaining tasks' in the issue's description.

Back to 'Needs work'.

Can we have some feedback from the maintainers if this issue will ever be resolved / is taking the right approach? (Dave Reid/RenatoG/amateescu i know your all busy, just like all of us, but would love to have at least a confirmation on the remaining tasks).

Reroll of the patch for the current dev branch

Hm, this patch is only for version 2.5 because the dev patch fails on 2.5.

Use the xmlsitemap_get_changefreq_values() instead of xmlsitemap_get_changefreq_options() in xmlsitemap_taxonomy_xmlsitemap_element_alter and xmlsitemap_node_xmlsitemap_element_alter because the
xmlsitemap_get_changefreq_options() translates the changefreq labels in the sitemap.xml

#54 Upping the hook_update_N implementation from 7204 to 7205 will cause installations that update to a later patch to crash during database updates:

Cannot add xmlsitemap.changefreq_override: field already exists.

I have added a sanity check to check if the database column already exists.

The patch in #76 didn't apply with git against the latest dev branch:

git apply xmlsitemap-change_frequency_option-1811692-76.patch
error: patch failed: xmlsitemap.admin.inc:551
error: xmlsitemap.admin.inc: patch does not apply

With alternative -p1 method it gave number of hunks:

patch -p1 < xmlsitemap-change_frequency_option-1811692-76.patch
patching file xmlsitemap.admin.inc
Hunk #1 FAILED at 551.
Hunk #2 succeeded at 574 (offset 2 lines).
Hunk #3 succeeded at 586 (offset 2 lines).
Hunk #4 succeeded at 594 (offset 2 lines).
Hunk #5 succeeded at 674 (offset 2 lines).
Hunk #6 succeeded at 758 (offset 2 lines).
Hunk #7 succeeded at 768 (offset 2 lines).
Hunk #8 succeeded at 851 (offset 2 lines).
Hunk #9 succeeded at 959 (offset 2 lines).
1 out of 9 hunks FAILED -- saving rejects to file xmlsitemap.admin.inc.rej
patching file xmlsitemap.generate.inc
Hunk #3 succeeded at 583 (offset 2 lines).
patching file xmlsitemap.install
patching file xmlsitemap.js
patching file xmlsitemap.module
Hunk #2 succeeded at 650 (offset 13 lines).
Hunk #3 succeeded at 1149 (offset 13 lines).
Hunk #4 succeeded at 1213 (offset 13 lines).
Hunk #5 succeeded at 1303 (offset 13 lines).
Hunk #6 succeeded at 1489 (offset 13 lines).
Hunk #7 succeeded at 1539 (offset 13 lines).
patching file xmlsitemap_menu/xmlsitemap_menu.module
patching file xmlsitemap_node/xmlsitemap_node.module
patching file xmlsitemap_node/xmlsitemap_node.test
patching file xmlsitemap_taxonomy/xmlsitemap_taxonomy.module
patching file xmlsitemap_user/xmlsitemap_user.module
patching file xmlsitemap_user/xmlsitemap_user.test

And even-though there is a new option for changing the `Default change frequency` on content type edit page, it causes the error:

PDOException: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'changefreq_override' in 'where clause': UPDATE {xmlsitemap} SET changefreq=:db_update_placeholder_0 WHERE (type = :db_condition_placeholder_0) AND (subtype = :db_condition_placeholder_1) AND (changefreq_override = :db_condition_placeholder_2) ; Array ( [:db_update_placeholder_0] => 604800 [:db_condition_placeholder_0] => node [:db_condition_placeholder_1] => blog [:db_condition_placeholder_2] => 0 ) in xmlsitemap_link_update_multiple() (line 728 of /home/username/public_html/sites/all/modules/contrib/xmlsitemap/xmlsitemap.module).

So the patch is far from ready.

Anyway, I wonder what exactly makes this discussion different from one on #854632: Add ability to override changefreq that is older and why not concentrate all the energy on one thread dedicated to resolving this issue?

I got the same error when apply the patch in #76 based on the latest dev branch (86000db):

git apply xmlsitemap-change_frequency_option-1811692-76.patch
error: patch failed: xmlsitemap.admin.inc:551
error: xmlsitemap.admin.inc: patch does not apply

But I can apply the patch in #76 based on the dev (dc7328b) successfully.

Based on the latest dev branch, re-roll of #76 patch.

Using drush make, I applied #76 against 7.x-2.6 successfully.

Testing: I changed Custom Links, changed the Settings tab for Frontpage, edited a Menu Link, Content Type, and Taxonomy term. I also used the Rebuild Links tab. I used Drush to run xmlsitemap-regenerate and xmlsitemap-index. No errors.

I'll let somebody else test #79 on 2.x-dev before switching to RTBC.

I got the same error as #77. I tried versions 7.x-2.x-dev and 7.x-2.6 width patch #79 and #76

At risk of confusing things, I needed this patch to apply to 7.x-2.6 official, not 7.x-2.x-dev, so here's a re-roll of #79 relative to the 7.x-2.6 tag...

Mostly this patch should be ignored, unless you're applying via composer etc.

Thanks/sorry,
-Derek

Updating to the latest 7.x-2.x-dev.

I couldn't easily generate an interdiff because the old patch no longer applied. There were only two main differences:

1) The patch in #79 contained a change from xmlsitemap_get_changefreq_options() to xmlsitemap_get_changefreq_values(), however a few other places in the module were referencing the _options() function, so I renamed the new function to xmlsitemap_get_changefreq_form_options().

2) The previous comment had some @file comments which differ from the current branch, and they don't need to be a part of this patch.

Fix to #84 to rename the new options function to xmlsitemap_get_changefreq_form_options().