Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
I needed that the Display Suite block fields respect the role and page visibility settings that are set up in block administration.
After looking into Context Respect module which provides the same functionality for Context module I made a patch for Display Suite.
Comments
Comment #1
martins.bertins CreditAttribution: martins.bertins commentedHere's the patch.
Comment #2
martins.bertins CreditAttribution: martins.bertins commentedFixed some typing errors in the patch.
Comment #3
Bernsch CreditAttribution: Bernsch commentedComment #4
swentel CreditAttribution: swentel commentedThere's spaces in the patch, and this was intented by design, not a bug report.
Comment #5
martins.bertins CreditAttribution: martins.bertins commentedRemoved the spaces.
Comment #6
kclarkson CreditAttribution: kclarkson commented@swentel,
I need this functionality as well. Basically I have an event that utilizes the registration form. Only logged in users can register for my events so I wanted to create a simple block that says: "you must be logged in to register" and use the block default visibility settings.
Because I am using Display suite for my layout I would like to position that custom block field but only want it to show for anonymous users.
Comment #7
kclarkson CreditAttribution: kclarkson commentedComment #8
kclarkson CreditAttribution: kclarkson commented@ martins.bertins
I just applied your most recent patch. Applied cleanly and now the blocks respect the default settings THANKS !!!!!
ps- at first I didn't think it was working but realized I was logged in as User 1. After I logged in with a different user it worked.
Comment #9
Shane Birley CreditAttribution: Shane Birley commentedI can confirm that the patch is working as expected. This should find its way into the commit list soonish. Quite an important and powerful change.
*UPDATE*
I spoke too soon. It worked for about five minutes and then (once the cache was cleared) I started getting:
Warning: include() [function.include]: Failed opening '.tpl.php' for inclusion (include_path='.:/usr/share/pear:/usr/share/php') in theme_render_template() (line 1495 of /includes/theme.inc).
It seems to open up a hole and "forgets" what theme bits are being loaded. Unsure if it is related but, if I return to the original ds.module file, the problem goes away.
Comment #10
bmodesign CreditAttribution: bmodesign commentedPatch #5 worked for me, installed on commerce kickstart.
Comment #11
markosef CreditAttribution: markosef commentedDoesn't work in my case. I use "Show block on specific pages" and "Content type" combined and when I combine the two, block is not displayed in those cases. Thinking of giving up on using DS for views as it just makes a mess.
Comment #12
swentel CreditAttribution: swentel commentedI'm sorry, but the visibility doesn't fly here for these kind of blocks.
Comment #13
kclarkson CreditAttribution: kclarkson commented@Swentel,
Does the patch in #5 not fix the solution ? Is there a reason you do not want to include this patch ?
Comment #14
swentel CreditAttribution: swentel commentedTalked to Mārtiņš at DrupalCamp Baltics.
The problem with the current patch is following: committing it like this would mean that suddenly visibility settings will kick on existing sites in case a block is also used on other places. This is not desired behavior, so it means we need an extra setting on the block field. Something like 'respect visiblity settings.
Another better option also than the current patch is probably just calling drupal_alter('block_list); which then would mean all kind of visibility settings would work automatically out of the box (pages, content types, php, language etc).
Comment #15
jwa CreditAttribution: jwa commentedExactly the same code as provided in #5, but updated line numbers so it can patch with DS 2.6
Comment #16
nicktr CreditAttribution: nicktr commentedThank you for this patch. Works nicely. Using DS 2.6.
Comment #17
aspilicious CreditAttribution: aspilicious commentedI agree with #14 so a committable patch would go in that direction.
I fixed this for the drupal 8 version, so we don't have any issues there.
Comment #18
Leeteq CreditAttribution: Leeteq commentedComment #19
skribbz14 CreditAttribution: skribbz14 commentedJust applied the patch from comment #15 and it doesn't appear to be affecting block visibility settings for restricting anonymous users.
What I am trying to do is hide particular blocks from anonymous users. I created the blocks and set their role visibility settings to "authenticated user" only, by checking only that roles' checkbox. I then created Display Suite custom block fields for each block and placed them on their view mode and pages. When logged out I can still see these blocks.
What's weird is that if I do the opposite and restrict a particular block from people who are logged in that works just fine, so that part is working, but I really need to hide things from anonymous users as well.
Thanks for any help in advanced!
Update:
I was able to able to configure role permissions for individual fields once I enabled "Field permissions", using the Display Suite Extras module.
Comment #20
khanz CreditAttribution: khanz commentedI am using a block to show adsense ads on nodes, but the block are also shown on node and comment preview pages and is a undesirable function for me. Trying to restrict the block in specific paths doesn't works with ds 2.6.
Comment #21
mducharme CreditAttribution: mducharme commentedThis feature request has been marked as "won't fix" several times already. I really needed this functionality as well though and the solution in the meantime is Field Formatter Conditions.
It replicates block visibility settings on the block field (or any field when managing display) at the cost of two extra modules.
Comment #22
bousley CreditAttribution: bousley commentedThis is a pretty serious issue. I don't see why they continue to mark this issue as "won't fix". It runs directly contrary to how blocks function as far as context goes...
Comment #23
mducharme CreditAttribution: mducharme commentedI have an idea. What about adding a new checkbox within the extras settings called "Respect Block Visibility" that would be checked before executing the code in this patch? That would resolve the issue raised in #14 since it would be off by default.
Thoughts?
Comment #24
mparker17+1 to @mducharme's idea in #23.
Comment #25
mducharme CreditAttribution: mducharme commentedRe #14
I thought this was a good idea since it leverages a block function but it's not going to work for this case. ```block_list``` depends on checking the theme's regions to determine whether or not the block should be displayed. Since we can use disabled blocks as DS block fields, those will be never checked. Even if block_list allowed us to check for "disabled" blocks, it's a memory hog and caused timeouts throughout my testing.
It would be great if there was an easy way to say "**IF** this block were to be rendered **anywhere** on this page, would the value of $block->visibility be 0 or 1?".
Comment #26
daggerhart CreditAttribution: daggerhart commentedThe patch from #15 is good except one thing. It attempts to detect if the user is admin with ($user->uid > 1). This causes the patch to ignore role visibility for anonymous users.
Attached is a re-roll of the #15 patch with this issue corrected.
Comment #27
nickBumgarner CreditAttribution: nickBumgarner commentedJust tested #26 and it seems to be working perfectly. Even anonymously it works! Thanks.
Comment #28
bousley CreditAttribution: bousley commentedThanks, daggerhart!
Comment #29
swentel CreditAttribution: swentel commented#23 sounds sane yes
Comment #30
DYdave CreditAttribution: DYdave commentedFollowing-up with #29 and @swentel's confirmation of #23's approach, I went ahead and tried to add this feature on top of the patch from #26, which seems to have been tested successfully at #27 and #28.
Please find attached to this comment an updated patch against ds-7.x-2.x at 1640acd, which does everything #26's did, plus adds a new checkbox on the DS block field edit/add form, called Respect Block Visibility, to allow users to enforce block's visibility settings for the field (approach from #23).
File attached as: ds-7.x-2.x-respect-block-visibility-settings-1936128-30.patch.
See attached screenshot of the resulting DS block field edit/add form:
Switching back issue to needs review for testing, feedback and reviews.
Feel free to let me know if you would have any comments, questions, issues, suggestions, objections or ideas on this updated patch, I would certainly be glad to provide more information.
Thanks very much in advance for everyone's testing/reporting, reviews and comments.
Comment #31
swentel CreditAttribution: swentel commentedLooks good on a first view - haven't tested it manually yet, will try this weekend. Others can too of course.
Two small code things
extreme nitpick: needs a space between 'if' and '('.
Default value should probably be FALSE instead of an empty string.
Comment #32
DYdave CreditAttribution: DYdave commentedThanks a lot @swentel for this detailed review.
I wish I could have received nitpicked reviews like that more often.
Please find attached to this comment a re-rolled patch from #30 against ds-7.x-2.x at 1640acd, including all the code comments/changes suggested at #31.
File attached as: ds-7.x-2.x-respect-block-visibility-settings-1936128-32.patch.
Any comments, feedback, testing/reporting, questions, reviews or suggestions on the re-rolled patch or the ticket in general would be greatly appreciated.
Thanks very much in advance for everyone's testing/reporting, reviews and comments.
Comment #33
mducharme CreditAttribution: mducharme commentedI've tested this and it works as expected.
I'm on the fence about having a "per-block field" vs a global setting in ds extras though. My concern is that you're left with a mixed mode where, down the road, a user configuring the core block visibility for two blocks might see the changes for one and not the other. I definitely see the added flexibility per-block though so I'm happy to see this method move forward.
Comment #34
aspilicious CreditAttribution: aspilicious commentedLooks sane to me.
[little hijack of the issue]
One more thing, related to drupal 8. Do we want the same flexibility or do we prefer to always follow the restrictions put on the block?
Comment #35
swentel CreditAttribution: swentel commentedGave this more thought. This won't work if someone uses i18n to respect language visibility. So the trick here is that we need to mimic hook_block_list_alter(). like block module does, then any block visibility will work out of the box.
@see _block_load_blocks()
This will also reduce the code immensively!
Comment #36
mducharme CreditAttribution: mducharme commentedHere's a rewrite of the patch based on your notes @swentel. It definitely reduces the code by offloading all of the block processing. I've tested a lot of scenarios and this seems to hold up.
Comment #37
swentel CreditAttribution: swentel commentedLooks amazing, will test this over the weekend unless aspilicious beats me to it - could probably use a couple of verifications anyway to make sure we really don't break existing installations :)
Comment #38
stephenpar CreditAttribution: stephenpar commentedI am using modules Organic Groups, Event and Entity Registration to allow group members to register to events. Users can only join Events organised for Groups that they are a member of. Everything worked fine except that Entity Registration doesn't show a link to Cancel a registration once a user is registered and I also wanted to display a list of participants (to logged in users only) when viewing an Event.
So Display Suite is used to display a block of Registrations that shows the username, company name and a Delete link of all people who have resgistered to attend. The delete link only shows at the user's own row as expected. Admins will see the delete link at all rows. It was almost perfect except that the Registrations block was also visible to anonymous users.
Then I applied patch #1936128-36 to 7.x-2.6 and here are the results.
Can anyone tell me how to fix this please?
Edited:
Basically the problem is with an empty block. Before applying the patch an empty block didn't cause any Notices to appear. The patch doesn't handle empty blocks well.
For now and until this is fixed I'll just make sure that the block is not empty even if there are no results by using the No Results Behaviour in the View.
Comment #39
mducharme CreditAttribution: mducharme commentedThanks for the detailed explanation. I know what the problem is and will post an updated patch shortly (hopefully within 24 hrs).
Comment #40
mducharme CreditAttribution: mducharme commentedFixed. I realized while reviewing the code that I had accidentally removed the check to ensure that the core block module was enabled. That's fixed too.
Comment #41
mducharme CreditAttribution: mducharme commentedComment #42
aguilara CreditAttribution: aguilara commentedI applied this patch and for some reason it seems to not be doing what I thought it was supposed to. From my understanding, this patch would allow one to add a block field using Display Suite and then be able to control the pages where the block would appear using the Visibility settings of the block and still be displaying in the section that it was added to in Display Suite. However, what ended up happening is that the Block settings ended up overwriting completely the Display Suite block field.
The situation I was trying to fix is that I have a two column display that I use for only two Basic Pages by using the "View mode per node" feature in the Extras of Display Suite. These two basic pages are supposed to have two different blocks in them (one in each column). So I was hoping that using this patch, I would be able to have only one "Two Column" view mode for these pages and add all four different blocks using Display Suite's block fields and place the blocks in the correct column using the Manage Display UI. Then use the Block settings to specify in which pages the blocks will appear. Now checking the "Respect Block Visibility" does indeed allow the Block settings to affect Display Suite. What happens though is that when I enter the page where I want the block to appear, the Block gets added to the Content section of the page. Which does cause the block to appear in the page the settings listed, but it is displayed in a one Column View. Maybe this has to do with the fact that I am using the "View per node feature" and by default, the block is displayed using the Default view for the content type? Hopefully my explanation makes sense and someone has an idea as to what is going on.
Thanks!
Comment #43
mducharme CreditAttribution: mducharme commentedI just ran through several tests and couldn't replicate your issue @aguilara. Everything worked as expected so I don't think it's related to this patch. I had a bit of trouble understanding your case/workflow though so I suggest posting a new issue or support request since I think it's display mode per node related. Post a link to your issue here and I'll head over and paste my step-by-step process for you to compare.
Comment #44
asad.hasan CreditAttribution: asad.hasan commented#40 works great, however native menu blocks do not work, I have to use some other modules menu block.
Please advise.
Comment #45
mducharme CreditAttribution: mducharme commented@asaduiux I just went through testing both the main menu and user menu "native" blocks and they work as expected with this patch. Can you provide the steps to reproduce the problem that you're seeing?
Comment #46
zmove CreditAttribution: zmove commented#40 perfectly work (don't forget to edit your field and check the option "Respect block visibility").
+1 for a quick commit as it sounds more like a bug report than a feature request to me.
Comment #47
kerrycurtain CreditAttribution: kerrycurtain commentedConfirm also that #40 works a treat, thank you.
Comment #48
kerrycurtain CreditAttribution: kerrycurtain commentedComment removed
Comment #49
bdanin CreditAttribution: bdanin commentedpatch in #40 works very well for me, huge help, thanks!!
Comment #50
hansrossel CreditAttribution: hansrossel commentedpatch #40 works here too
Comment #51
hansrossel CreditAttribution: hansrossel commentedAfter applying patch #40 there is a caching issue when I create a new views block field; to reproduce
- make a views block
- create a block field for that view, leave everything default and do not select the respect visibility settings
- enable the block field: nothing is visible
To fix it:
- go to the block config in the block overview and save the block => the block field is visible now
Comment #52
hansrossel CreditAttribution: hansrossel commentedComment #53
bdanin CreditAttribution: bdanin commented@hansrossel, before going to the block config admin screen and saving the block, did you try to clear all Drupal caches to see if that alone fixes the problem? Just wanting to make sure that before we switch back to "needs work" that something is actually breaking
Comment #54
dshields CreditAttribution: dshields at Canadian Blood Services commentedIt'd be great to hear back from @hansrossel (who set it to "Needs work") on this.
Comment #55
hansrossel CreditAttribution: hansrossel commentedUnfortunately I don't remember anymore for which site I used it. If I'm the only one that had cache issues it might also have been something with that specific site. I did not test it with a vanilla Drupal installation. So set back to reviewed and tested if you feel like.
Comment #56
mducharme CreditAttribution: mducharme commentedThe patch still applies cleanly to 7.x-2.13 and 7.x-2.x.
Comment #57
dshields CreditAttribution: dshields at Canadian Blood Services commentedComment #58
ron_s CreditAttribution: ron_s commentedPatch still applies cleanly to 7.x-2.14.
We've been using this for almost 2 years now... can we finally get patch #40 committed? Thanks.
Comment #59
lanceh1412 CreditAttribution: lanceh1412 commentedThis patch (#40) works fine for me on 7.x-2.14
Comment #60
dshields CreditAttribution: dshields at Canadian Blood Services commentedComment #62
swentel CreditAttribution: swentel at eps & kaas for MuseScore commentedOk. I went ahead and committed this to dev. Will let it like this for a while to make sure enough people can test it.
Comment #63
rubendello CreditAttribution: rubendello commentedComment #64
rubendello CreditAttribution: rubendello commentedDid, by any chance, somebody tried to make this work in D8?
Comment #66
MariaIoann CreditAttribution: MariaIoann commentedI updated DS from 7.x-2.14 to 7.x-2.15 which includes patch #40 and my DS block fields (Quick Tabs blocks) are not being rendered.
Debugging it, seems that
$block->content['#markup']
is not set. Using the Default DS Block Layout it works, but then I have to manually hide the block title.Maybe, it is related to this: https://www.drupal.org/project/ds/issues/2962309
Is it a DS issue or a Quick Tabs issue?
Comment #67
maartendeblock CreditAttribution: maartendeblock at EntityOne commentedUpdating from 7.x-2.14 to 7.x-2.15 made block fields no longer visible. The checkbox to respect block visibility is not set.
Applying patch https://www.drupal.org/files/issues/2018-04-23/block-content-fix-2962309... to 2.15 solved the issue.