When editing a box (or creating a new one) the visibility settings are never saved. Stepping through the save hooks with xdebug it would appear that the visibility values are never passed to the block_save hook and instead are "stomped" by the box_save method.

Shouldn't the box_save method save in addition to the block save for a given box/block?

CommentFileSizeAuthor
#13 1444544-visibility-settings-do-not-save.patch751 bytese2thex

Comments

tirdadc’s picture

tirdadc commented

To be honest, the core block administration is not the best way to leverage Boxes, which work much better through Context UI and with Context in general. I think that's why this is still broken at this point, but we should definitely fix this nonetheless.

mrryanjohnston’s picture

mrryanjohnston commented

I would also like to add that I am unable to delete boxes. I believe it may be related, as it exhibits similar behavior to saving box visibility:

1 Click delete
2 Redirected to the block lists without confirmation message.

tirdadc’s picture

tirdadc commented

Deletion should work following the commits that were made here.

emptyvoid’s picture

emptyvoid commented

Hmm yeah I generally use the box via the Context module too. However I have found that without setting the roles permissions to anon and authenticated the box will never render for users. Maybe this is just a bug with my particular setup. But I always have to add the setting for it to render any block/box.

I'll post more if I deduce anything else and or a patch should I stumped upon a simple solution.

emptyvoid’s picture

emptyvoid commented

So, I'm struggling with getting all of the boxes I have created to be visible to anonymous visitors. When I create a box it is visible to logged in users but not anonymous.

The block visibility settings are being ignored, yet placing a box in a context and not defining any constraints for the box results it he box not appearing for anon users.

Am I missing a permission? In the default block visibility settings fields it states that if no roles are selected then the block will be visible to all users.. However this doesn't appear to be the case.

I don't see any way to link boxes with block settings as blocks use a bid (integer) while boxes use a text string for the name.

Suggestions?

emptyvoid’s picture

emptyvoid commented

Sadly I couldn't find an obvious solution to the problem so I am going to transition all of my boxes to good ole blocks. I guess for now I'll uninstall the module until I can find a resolution to the problem.

Thanks for playing. :)

tirdadc’s picture

tirdadc commented
Status: Active » Postponed (maintainer needs more info)

yet placing a box in a context and not defining any constraints for the box results it he box not appearing for anon users.

Do other elements placed in that context show up as normal for anon users? Does your context have a reaction? And what box type were you creating and placing? Unless it was a custom type that implemented some form of custom access check, this doesn't seem normal at all and boxes render just fine for anon users since they're ultimately processed as blocks, see boxes_block_view().

ptmkenny’s picture

ptmkenny commented
Status: Postponed (maintainer needs more info) » Active

I also have the issue in which block visibility settings do not save. I am running 7.12 with boxes dev (2012-Mar-27). When I go to the block administration page and click configure to configure a custom block, any changes I make to "Region Settings" or "Visibility Settings" are not saved when I click "Save block."

However, I can adjust the placement (region) of the box by dragging and dropping it on the blocks admin page (/admin/structure/block) and then clicking "Save blocks."

Anonymous’s picture

Anonymous (not verified) commented

Same issue here for me as well. Blocks visibility settings do not save for boxes.

himerus’s picture

himerus commented

I'd love to get a fix for this in.

I'm the biggest fan of using context to place most blocks/boxes/whatevers, but I think the case can be made that sometimes you just need a few, simple, exportable blocks, and don't need the complexity of context to implement them.

The visibility settings (per normal blocks) should have the potential to be both saved AND exported IMHO.

jec006’s picture

jec006 commented
Issue tags: +D7 stable release blocker

Tagging as release blocker

e2thex’s picture

e2thex commented
Assigned: Unassigned » e2thex
e2thex’s picture

e2thex commented
Status: Active » Needs review
StatusFileSize
new 1444544-visibility-settings-do-not-save.patch751 bytes

The issue was two two fold.
1. we were removing the normal block save submit handler
2. after adding it back in it was calling block_save which was doing what we had already done in a save handler we are adding, but with out process the additional settings.

so i make sure that we have both submit handlers and removed the hook_block_save

e2thex’s picture

e2thex commented
Status: Needs review » Fixed

commited http://drupal.org/commitlog/commit/13110/705bfd3eeb07239624f7f41a39a430b...

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

likewhoa’s picture

likewhoa commented
Version: 7.x-1.x-dev » 7.x-2.x-dev
Assigned: e2thex » Unassigned
Status: Closed (fixed) » Active

fix in #14 only applies to the 1.x version. This reopening of the issue is for 2.x which is affected by this bug.