Nodes set to priority 0.0 on node update [#123952]

A bug in the SQL UPDATE seems to cause any edited (nodeapi update) nodes to get priority_override set to 0.0 if the override field is blank. It is then impossible to un-override the node without editing the xmlsitemap MySQL table directly (unsure if the problem also exists with Postgre); the only way to give the node a priority other than 0.0 is to override with another number. Fix above changes the code to submit the priority_override value to the SQL string as a string, not as a float, as is done in the nodeapi insert (which works fine).

Comment	File	Size	Author
	xmlsitemap.module-HEAD-r0.patch	1.59 KB	gnassar

Comments

Comment #1

hquadrat commented 7 March 2007 at 14:18

I have the above mentioned problem too... all content nodes have now an assigned priority of 0.0 (also to bee seen in the override-field when editing a node).
Now... applying this patch - does it solve this? Or would I still have to edit every single node to assign a new priority? I really hope not...

Comment #2

hquadrat commented 7 March 2007 at 18:04

ok, I now applied the patch manually by editing the gsitemap.module (yes, I'm using the 5.x-1.0 module-version and this happened there too as I had to edit every single node due some other module's bug).
Now everything is normal with the priorities, if I remove the 0.0 priority override in a node's edit-form. But how can I now remove those buggy 0.0 overrides from all previously edited nodes in my site?

Comment #3

gnassar commented 7 March 2007 at 21:34

That's a good question, with a no-fun answer unless you like SQL. You're looking for something along the lines of:
UPDATE {xmlsitemap} SET priority_override=NULL WHERE priority_override=0.0;

I don't know of any better way; the above is what I did. That clears out all 0.0 priorities, and lets xmlsitemap calculate them again.

Comment #4

hquadrat commented 18 March 2007 at 11:53

thank you very much, gnassar. I used :

UPDATE gsitemap SET priority_override=NULL WHERE priority_override=0.0;

which helped to reset the field's 0.0 values when applied your patch before of course.

Now, I am still a little confused with the versions and the naming of this module respectively... (gsitemap/xmlsitemap??) There is now a new version of "gsitemap.module" (5.x-1.1)... I am currently running the 1.0 version. Is this bug resolved there or would I have to patch again? At least to me it seems that the patch did not go into the new version as the code there seems unchanged at the places that are critical to this issue...

Comment #5

bwynants commented 18 March 2007 at 20:00

please see http://drupal.org/node/128636 for a patch

Comment #6

SamAMac commented 22 March 2007 at 19:29

Version:	master	» 5.x-1.x-dev
Status:	Needs review	» Fixed

Actually, the one of the commits made to fix http://drupal.org/node/128636 is what caused this, namely 61135.

This does not actually appear to have been changed in HEAD, but is present in 5.x-dev. I have corrected it in 61669.

Comment #7

bwynants commented 22 March 2007 at 21:03

there is still a small problem, don't know when it happens but I can see it in the code:
in gsitemap_nodeapi function case update:

        if (!isset($oldnode->last_changed)) {
          $node->last_changed = 'NULL';
        }
        if (user_access('override node priority')) {
          db_query("UPDATE {gsitemap} SET last_changed = %s, previously_changed = %d, priority_override = %s WHERE nid = %d", $node->changed, $oldnode->last_changed, $node->priority_override, $node->nid);
        }
        else {
          db_query("UPDATE {gsitemap} SET last_changed = %s, previously_changed = %d WHERE nid = %d", $node->changed, $oldnode->last_changed, $node->nid);
        }

oldnode->last_changed is checked, if not set node->last_changed is updated.
oldnode->last_changed however the query uses....

bert