Posted by jensimmons on January 18, 2010 at 12:01am
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | block.module |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
| Issue tags: | API change, Bartik, Needs tests, zen |
Issue Summary
Normally, when you configure a block, and you say "Show block on All Pages except those listed", and then you list a page, the block is hidden on that page.
If you are configuring the Content block, this is not true.
I set the content block on my site to list on every page except "node/9". I also did this for all the blocks in the sidebar.
The sidebar blocks are hidden. The content block displays.
It should instead look like this:
Comments
#1
create a separate tpl.php file for the desired page and remove those divisions from that tpl file
cheers
ask4prasath@gmail.com
#2
A) Those screenshots are from Bartik, a theme for core, so making a custom tpl is not an option. This is not a design for a specific site, it's the design of a tool for anyone to use without hacking the theme. (You can see the Bartik demo at http://bartik.milkweedmediadesign.com/node/9 )
B) The content block should hide like all the other blocks. There is no indication that the behavior of this one block is different from the others. The interface and the help text on the content block setting page all indicate this block will hide. The fact is doesn't is a bug. It's a new "drupal wtf?"
Let's fix it.
#3
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).
#4
moving that block to another region also has no effect. perhaps the block isn't what it appears to be from the description?
#5
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.
#6
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.
#7
This patch removes the main content block visibility settings to avoid confusion.
#8
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.
#9
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...
#10
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
#11
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'?
#12
Tagging this so we can keep track as it relates to Bartik.
#13
#14
You can't disable the content block? Then what's the point of making content a block? I think it would be great to be able to disable the content block on certain pages. Especially the front page. Sure those of us who know how to erase the printing of $content from the page-front.tpl.php don't need this, but what about everyone else?
Perhaps we leave a safety so it's not possible to disable it on all pages. Only a certain list of them.
For sure, changing the help text would help. Right now, it's pretty misleading.
#15
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.
#16
Moving to bartik project. Keeping at needs review until there's a dev release / CVS HEAD to review against.
#17
Actually changed project this time, sorry.
#18
Ummm, no, I believe this is larger than Bartik.
#19
Yeah — this isn't about Bartik, this is about core. I designed Bartik to take serious advantage of the fact content is now a block, assuming I could hide the content block like any other block.... and then I discovered you can't do that.
I think you should be able to do so. If that seems like a dangerous power to give people, then let's put warning messages along the way and ask for confirmation.
Or, if there is some reason why we don't want to allow people to hide the content block completely, then let's allow them to hide in on a few specific pages (disabling the options to hide always or hide everywhere except ) and put clear help text in place to explain what's going on.
OR if the consensus disagrees with me completely, and wants to ban the hiding content in any way, then at the minimum there must be help text explaining what's up, and that you can't hide the content block like other blocks.
I know I'm repeating myself, but there seem to be confusion about about what I'm talking about. If you still don't understand, go install D7, and imagine you are building a site. Then think to your hypothetical self, "hey I'd like to have one of those cool front pages with a while bunch of different blocks that only show up there — and oh! I'll hide the block that's the long list of blog posts on the home page... that will be cool. I know how to hide that block..... uh... why is it still there? What's wrong? Why isn't this working? I don't get Drupal. I suck!" <<-- we don't want that.
#20
This applies to every theme, ever. I'd like to hide the content block.
#21
subscribe
#22
#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?
#23
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
#24
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
#25
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.
#26
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?
#27
#15: remove_default_content_687686.patch queued for re-testing.
#28
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
#29
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.
#30
Hm. And come to think of it, we should add some tests, too, so we don't accidentally break this in the future.
#31
Good idea. will do in a bit
#32
#33
This patch should work better.
#34
The last submitted patch, remove_default_content_687686.patch, failed testing.
#35
oops, git patch
#36
bah
#37
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?
#38
Ugly issue.
Hopefully this serves as summary to move on here. No conclusion contained, so please share your ideas and considerations.
#39
Bump.
At the minimum, in my opinion, we need some help text to let people know what's going on.
#40
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?
#41
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.
#42
The patch in #35 didn't seem to work against 7.0-beta3 or HEAD, but I could be doing something wrong.
#43
this is an untested reroll of #35 ...
#44
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:
A confirmation page would perhaps be the best solution.
#45
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.
#46
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.
#47
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,
#48
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:
<?phpprint render($page['content']);
?>
3) Change the "content" region to "content_home" or something similar:
<?phpprint 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.
#49
Still a valid issue in Drupal 7.2.
#50
and 7.4. and btw, it's not only bartik... I'm using a customized Zen theme and it happens too.
subscribing
#51
subscribing, as running into this issue again.
#52
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.
#53
subscribe
#54
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.
#55
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.
#56
Looks like there are a few suggestions for fixing this. Let's get a current patch implementing one of them.
#57
I've tested that solution #43 and #55 do not work in drupal 7.9, any ideas?
#58
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.
#59
this issue needs a "might contain some of the worst ideas ever" tag
#60
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.
#61
#7: remove_main_block_visilibity.687686.7.patch queued for re-testing.
#62
@bdu — This would be helpful for any kind of landing page, not just the front page. Many sites with lots of content have complex landing pages for everything — taxonomy terms, subsections of the site... I could see similar things done for even little sites.
I think having something like this behave differently on the page marked "front page" from all other pages would only add an even more complicated WTF.