Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
The following metatag appears on our homepage:
<meta name="googlebot" content="unavailable_after: 11-Sep-2012 14:39:15 CEST" />
This is because we have a block on the homepage which uses node_view() to show full items in a slideshow.
scheduler_node_view() doesn't check if we're on a node detail page and prints out the metatag also on the homepage.
I suggest the following change:
change
if ($view_mode == 'full' && !empty($node->unpublish_on)) {
to
if ($view_mode == 'full' && !empty($node->unpublish_on) && count(arg()) === 2 && arg(0) === 'node' && is_numeric(arg(1))) {
So this metatag is only printed out on detail pages, not when a page uses node_view() somewhere.
Comment | File | Size | Author |
---|---|---|---|
#3 | _scheduler.1781186_3.unavailable_after.patch | 909 bytes | jonathan1055 |
#2 | _scheduler.1781186_2.unavailable_after.patch | 759 bytes | jonathan1055 |
Comments
Comment #1
jonathan1055 CreditAttribution: jonathan1055 commentedHi pcoucke,
Yes I can see this is a problem. Can you give me an example of your code, or show how I can replicate the full node view when it is not the node's page. Then I can test your fix and make a patch.
The function node_is_page($node) might be a more readable way to determine it, but until I can replicate your code I can't test it.
Jonathan
Comment #2
jonathan1055 CreditAttribution: jonathan1055 commentedI found a way to test it, by simply having a page which executed php that called node_view. The function node_is_page() works nicely, and here is a patch for you to try.
Jonathan
Comment #3
jonathan1055 CreditAttribution: jonathan1055 commentedA further check is required to make sure the node is not being edited. Although it does not matter if the temporary edit page has the 'unavailable after' info in the header, it has caused problems adding it during the preview, hence a simple check on arg(2) != 'edit' avoids this.
Also to prevent confusion, I have changed it to use $node->scheduler['unpublish_on'] which is always numeric. $node->unpublish_on is numeric in saved nodes but is a string during editting. Hence better to use the consistent one.
This patch now also solves issue #1036296: Previewing a scheduled node will result in PHP warnings
Jonathan
Comment #4
jonathan1055 CreditAttribution: jonathan1055 commentedHi pcoucke
Have you managed to test the patch? If you need help to apply the patch let me know.
To test the fix, you can paste this into an 'Execute PHP' form, if you are using the Devel module
We would like to get this fix committed to scheduler 7.x-1.1 soon, then also port it to the Drupal 6 version.
Jonathan
Comment #5
pcoucke CreditAttribution: pcoucke commentedI just tested again and the patch from #3 works!
Comment #6
jonathan1055 CreditAttribution: jonathan1055 commentedThanks for confirming this. I'm marking as Reviewed and tested, so that Rick can commit this patch when he next does a batch of updates.
Jonathan
Comment #7
rickmanelius CreditAttribution: rickmanelius commentedCommitted. http://drupalcode.org/project/scheduler.git/commit/3f30383
Thanks pcoucke and jonathan1055!
Comment #8
jonathan1055 CreditAttribution: jonathan1055 commentedI have checked in Drupal 6 and there is no problem, it already works correctly. The code in scheduler_nodeapi() is:
The parameter $a4 is always blank during edit and preview and also blank when the node is displayed in teaser mode. It is only 1 when displaying the node in full page view on its own page. So backport to Drupal 6 is not required.
Comment #10
pcoucke CreditAttribution: pcoucke commentedThe release notes for 7.x-1.1 on https://drupal.org/node/1973360 mention this as fixed, but it seems the patch from https://drupal.org/node/1781186#comment-6824210 was not applied?
Comment #11
jonathan1055 CreditAttribution: jonathan1055 commentedHello Pieter,
Yes you are right, this fix is not in 7.x-1.1. The patch was committed in #7 on 20th April, but 7.x-1.1 was already released by 18th April.
Rick, can you delete that line from https://drupal.org/node/1973360
This issue is fixed and will appear in 7.x-1.2 but for now you will have to apply the patch yourself to 1.1. Sorry for the confusion.
Jonathan