2

We have several nodes that serve as open job postings which need to "open" and "close" on specific dates. In order to accomplish this, we publish and unpublish them accordingly.

We have a query (based on publish unpublished node programmatically) that successfully updates both the node table and the node_revision table:

$result = db_query('update node n
JOIN field_data_field_jobs_date d ON d.entity_id = n.nid and d.revision_id = n.vid
JOIN node_revision r ON n.nid = r.nid and n.vid = r.vid
# Update the node_revision table
SET r.status = IF(
    ( 
    CURDATE() >= d.field_jobs_date_value 
    AND 
    CURDATE() <= d.field_jobs_date_value2
    ),1,0
),
# Update the node table
n.status = IF(
    ( 
    CURDATE() >= d.field_jobs_date_value 
    AND 
    CURDATE() <= d.field_jobs_date_value2
    ),1,0
)
# Only update our custom content type
WHERE n.type = \'job_posting\'');

This successfully updates the node status and node revision status in the database.

However, once a node has been published through this method, anonymous users still cannot see it (and are presented access denied if given a direct link to the node).

We have to manually edit each node and hit the save button for the published status to "take." This leads me to believe that we are omitting some sort of call to node access or something similar that updates the permissions on the node appropriately.

Any ideas besides the status field that may be preventing anonymous users from seeing programatically published nodes?

  • As a side note, using db_query() for anything other that read-only queries (SELECT, SHOW, DESCRIBE, etc) is frowned upon. Use db_update(). – mpdonadio Aug 1 '14 at 19:35
  • Thanks for the clarification, MPD - we would use db_update but it doesn't really support this complex of a query with IF statements and what not. – oranges13 Aug 5 '14 at 13:46
3

The method that you are following to update your nodes/revisions is generally frowned upon by the Drupal community. However, since you seem to know what you are doing and the changes that you perform to the database do not break anything, I can give you a suggestion on how to fix it.

After updating the database table, you can use the node_load and node_save functions to programmatically retrieve and save the node using the proper Drupal way. This, is basically the same thing that you are doing by opening and saving the node.

As to why this is happening, you might check the node_save function's code. Specifically, the fact that you do not update the node access table with something like:

    node_access_acquire_grants($node);

seems like something that could be causing the issue that you are facing.

  • Thank you for your suggestion, you are probably correct in your assumptions that it was to do with the access grants. We worked around this by instead of querying for date and using it to publish / unpublish nodes, we simply modified the view we were using to display them filtered by their open and close date. Why we didn't do that to begin with is beyond me. – oranges13 Aug 15 '14 at 19:10
4

Most probably caching. Directly changing something in the database is, though the fastest, not really the safest / most reliable way of doing things in Drupal.

I'd suggest to use enity_query (or in this case even direct database access) to retrieve node ids of nodes you want to update and then use 'correct' drupal way of doing things -> load all the nodes, individually change their publish status and save them.

Something along these lines...

$nodes = node_load_multiple($nids);
foreach ($nodes as $node) {
  // set status property to 1
  $node->status = 1;
  // re-save the node
  node_save($node);
}

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.