Prevent hiding the Content Block on particular pages

create a separate tpl.php file for the desired page and remove those divisions from that tpl file
cheers

ask4prasath@gmail.com

Confirmed behavior. This happens even with Garland:

To reproduce:

- create a node (say node/1), with some text in the body.
- go to admin/structure/block/manage/system/main/configure
- configure 'Show block on specific pages' to not display on node/1
- go to node/1 -- you should not have the main content (but you do).

moving that block to another region also has no effect. perhaps the block isn't what it appears to be from the description?

looking through the API, it appears this may be by design. the 'main' content block in http://api.drupal.org/api/function/system_block_view/7 returns the entire page content as http://api.drupal.org/api/function/drupal_set_page_content/7

http://api.drupal.org/api/function/drupal_render_page/7 will display it even if it's been set to false.

ah, the content does move to the sidebar if you tell it, UNLESS you have it set to not display, in which case it's displayed back in the original location. appears that you cannot control the visibility of this block -- it's required. thus, we should disable that section for this block configuration page.

This patch removes the main content block visibility settings to avoid confusion.

Note that this doesn't stop an administrator from being able to "disable" the block (to no avail). I considered also removing the 'Disabled' option from the region drop-downs, but realized the same effect could be had by dragging it to the disabled region on the block list page.

The whole thing seems like a hack to me -- I guess it's useful to be able to label the main content and move it to another region. But it's obviously confusing to the administrator when it doesn't otherwise act like a block.

The alternative would be to have the main content block honor its visibility and disabled region settings. But that could too easily leave the entire site broken with no way to fix except in the database...

it actually doesn't show the main content block, but it does show it's content

with the block enabled on this particular page (garland btw) -> http://gyazo.com/c63b12dc919407654af84dc68d0a14bf.png
with the block disabled on this particular page -> http://gyazo.com/5d1941589acd5e23a56fb74dea0284bc.png

note the absence of the region and block wrappers

not saying this is how it's suppose to act, just trying to shed some light on what's actually happening

that's actually the way it's "supposed to act". you never want to disable content from the page, because that can effectively shut down your drupal site for good.

i suppose one might want to be able to turn off the block wrapper, and this would be the way to do that. seems like that's better handled with css to me.

maybe this issue should be marked 'won't fix'?

Tagging this so we can keep track as it relates to Bartik.

In common.inc, starting on line 4928, there are a few lines of code that basically say "has anyone printed the main content? if not, print it." The idea behind the code that keeps it there is that if you disable the block module, you'll be able to enable another page managing module (read: panels).

However, we can set that variable to TRUE regardless of anything in block.module. That's the approach this patch takes.

Moving to bartik project. Keeping at needs review until there's a dev release / CVS HEAD to review against.

Actually changed project this time, sorry.

Ummm, no, I believe this is larger than Bartik.

This applies to every theme, ever. I'd like to hide the content block.

subscribe

#15 works fine and solves the issue.

This comment in common.inc:4612 seems to indicate that this is probably the right way to handle the problem.

  else {
    // Indicate that the main content has been requested. We assume that
    // the module requesting the content will be adding it to the page.
    // A module can indicate that it does not handle the content by setting
    // the static variable back to FALSE after calling this function.
    $main_content_display = TRUE;
    return $content_block;
  }

However, it's worth asking whether this code (from common.inc:4772 - below) should simply be removed. I cannot think of a single case where the content region would be empty unless (a) the content region is hidden as in the example in the original post or (b) a module purposefully decides to manipulate the content region and therefore no assumptions should be made about whether or not to force the content.

  // If no module has taken care of the main content, add it to the page now.
  // This allows the site to still be usable even if no modules that
  // control page regions (for example, the Block module) are enabled.
  if (!$main_content_display) {
    $page['content']['system_main'] = drupal_set_page_content();
  }

Thoughts?

Well, if you disable the block module, then without that code you wouldn't be able to enable any module (like block or panels) to show the main content

Until right now I never realized that the block module *could* be disabled. Now that I know, I'd say your argument is compelling for keeping that code. :)

That said ... I'm happy with the patch in #15 so I'm marking RTBC. If someone else wants to come along and review then mark accordingly

What about doing a simple check in the code:
if it's on admin page, force display the content block;
if not, obey the user's setting.

So, the problem mentioned in #23 won't be a problem, and it keeps the flexibility of blocks.

Something like this:

  // On admin pages, if no module has taken care of the main content, 
  // add it to the page now. This allows the site to still be usable even 
  // if no modules that control page regions (for example, the Block
  // module) are enabled.
  if (!$main_content_display && arg(0) == "admin") {
    $page['content']['system_main'] = drupal_set_page_content();
  }

