I have no idea whether this is a problem in Node Convert or XML Sitemap. But when I try to convert a node, it works, but after conversion is done, XML Sitemap tries to do something that causes a PDO Exception.

PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '0-' for key 'PRIMARY': INSERT INTO {xmlsitemap} (subtype, language, access, status, status_override, la...

(and causing multiple undefined indexes after this)

Any idea how/why this error is triggered?

CommentFileSizeAuthor
#3 xmlsitemap-incompatible-2394047-3.patch630 bytesniko-
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

shadysamir’s picture

Same for me. I had to disable xmlsitemap to do node conversion

vincer’s picture

Similar issue here, maybe.

My initial error when trying to convert a single node was:

Notice: Undefined index: safe_value in node_convert_format_field_value_helper() (line 422 of /home4/*user/public_html/site.com/sites/all/modules/node_convert/node_convert.util.inc).

However, the errors when I tried a batch conversion from the content admin page was:

Notice: Undefined index: safe_value in node_convert_format_field_value_helper() (line 422 of /home4/*user/public_html/site.com/sites/all/modules/node_convert/node_convert.util.inc).
Notice: Undefined index: type in xmlsitemap_xmlsitemap_link_alter() (line 254 of /home4/*user/public_html/site.com/sites/all/modules/xmlsitemap/xmlsitemap.xmlsitemap.inc).
Notice: Undefined index: loc in xmlsitemap_xmlsitemap_link_alter() (line 254 of /home4/*user/public_html/site.com/sites/all/modules/xmlsitemap/xmlsitemap.xmlsitemap.inc).
Notice: Undefined index: type in xmlsitemap_link_save() (line 606 of /home4/*user/public_html/site.com/sites/all/modules/xmlsitemap/xmlsitemap.module).
Notice: Undefined index: id in xmlsitemap_link_save() (line 606 of /home4/*user/public_html/site.com/sites/all/modules/xmlsitemap/xmlsitemap.module).
PDOException: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '0-' for key 'PRIMARY': INSERT INTO {xmlsitemap} (subtype, language, access, status, status_override, lastmod, priority, priority_override, changefreq, changecount) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6, :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9); Array ( [:db_insert_placeholder_0] => drupal_module [:db_insert_placeholder_1] => und [:db_insert_placeholder_2] => 1 [:db_insert_placeholder_3] => 1 [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => 0 [:db_insert_placeholder_6] => 1 [:db_insert_placeholder_7] => 0 [:db_insert_placeholder_8] => 86400 [:db_insert_placeholder_9] => 0 ) in drupal_write_record() (line 7239 of /home4/*user/public_html/site.com/includes/common.inc).

The node does convert, but only one at a time. If I select multiple items and run a batch I get the same error but nothing converts.

niko-’s picture

This patch solve node convert part of this bug.
Reason of this bug following:
Node convert try to load xmlsitemap data for changing node type in xmlsitemap table using xmlsitemap_link_load and does not check if link really present in table. After this it try to save updated corrupted link data (becouse xmlsitemap_link_load return FALSE if link not present) back.
But this patch not fully solve problem becouse xmlsitemap_link_save rice following message for existing links.
Caught exception: SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry 'node-27318-0-0-und' for key 'PRIMARY'
although updates the data in xmlsitemap table

apmsooner’s picture

Status: Active » Reviewed & tested by the community

The patch prevents the empty table record from trying to insert which is what generates the errors. The node record still gets created in the xmlsitemap table regardless of node bundle settings but I feel thats an issue with the xml sitemap module as in my testing, any node created programatically gets a record inserted into that table regardless of node bundle settings.

Ultimately the patch fixes a problem i had where the bundle column for a field table attached to the node being converted was not getting updated to the new bundle and i have some custom validation logic that does table lookups on that field that depends on the correct bundle. Anyone who has seen this error, you might want to have a look at your field tables for converted nodes and check if their bundle is correct. I had to manually update several records for my case.