Problem/Motivation
In certain circumstances, the Main Content Block appears appears in a selection list, as an optional selection. It should not be optional.
Proposed resolution
Prevent the Main Content Block from being deselected. The main Content Block's selectability is being modified to prevent it from not being selected, or deselected, since it is required for proper rendering.
Remaining Tasks
The issue summary seems to have strayed from the original report. "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." vs. "In certain circumstances, the Main Content Block appears in a selection list, as an optional selection. It should not be optional." Should this be split into two different issues? Also see comment #65 as a possible work around.
User interface changes
@todo
API changes
@todo
Original report by jensimmons
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.
http://img.skitch.com/20100117-mbc747ueerwi95gybkqjea25ty.jpg
The sidebar blocks are hidden. The content block displays.
http://img.skitch.com/20100117-bk5ppxy5ai2stj1ya5pahayy2d.jpg
It should instead look like this:
http://img.skitch.com/20100117-xgwbjunijy7hfxy6d8abj5xb99.jpg
Comments
Comment #1
ask4prasath CreditAttribution: ask4prasath commentedcreate a separate tpl.php file for the desired page and remove those divisions from that tpl file
cheers
ask4prasath@gmail.com
Comment #2
jensimmons CreditAttribution: jensimmons commentedA) 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.
Comment #3
aaron CreditAttribution: aaron commentedConfirmed 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).
Comment #4
aaron CreditAttribution: aaron commentedmoving that block to another region also has no effect. perhaps the block isn't what it appears to be from the description?
Comment #5
aaron CreditAttribution: aaron commentedlooking 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.
Comment #6
aaron CreditAttribution: aaron commentedah, 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.
Comment #7
aaron CreditAttribution: aaron commentedThis patch removes the main content block visibility settings to avoid confusion.
Comment #8
aaron CreditAttribution: aaron commentedNote 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.
Comment #9
aaron CreditAttribution: aaron commentedThe 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...
Comment #10
seutje CreditAttribution: seutje commentedit 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
Comment #11
aaron CreditAttribution: aaron commentedthat'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'?
Comment #12
JacineTagging this so we can keep track as it relates to Bartik.
Comment #13
dmitrig01 CreditAttribution: dmitrig01 commentedComment #14
jensimmons CreditAttribution: jensimmons commentedYou 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.
Comment #15
dmitrig01 CreditAttribution: dmitrig01 commentedIn 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.
Comment #16
willmoy CreditAttribution: willmoy commentedMoving to bartik project. Keeping at needs review until there's a dev release / CVS HEAD to review against.
Comment #17
willmoy CreditAttribution: willmoy commentedActually changed project this time, sorry.
Comment #18
aaron CreditAttribution: aaron commentedUmmm, no, I believe this is larger than Bartik.
Comment #19
jensimmons CreditAttribution: jensimmons commentedYeah — 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.
Comment #20
RobLoachThis applies to every theme, ever. I'd like to hide the content block.
Comment #21
bleen CreditAttribution: bleen commentedsubscribe
Comment #22
bleen CreditAttribution: bleen commented#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.
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.
Thoughts?
Comment #23
dmitrig01 CreditAttribution: dmitrig01 commentedWell, 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
Comment #24
bleen CreditAttribution: bleen commentedUntil 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
Comment #25
BettyJJ CreditAttribution: BettyJJ commentedWhat 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.
Comment #26
bleen CreditAttribution: bleen commentedSomething like this:
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?
Comment #27
realityloop#15: remove_default_content_687686.patch queued for re-testing.
Comment #28
dmitrig01 CreditAttribution: dmitrig01 commentedEvery 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
Comment #29
webchickIt'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.
Comment #30
webchickHm. And come to think of it, we should add some tests, too, so we don't accidentally break this in the future.
Comment #31
dmitrig01 CreditAttribution: dmitrig01 commentedGood idea. will do in a bit
Comment #32
dmitrig01 CreditAttribution: dmitrig01 commentedComment #33
dmitrig01 CreditAttribution: dmitrig01 commentedThis patch should work better.
Comment #35
dmitrig01 CreditAttribution: dmitrig01 commentedoops, git patch
Comment #36
dmitrig01 CreditAttribution: dmitrig01 commentedbah
Comment #37
markabur CreditAttribution: markabur commentedAt 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?
Comment #38
sunUgly issue.
Hopefully this serves as summary to move on here. No conclusion contained, so please share your ideas and considerations.
Comment #39
jensimmons CreditAttribution: jensimmons commentedBump.
At the minimum, in my opinion, we need some help text to let people know what's going on.
Comment #40
scottrouse CreditAttribution: scottrouse commentedBumping 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?
Comment #41
sunAfter 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.
Comment #42
scottrouse CreditAttribution: scottrouse commentedThe patch in #35 didn't seem to work against 7.0-beta3 or HEAD, but I could be doing something wrong.
Comment #43
bleen CreditAttribution: bleen commentedthis is an untested reroll of #35 ...
Comment #44
pfrenssenThis 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.
Comment #45
Damien Tournoud CreditAttribution: Damien Tournoud commentedActually, 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.
Comment #46
stephthegeek CreditAttribution: stephthegeek commentedI 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.
Comment #47
sebsebseb123 CreditAttribution: sebsebseb123 commentedHi 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,
Comment #48
pixelgrrl CreditAttribution: pixelgrrl commentedI 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.
Comment #49
Tor Arne Thune CreditAttribution: Tor Arne Thune commentedStill a valid issue in Drupal 7.2.
Comment #50
caravinci CreditAttribution: caravinci commentedand 7.4. and btw, it's not only bartik... I'm using a customized Zen theme and it happens too.
subscribing
Comment #51
ckngsubscribing, as running into this issue again.
Comment #52
caravinci CreditAttribution: caravinci commentedI "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.
Comment #53
andrenoronha CreditAttribution: andrenoronha commentedsubscribe
Comment #54
ziodave CreditAttribution: ziodave commentedFor 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:
around lines 13-14, just after
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.
Comment #55
migrad CreditAttribution: migrad commentedHi! 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:
Well, comment it, and add:
The main content block already not appear on the home page, but this is not perfect I know... but work. :)
Bye.
Comment #56
xjmLooks like there are a few suggestions for fixing this. Let's get a current patch implementing one of them.
Comment #57
this_is_it CreditAttribution: this_is_it commentedI've tested that solution #43 and #55 do not work in drupal 7.9, any ideas?
Comment #58
this_is_it CreditAttribution: this_is_it commentedI found a theme-related solution, as in marinelli theme.
add following css pieces to drupa.css file:
clear cache, you will see 'main content page' disappears.
Comment #59
seutje CreditAttribution: seutje commentedthis issue needs a "might contain some of the worst ideas ever" tag
Comment #60
bdu CreditAttribution: bdu commentedIt 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.
Comment #61
clicsoluciones CreditAttribution: clicsoluciones commented#7: remove_main_block_visilibity.687686.7.patch queued for re-testing.
Comment #62
jensimmons CreditAttribution: jensimmons commented@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.
Comment #63
kamescg CreditAttribution: kamescg commentedBad Information
Comment #64
pfrenssenGuys, hiding stuff with CSS is an ugly workaround. Don't do that.
Comment #65
alexanderpas CreditAttribution: alexanderpas commentedI 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.
Comment #66
webchickAh, nice! I was looking for this patch. :) No longer seems to apply, though.
Comment #67
ryan.gibson CreditAttribution: ryan.gibson commentedOkay, so here's a reroll of the patch for 8.x.
Comment #69
disasm CreditAttribution: disasm commentedshould be page-managing
Need to pass an array of modules to setUp that need enabled. Block needs to be one of them.
Comment #70
disasm CreditAttribution: disasm commentedComment #71
disasm CreditAttribution: disasm commentedattached 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.
Comment #73
chx CreditAttribution: chx commentedIf 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.
Comment #74
chx CreditAttribution: chx commentedAlso... 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 :)
Comment #75
tim.plunkettI updated the title according to how I understand this issue is headed.
Can someone update the issue summary?
Comment #75.0
tim.plunkettadded issue summary template
Comment #75.1
tim.plunkettswitched input format
Comment #76
tracycarroll CreditAttribution: tracycarroll commentedChanged issue summary
Comment #76.0
tracycarroll CreditAttribution: tracycarroll commentedUpdated issue summary
Comment #76.1
tracycarroll CreditAttribution: tracycarroll commentedFixed typo
Comment #76.2
tracycarroll CreditAttribution: tracycarroll commentedEdit
Comment #76.3
tracycarroll CreditAttribution: tracycarroll commentedEdit
Comment #76.4
Jeff Burnz CreditAttribution: Jeff Burnz commentedRemove img tags for remote images, link to the image instead, since we are not allowed remote images
Comment #77
ajeverson CreditAttribution: ajeverson commentedThis is a test for the approach in #65 which is removing the visibility settings on the main content block.
Comment #78.0
(not verified) CreditAttribution: commentedEdited Issue Summary
Comment #79
disasm CreditAttribution: disasm commentedAttached 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.
Comment #80
disasm CreditAttribution: disasm commentedComment #81
AlmogBaku CreditAttribution: AlmogBaku commentedHappend 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.
Comment #82
tim.plunkettPlease see the backport policy.
Comment #83
nightlife2008 CreditAttribution: nightlife2008 commentedInstead 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.
Comment #84
tstoecklerThis doesn't apply anymore.
Comment #85
pwieck CreditAttribution: pwieck commentedWorking on re-roll to current head
Comment #86
pwieck CreditAttribution: pwieck commentedRe-rolled to current head.
Comment #88
pwieck CreditAttribution: pwieck commentedKicking back to coders. Conflict in reroll. The head has a newer function block_admin_demo()
Comment #89
rgoodine CreditAttribution: rgoodine commentedWorking on the reroll.
Comment #90
rgoodine CreditAttribution: rgoodine commentedTried a reroll, but there was a large conflict. #88 only shows the first part of the conflict.
Comment #91
alexanderpas CreditAttribution: alexanderpas commentedI'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.
Comment #91.0
alexanderpas CreditAttribution: alexanderpas commentedhttp://drupalofficehours.org/task/309
Comment #92
alansaviolobo CreditAttribution: alansaviolobo commentedThis patch seems to be created for D7 whereas the issue is tagged 8.x.
Comment #94
Sonal.Sangale CreditAttribution: Sonal.Sangale at Blisstering Solutions commentedTried to reroll the patch. There were two files deleted and status is upto date. Hence no need to reroll the patch.
Comment #102
quietone CreditAttribution: quietone as a volunteer commentedThis 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.