I have quickly seen view reference and context module. Though they can display a view or block to a specific content type, I'm not sure if they can do it within a specific node.

As an example: I want to display a block only for an article with node id 3.

Can that be done?

5 Answers 5


I would steer clear of using PHP for block visibility. If you type something wrong you can break any number of things.

Just go to your block settings, and take a look at the vertical tabs at the bottom of the page. The first option is Pages. Just change the radio button to "Only the listed pages" and enter node/3 in the box.


If you use the Views Reference module mentioned in your question, then you can quite easily embed a Views block as one of your fields just as any other field. The field itself can't be exclusive to a node ID, only an entity type. However, you could just leave it blank for the other entities of the same type and use Field Permissions if you are worried about other people using the field incorrectly/at all.

One unrelated helpful hint with Views Reference - I generally tag my "reference-able" views with the same tag (i.e. Embeddable, Referenceable e.t.c.). then you can easily select which Views to make available to the Views Reference field.

You MIGHT be able to embed blocks with Entity Reference combined with BEAN or Boxes, but I'm not 100% sure. Failing this you are probably looking at breaking up the entire $content variable in the template and embedding it yourself (which would mean much more maintenance if fields get added or removed), using Views and turning the whole content types into blocks that can be positioned (MUCH effort).

  • no my friend, lets suppose I want put a block between my node body . your method not ok with it.
    – Yuseferi
    Sep 6, 2012 at 8:23
  • I agree with Zhilevan because thats exactly is my purpose, put the block as part of the node content.
    – ARGO
    Sep 6, 2012 at 8:25
  • 2
    Aaah, I see. The question could probably have been clearer. Either way, you're going to need more help, as the module_invoke() part will still render the block outside of your $content variable unless you break up the entire variable and render everything separately in the template.
    – Chapabu
    Sep 6, 2012 at 8:32
  • Ah, I also read the other answer wrong at first - I thought you meant PHP for block vsibility on the settings page. I'll have my coffee now and come back later ;-)
    – Chapabu
    Sep 6, 2012 at 8:33
  • @Chapabu be appetite :)
    – Yuseferi
    Sep 6, 2012 at 12:14

To render something inside a node body, you need an input filter to be able to write something like [block:foo:bar] and have the bar block from the foo module rendered. Unfortunately, a dedicated module does seems to exists on Drupal.org. Actually, one exists but is for Drupal 5 and has only a development release.

Using the PHP filter as suggested in others answers is an easy option. But this is a hacky one and not recommended. It opens to gate to a lot of abuses and potential headache debugging code stored in the database.

  • hacky? if php filter was hacky not cosider it as drupal core modules :(. if roles with high permission admit use php filter there is no worring. at least it's implementable
    – Yuseferi
    Sep 6, 2012 at 13:20
  • 3
    If you search for it, you will find that a lot of stuffs in core stuffs are considered hacky by core maintainers themselves. Just assist conversations at DrupalCons or follow issues in the issue queues. PHP filter is one of them. Yes it works, yes it allow site builders to quickly meets many needs. But for a developer this is a quick and (extremely) dirty solution that create hard to maintain website. It is also a security risk. Sep 6, 2012 at 16:01

You could try the Insert Block module. Still in dev, but may be useful.


You should be able to get this to work using the Rules block visibility module. Here is a quote from its project page:

The Rules block visibility module allows Rules components to be used to control block visibility. This provides Drupal administrators and developers extreme flexibility in controlling when blocks should be displayed on their websites, in addition to the default visibility options provided by Drupal.

The general idea is that if you can do it with Rules, you can use it to control block visibility, so the possibilities are limitless:

  • Need to show a block only for users registered more than a month ago?

  • Perhaps you have a block that must be shown only between 8am-5pm on weekdays?

  • What about displaying or hiding a block based on current weather conditions?

All of this can be done by using Rules block visibility.

With that, and as per the "if you can do it with Rules, you can use it to control block visibility" above, you've reduced your question to making Rules intercept the URL corresponding to your article, which appears to be a node, with node id = 3.

Adding a Rules Condition like "if it is /node/3" is really like a getting started with Rules Conditions. If needed, just copy (import) the Rules example included in my answer to "How to make the permissions of a module more granular?" and finetune it a bit to fit your needs.



Enable php filter module , add new content in body section do something like this picture ScreenShot

(load your module accrding below notes)

if we wanted to place this custom block into a page, we would simply substitute these values into our PHP code snippet (which we place in a node (page or other content type)) as follows:

Drupal 7

$block = module_invoke('block', 'block_view', 26);
print render($block);

Drupal 6 And Earlier

$block = module_invoke('block', 'block', 'view', 26);
print $block['content'];

Notice that the middle two terms ('block', 'view') always stay the same. You're simply updating the first and last term.

  • I'm not sure why you would want to do this when there are settings in the UI for exactly what the op wants.
    – Chapabu
    Sep 6, 2012 at 8:20
  • THis might be "similar" to the link mentioned but what Im looking is a module than a snippet of code.
    – ARGO
    Sep 6, 2012 at 8:28
  • @ARGO, ok I am expain in another way, see the edit
    – Yuseferi
    Sep 6, 2012 at 11:22
  • 1
    There are huge caveats needed when using the PHP filter. It should not be promoted as a good tool to do everything including the kitchen sink on a Drupal website. Because it store code in the database it prevent proper version tracking of that code. Leading to maintenance and evolution nightmares. Because it allow administrator to write any code on the page, it can easily lead to borken pages (ie. PHP Fatal Error) or worse, broken site (broken code in a block/node displayed on all pages including admin pages) hard to investigate and harder to fix. Sep 7, 2012 at 14:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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