The hook_node_access_records function in the Content Access module that returns all the privileges to apply to a node gets essentially bypassed because the "entityLoad" function in does not load the node's status.

When not updating a node, but replacing, I think the db query should grab the node status as well. I think. Is this a bug or working as intended?

protected function entityLoad(FeedsSource $source, $nid) {
    if ($this->config['update_existing'] == FEEDS_UPDATE_EXISTING) {
      $node = node_load($nid, NULL, TRUE);
    else {
      // We're replacing the existing node. Only save the absolutely necessary.
      $node = db_query("SELECT created, nid, vid, type FROM {node} WHERE nid = :nid", array(':nid' => $nid))->fetchObject();
      $node->uid = $this->config['author'];
    // Populate properties that are set by node_object_prepare().
    if ($this->config['update_existing'] == FEEDS_UPDATE_EXISTING) {
      $node->log = 'Updated by FeedsNodeProcessor';
    else {
      $node->log = 'Replaced by FeedsNodeProcessor';
    return $node;


#1 1300500-1-node-loads-missing-status.patch694 bytesmilesw
Members fund testing for the Drupal project. Drupal Association Learn more


milesw’s picture

Status: Active » Needs review
694 bytes

This just bit me hard. None of the existing nodes were being replaced and I was getting the following exception for every item:

SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'status' cannot be null

My node processor is set to "Replace existing nodes". The first import runs fine. Subsequent imports fail because the status never gets set.

Simply adding 'status' to the db query fixed the issue. It's not clear why other missing values, such as sticky and promote, don't cause similar errors since their database config is similar.

 // OLD
 $node = db_query("SELECT created, nid, vid, type FROM {node} WHERE nid = :nid", array(':nid' => $nid))->fetchObject();
 // NEW
 $node = db_query("SELECT created, nid, vid, type, status FROM {node} WHERE nid = :nid", array(':nid' => $nid))->fetchObject();

Patch attached.

emackn’s picture

Can you provide some other info on how to reproduce the error. Is this a CSV file node import? Any testing data files, etc that you can provide help me get these issues worked out much more quickly.

emackn’s picture

Status: Needs review » Postponed (maintainer needs more info)
milesw’s picture

Steps to reproduce:

  1. Create a new importer with File Fetcher, CSV Parser, Node Processor
  2. On Node Processor settings, change to "Replace existing nodes"
  3. On Mappings form, add the following mappings...
    Title -> Title
    GUID -> GUID
  4. Visit /import page and open the standalone form for the importer.
  5. Choose this sample CSV to import: feeds/tests/feeds/nodes.csv
  6. Run the import, which should create 9 nodes.
  7. Go back to the Mappings form and add another mapping...
    Body -> Body
    (this is only to trigger replacement of the nodes, otherwise Feeds will report "No new content")
  8. Run the import, and you should see the above error repeated 9 times.

Just confirmed this on the dev branch.

milesw’s picture

Status: Postponed (maintainer needs more info) » Needs review
rooby’s picture

Priority: Normal » Major

I have also seen this problem.

The proposed solution makes sense.

I will test it out soon and let you know if it works.

By the way I think this is higher than normal priority because access control is serious.

rooby’s picture

Version: 7.x-2.0-alpha4 » 7.x-2.0-alpha5
rooby’s picture

Status: Needs review » Reviewed & tested by the community

I can confirm the fix.

I am testing on a site using content access and importing from an RSS feed.

I am using the devel node access module in debug mode to view node access grants on a node.
I have littered the node & content access modules with dpm() calls to see what is going on.
I am testing by:

1. Running the import so it imports the nodes.
2. In the database, update the feeds_item table to change the hash value of the node I am viewing.
3. Run the import again, it updates the node with the changed hash, and content access breaks. (If I then manually update the node, content access is properly saved and is working correctly.)
4. Apply the patch in #1.
5. Change the node's hash in the database again.
6. Run the import again, it updates the node, this time content access is saved correctly.

I can also confirm again that the content access module doesn't properly set access control if !$node->status.

Also, just to note that this isn't actually a security hole, because it results in people not being able to see content they should be able to, not the other way around.

twistor’s picture

Version: 7.x-2.0-alpha5 » 7.x-2.x-dev
Priority: Major » Normal
Status: Reviewed & tested by the community » Fixed
rooby’s picture

Great, thanks.

Status: Fixed » Closed (fixed)

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

Anonymous’s picture

Issue summary: View changes

update code tags