I just noticed today that some of my unpublished header image nodes were being displayed in my headerimage block. For some odd reason, the image displays fine (i.e. no "access denied" message), however the image has a pink background behind it.

Considering that there isn't any other built-in method right now of temporarily hiding/disabling a headerimage node from the block, it would be great to exclude unpublished nodes from the image selection. This also seems like a very intuitive method for admins to remove nodes from the image selection -- though I could think of cases where a site admin wouldn't want to actually unpublish a node, but simply hide it from the headerimage selection, and so a better solution could be thought of in the future. But either way, the semantic definition of any "unpublished node" is that it should not be available for public viewing.

The simplest method to exclude unpublished nodes (without doing a bunch of modifications to the existing code) is to alter the image selection query.
Line 180 in the function headerimage_select_node():

Change this line:
$result = db_query("SELECT nid, conditions FROM {headerimage} WHERE block = %d ORDER BY weight, nid ASC", $block);

To this:
$result = db_query("SELECT nid, conditions FROM {headerimage} LEFT JOIN {node} USING(nid) WHERE block = %d AND status = 1 ORDER BY weight, nid ASC", $block);

--

Here's a workaround method until this fix gets committed:
Create a separate header image block called something like "Header Images Disabled" and move the unpublished nodes into that block.

Comments

bartezz’s picture

bartezz commented

Hey Linxor,

I've had this problem with D5 as well (http://drupal.org/node/347397)
The module maintainer stated this issue was fixed in D6 but I guess it's not (http://drupal.org/node/347397#comment-1603310)

Your code isn't working as headerimage table doesn't even have a column status, so it can not check on that.

Your best of by leaving the query to this;

$result = db_query("SELECT nid, conditions FROM {headerimage} WHERE block = %d ORDER BY weight, nid ASC", $block);

And then inserting this code on line #182

if(!node_access("view", node_load($header_image->nid))) {
	return;			  
}

That way header_image doesn't only work properly to not show unpublised nodes but it also respects node_access settings set by any other module!

Cheers

hargobind’s picture

hargobind
he/him
Location Austin, Texas
commented

My code should work fine. Have you even tested it? It's been working for me since June 2009.
The "status" column in my query comes from the {node} table (via the "LEFT JOIN" statement).

Your second point about adding the node_access() check is unrelated to the original issue. In the future, please post that as a separate issue.
However, it's a nice idea in the right direction... and I'd like to recommend an improvement to it. Instead of the return;, it would be better to use continue;. The purpose of the while {} loop on line 181 is to search through all header images returned in the query above and find the best matching header image to display. When you tell the loop to return;, it effectively stops the code from searching any subsequent items in the list.

sense-design’s picture

sense-design
sense
Primary language German
Location Münster
commented
Status: Active » Fixed

Dear fellow Drupal enthusiasts,

this issue is now lasting for a very long time in the issue queue and was unfortunately never solved. As Drupal is a open source project everyone is helping on voluntary basis. So that this is was not solved is nothing personal and means no harm. But perhaps no one had time to deal with this issue, maybe it is too complex or did not pose the problem comprehensible.

But this issue is not the only one. There are thousands of issues on Drupal.org that have never been worked on or could not be processed. This means that we are building a wave that is unmanageable and just a problem for the Drupal project as a whole. Please help us keep the issue queue smaller and more manageable.

Please read again, "Making an issue report" and see if you can improve the issue. Test the problem with the current Core and modules. Maybe the problem doesn't exist anymore, is a duplicate or has even been solved within this issue but never closed.

Help can also be found for it on IRC and in the user groups.

In order this issue no longer remains, I put this issue to "fixed".

If there is new information, please re-open the issue.

Status: Fixed » Closed (fixed)

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