This seems like it might be a fragile solution...but then I think that every time I use the arg() function in an if()... thoughts?

#15: remove_default_content_687686.patch queued for re-testing.

Every time you use arg() god kills a kitten. arg() is not the solution. Ok, well maybe in Drupal >(8|9) we need it we still really sholudn't be using it. Disabling a module shouldn't make your site break, but you can't see anything except the admin section with that solution.

I still like my solution

It'd be good to get this documented in the code here, since it's not immediately obvious what's going on, and there's a lot in this issue that's not captured by just reading the code.

Hm. And come to think of it, we should add some tests, too, so we don't accidentally break this in the future.

Good idea. will do in a bit

This patch should work better.

oops, git patch

bah

At a minimum, s/manging/managing/

But the documentation doesn't make sense to me anyway since I'm not familiar with $system_main_content_added and the docs right now don't really tell me why it's being set to TRUE here. Is this some kind of flag that tells system module not to populate $content?

Ugly issue.

1. When Block module is disabled and no other page region handling module is acting, Drupal needs to force the output of the main content block.
2. When Block module is enabled, it is likely responsible for outputting the main content block, but not necessarily.
3. When Block module is enabled, but does not render the main content block (via visibility settings or other means), the main content block may still be rendered by another page region handling module. block_page_build() is executed anyway, and regardless of whether the main content block was actually output, the current patch would tell core that it has been output.
4. Clearly, the cause of this problem is that we do not invoke hook_block_view() for invisible blocks. Or in other words: Even if the page region handling module is properly acting, we cannot tell whether it attempted to output the main content, because in the case of Block module, the visibility settings prevent the invocation of the right callbacks to indicate that we attempted to render, but purposively did not want to render the main content. Or in other words: We are technically not able to differentiate between a failure and an intended omission.
5. We cannot change the invocation of block callbacks for D7. So we need to solve this with a hack. The currently proposed one makes me feel a bit nervous though, since it presumes that Block module, whenever enabled, is responsible for the main content block - since block_page_build() is invoked no matter what.

Hopefully this serves as summary to move on here. No conclusion contained, so please share your ideas and considerations.

Bumping this...

Having the main content as a block seems like a very elegant UI solution to, say, being able to hide the "river of news" content from the front page. That is a question I hear over and over from those new to Drupal: "How do I get all these posts off the front page?"

With a little bit of playing around with D7 this week, I've found that I've had trouble removing the front page content using a template override (which, incidentally, I finally figured out as being page--front.tpl.php rather than page-front.tpl.php). If I remove the <?php print render($page['content']); ?> line, I lose that block region on the front page...not the intended behavior. From the Blocks admin UI, it seems one should be able to define the Main page content block to not show on the <front> page only and call another (custom) block into that Content region.

What's the status on this one?

After re-reading my summary, the existing and recent patch is all we can do for D7.

Steps to fix this issue:

1) Revise and completely revamp the inline code comments, removing all emotions and "wordy" stuff.

2) Add a test to confirm that this patch fixes the problem.

3) Test manually, mark RTBC, and inform maintainers of Panels/Context and alike modules about this patch.

The patch in #35 didn't seem to work against 7.0-beta3 or HEAD, but I could be doing something wrong.

this is an untested reroll of #35 ...

This definitely needs some help text to explain the possible consequences of disabling the main content. But where should this help text be shown? There are several places where the visibility of the block can be changed:

1. In the main block admin page, by drag & drop or using the dropdown menu
2. in admin/structure/block/manage/system/main/configure under 'region settings'
3. in admin/structure/block/manage/system/main/configure under 'visibility settings'

A confirmation page would perhaps be the best solution.

Actually, if the main content itself is a block, the main title, the tags and messages are not. This makes the usefulness of the moving and/or hiding this block very very limited. Downgrading to a normal bug.

I was trying to do this again today, assuming it had been fixed since the early Bartik issues, and ran into this issue.

Damien: the situation described in #40 seems to be the most common use case (hiding the main content on a front/landing page, not a full node), in which case the proposed solution would be completely applicable so people have a core way of making a 'blocky' front page. Having the block hiding mysteriously not work is very confusing.

Hi All,

- I recreated the issue on my local.
- Tested the patch in #43.
- Works!
- Added a simpletest
- Rolled it in with the patch from #43...(which is a re-roll of #35.)

This is my first patch submit, so if someone could let me know if I'm doing this properly according to best practices... I feel like I missed a step ;)

...also, I do agree that perhaps there should be a warning/confirmation page. Maybe it would appear only when you're about to remove the Content block on all pages? Anywho...

