Problem/Motivation

Administrators and editors are unable to alter the 'changefreq' for node types and individual nodes.

Proposed resolution

Implement altering changefreq in xmlsitemap_node sumodule.

Remaining tasks

  • Test the patch in #35.
  • More automated tests.

User interface changes

  • changefreq option at admin/structure/types/manage/[type]
  • changefreq option at node/add/[type]
  • changefreq option at node/[nid]/edit
  • 1 additional column at admin/config/search/xmlsitemap/settings on the 'Content' tab listing the changefreq in human readable format.

API changes

None

Data model changes

None

Original, by mototribe:
I added nodes to the sitemap and they all have a change frequency of "yearly". I didn't see an option to change that.

Comments

earnie’s picture

saratsubolg’s picture

Category: feature » support
Priority: Normal » Major
Status: Closed (duplicate) » Closed (won't fix)

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.

earnie’s picture

Status: Closed (won't fix) » Closed (duplicate)

Have you regenerated the sitemap?
Is the weight of your custom module greater than xmlsitemap such that your custom hook implementation executes after xmlsitemap?

saratsubolg’s picture

Status: Closed (duplicate) » Active

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 ?

facine’s picture

I solved it with:

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

Priority: Major » Normal
Status: Active » Fixed

Status: Fixed » Closed (fixed)

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

BeaPower’s picture

Where do you put this code?

facine’s picture

In a custom module.

AdamGerthel’s picture

Category: support » task
Status: Closed (fixed) » Active

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

<changefreq>yearly</changefreq>

stephesk8s’s picture

Issue summary: View changes

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

saitanay’s picture

Status: Active » Needs review
FileSize
2.7 KB
FAILED: [[SimpleTest]]: [MySQL] 525 pass(es), 0 fail(s), and 14 exception(s). View
saitanay’s picture

FileSize
1.8 KB
FAILED: [[SimpleTest]]: [MySQL] 525 pass(es), 0 fail(s), and 14 exception(s). View

cleaner patch

The last submitted patch, 12: change_frequency_option-1811692-12.patch, failed testing.

Status: Needs review » Needs work

The last submitted patch, 13: change_frequency_option-1811692-13.patch, failed testing.

jenstechs’s picture

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??

fhdrupal’s picture

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.

giupenni’s picture

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

Dave Reid’s picture

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.

diqidoq’s picture

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...

tr-drupal’s picture

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.

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 13: change_frequency_option-1811692-13.patch, failed testing.

SpadXIII’s picture

Version: 7.x-2.0-rc1 » 7.x-2.x-dev
Component: xmlsitemap_node.module » Code
Category: Task » Feature request
Status: Needs work » Needs review
FileSize
10.75 KB
FAILED: [[SimpleTest]]: [MySQL] 507 pass(es), 1 fail(s), and 8 exception(s). View

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.

Status: Needs review » Needs work

The last submitted patch, 24: change_frequency_option-1811692-24.patch, failed testing.

SpadXIII’s picture

FileSize
11.98 KB

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 :)

SpadXIII’s picture

Missed fixing a weird description...

ra.’s picture

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

theterencechan’s picture

update simple test cases on #27

theterencechan’s picture

add check changefreq_override when rebuiding links to avoid ignoring override.

Rob C’s picture

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.

Rob C’s picture

Status: Needs work » Needs review

The last submitted patch, 27: change_frequency_option-1811692-27.patch, failed testing.

theterencechan’s picture

Build links with default frequency if it is not given.

Rob C’s picture

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

Rob C’s picture

Issue summary: View changes
Rob C’s picture

Issue summary: View changes
Rob C’s picture

dmkelner’s picture

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

Rob C’s picture

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

Heidel’s picture

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)

Heidel’s picture

Issue tags: +Needs tests

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?

Heidel’s picture

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?

Rob C’s picture

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.

Heidel’s picture

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

dddave’s picture

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

Heidel’s picture

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

dddave’s picture

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

swa234’s picture

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.

mvzundert’s picture

Version: 7.x-2.x-dev » 7.x-2.3
FileSize
17.09 KB

Hi,

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

Status: Needs review » Needs work

The last submitted patch, 51: change_frequency_option-1811692-51.patch, failed testing.

Rob C’s picture

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).

Dimiter’s picture

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)

Status: Needs review » Needs work

The last submitted patch, 54: change_frequency_option-1811692-54.patch, failed testing.

mparker17’s picture

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.

mparker17’s picture

Looks like that worked \o/

Rob C’s picture

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!

ChristophWeber’s picture

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.

sprite’s picture

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.

frommarcq’s picture

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").

CKIDOW’s picture

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.

gauladell’s picture

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.

Rob C’s picture

@ #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.