Thanks,

I agree with all the comments here and wonder why the page content is set as a block with the typical show/hide options when they are really just fake options!

The solution I went with to remove the dynamic content from being pumped into the homepage was this:

1) Create a "page--front.tpl.php" template (duplicate the existing "page.tpl.php" and make sure they are both uploaded together)

2) Remove all the php calls inside the "content" div around line 105 leaving just this: print render($page['content']);

3) Change the "content" region to "content_home" or something similar: print render($page['content_home']);

4) Save file, open .info file and add the new "content_home" region below the definition for the "content" one. Upload all files mentioned.

5) Refresh the site and admin panel and you should now have two content regions ready to accept blocks: "Content" and "Content Home". Leave the offending page content block in the normal content one so it populates all subpages as expected, and drag all your homepage blocks to the new "Content Home" region.

Voila. Kludgy, especially with the direction of the logic they were going with in D7, but it works.

Still a valid issue in Drupal 7.2.

and 7.4. and btw, it's not only bartik... I'm using a customized Zen theme and it happens too.
subscribing

subscribing, as running into this issue again.

I "solved" it by creating a separate template for the front... but it still doesn't change the fact that hiding the content on the home via blocks is not working and it should... or at least should display some sort of message stating it wont.

subscribe

For Zen users, to prevent the main content block to show I made the following, in file zen/zen-internals/template.theme-registry.inc, added these lines:

  $main_content_display = &drupal_static('system_main_content_added', FALSE);
  $main_content_display = TRUE;

around lines 13-14, just after

 function _zen_theme(&$existing, $type, $theme, $path) {

This is not a clean solution, but Zen could implement a configuration property here and act accordingly.

Maybe other themes can be patched the same way.

Hi! This is my solution for hidden the main content block on the home:

1) You must create a new type content, for example 'home'.
2) On the configuration of the main content block, in 'Types of contents' select 'home' and save.
3) In the node block, file node.module line 2557, the following code appears:

drupal_set_title(t('Welcome to @site-name', array('@site-name' => variable_get('site_name', 'Drupal'))), PASS_THROUGH);

    $default_message = '<p>' . t('No front page content has been created yet.') . '</p>';

    $default_links = array();
    if (_node_add_access()) {
      $default_links[] = l(t('Add new content'), 'node/add');
    }
    if (!empty($default_links)) {
      $default_message .= theme('item_list', array('items' => $default_links));
    }

    $build['default_message'] = array(
      '#markup' => $default_message,
      '#prefix' => '<div id="first-time">',
      '#suffix' => '</div>',
    );

Well, comment it, and add:

    drupal_set_title('');
    $build['default_message'] = array(
      '#markup' => '',
      '#prefix' => '',
      '#suffix' => '',
    );

The main content block already not appear on the home page, but this is not perfect I know... but work. :)

Bye.

Looks like there are a few suggestions for fixing this. Let's get a current patch implementing one of them.

I've tested that solution #43 and #55 do not work in drupal 7.9, any ideas?

I found a theme-related solution, as in marinelli theme.
add following css pieces to drupa.css file:

.front #block-system-main {
  display:none;
}

clear cache, you will see 'main content page' disappears.

this issue needs a "might contain some of the worst ideas ever" tag

It looks like that all that want this would be using it to customize the front page. Why no simply allow just suppression on the front page? And error on anything else?

All work arounds have it computed, but suppress it in one way or another. In theory it is possible to safe some cycles by not computing it at all, as the system can know it will not be needed.

#7: remove_main_block_visilibity.687686.7.patch queued for re-testing.

Bad Information

Guys, hiding stuff with CSS is an ugly workaround. Don't do that.

I suggest a totally different approach: Disable the block visibility settings for the content area.

This matches the observed behaviour.

99% of the time the content area SHOULD NOT be hidden. (on all /admin and */edit pages for example it MUST NOT be hidden)

in that 1% where you think it should be hidden, such as landing pages, you SHOULD put the information you want to show into the content.

I personally think this is the simplest approach for the block module.

If you want anything more fancy, you can for example create a content type that only contains a title, or use a page views to push thing into the content area.

Ah, nice! I was looking for this patch. :) No longer seems to apply, though.

Okay, so here's a reroll of the patch for 8.x.

+++ b/core/modules/block/block.module
@@ -314,6 +314,15 @@ function block_page_build(&$page) {
+  // modules, but since this is a page-manging module, we're in charge of the

should be page-managing

+++ b/core/modules/block/lib/Drupal/block/Tests/ContentBlockTest.php
@@ -0,0 +1,69 @@
+    parent::setUp();

Need to pass an array of modules to setUp that need enabled. Block needs to be one of them.

attached is a patch that does what I suggested above, yet still fails. There's something wrong with my syntax in the settings array for body, because even if I simplify it to drupalCreateNode(...) followed by drupalGet('node/1'), the body doesn't show up in the get request. I'm marking this needs review to invoke testbot so others can see the error.

If you want to hide the main contents block why can't you use a small contrib which slaps an #access FALSE on it? #65 sounds the right idea to me -- do not allow the main content to be hidden.

Also... I doubt this can happen in D7 and hopefully in D8 Blocks Everywhere will kill this issue before we kill each other debating over it :)

I updated the title according to how I understand this issue is headed.
Can someone update the issue summary?

added issue summary template

switched input format

Changed issue summary

Updated issue summary

Fixed typo

Edit

Edit

Remove img tags for remote images, link to the image instead, since we are not allowed remote images

This is a test for the approach in #65 which is removing the visibility settings on the main content block.

Attached is a patch that hides visibility setting is module is system and delta is main.

The only problem is that the node module has a hook_form_alter that adds content type to the visibility pane. However; it doesn't have a block object in the function, so putting a conditional if statement there is more difficult.

It might be possible to investigate the block based on the form array, but I want to hear further advisement before I modify that module as well.

Happend with the lastest released version:
The system "push" this block into the content region, even if the block is set to exclude the path or set to none region.
Happend with child theme of zen.

Please see the backport policy.

Instead of patching this behaviour, we should more likely circumvent it.

I've created a small module which contains a context reaction, to remove the system content block. This way we don't have to patch core, and we can re-use the functiunality with context conditions.

See attachment for module, until I can release this as a real module on d.o.

This doesn't apply anymore.

Working on re-roll to current head

Re-rolled to current head.

Kicking back to coders. Conflict in reroll. The head has a newer function block_admin_demo()

/**
 * Page callback: Attaches CSS for the block region demo.
 *
 * @see block_menu()
 */
function block_admin_demo($theme = NULL) {
<<<<<<< HEAD
  return array(
    '#attached' => array(
      'css' => array(drupal_get_path('module', 'block') . '/css/block.admin.css'),
    ),
  );
=======
  drupal_add_css(drupal_get_path('module', 'block') . '/block.admin.css');
  return '';
}

/**
 * Page callback: Shows the block administration page.
 *
 * @param $theme
 *   The theme to display the administration page for. If not provided, defaults

Working on the reroll.

Tried a reroll, but there was a large conflict. #88 only shows the first part of the conflict.

I'm actually now thinking this should be closed as "works as designed"

If you have multiple modules that are able to show the main content, such as Panels and the Block module, as long as for example Panels is showing the main content, you can hide the block without a problem. (or you can show the content twice on the page)

Only if no module handles the main content for example when Panels doesn't handle the main content AND you have the Block module disabled (or the block hidden) Drupal will print the main content as a fail-safe to prevent breakage of your site.

I've seen several other issues clutter this issue, such as the front page node listing (front page can be edited in setting, there's a published to front page setting, I agree /node should be able to be disabled but that is another issue.) that do not belong in this issue.

Really, 99% of the time the content area SHOULD NOT be hidden. (on all /admin and */edit pages for example it MUST NOT be hidden)

in that 1% where you think it should be hidden, such as landing pages, you SHOULD put the information you want to show into the content.

If you want anything more fancy, you can for example create a content type that only contains a title (perhaps together with the Rabbit Hole module), or use a page views to push thing into the content area.

http://drupalofficehours.org/task/309

This patch seems to be created for D7 whereas the issue is tagged 8.x.

Tried to reroll the patch. There were two files deleted and status is upto date. Hence no need to reroll the patch.

This is a difficult issue to review. The Issue Summary is a bit of a muddle. The problem refers to selection and option lists but then there isn't any reference to that in the comments. The remaining tasks says the the Issue summary has diverged from the original and then asks if this should be split into two issue but, again, didn't find any comments discussing that point. And It would really help to have complete Steps to Reproduce.

In #38 sun gives a nice summary of the situation. And then in#41 says that the patch in #35 (rerolled in #43) in the best that can be done for D7, with some further suggestions. Then a patch in #47 that was tested and includes a test.

Then, there is #65 which says that this works as designed and offers ways to not show the block. This is supported in #73 and reiterated in #91.

Then I took a pause and looked for related issues and found #2546590: Main content block shows up on page, even if hidden. That is a duplicate, working to solve the same problem. However that one is D8+ specific while this is D7. Therefor, changing this to D7.