'Setup on Child Pages' Error

Permalink
Short:
Setup on Child Pages shows block enabled for pages, although it is not displaying on them. Trying to disable it for those pages results in blank screen. Ideas?

Details:
I have 2 blocks setup in Defaults for my page type. At any given time my site only displays one of the two blocks, so I use Set on Child Pages to set one for all pages and remove the other from all pages.

Nice.

Until, I go in to the currently unset block and the checkboxes are all selected (but the block isn't displaying on the site).

I try turning them unselecting them, but when i click Update the page goes blank.

I then noticed another block that I had previously deselected from all child pages, still had some pages selected. Trying to deselect those results in the same blank page.

I'm wondering if this has something to do with the version of the pages when I add a block to child pages vs. when i remove the block from them?

Is there a way to get set on child pages to behave a little better?

marcM
 
frz replied on at Permalink Reply
frz
maybe i'm miss-reading your post, but the interface there isn't choosing which block is active, its actually copying that block out to existing copies of the page.

that make any sense or are we passing in the digital divide..

uh.. turning off a checkbox and hitting update from there just means you aren't copying that block to the block area on those pages right now..
marcM replied on at Permalink Reply
marcM
just played around with this a little more and still not understanding something. maybe this will help close the divide...

Here's what i did.
- goto Page Types | Defaults
- add a content block (defBlock1)
- exit edit mode & back to dashboard

- add a new page (page1)

page1 is automatically set as child of defBlock1

- edit & publish page1 by adding a new content block

- back to Page Types | Defaults
- defBlock1 | Setup on child pages | deselect page1 | Update
- defBlock1 | Setup on child pages

page1 still shows selected. although goto page1 and defBlock1 is actually gone, as expected.

at this point if i again
- defBlock1 | Setup on child pages | deselect page1 | Update

i get a blank page. and i cannot select page1 again as a child for defBlock1.

once i deselected page1 as a child shouldn't the checkbox stay off so i can select it again later if needed?

(note: seems to only happen when i edit page1 before removing it as selected child)
frz replied on at Permalink Reply
frz
I dont think child is the right term here.

Page defaults sets up blocks that will be copied or aliased to the pages you make following that type.

If you edit the block set by the defaults UI from the page you made, you are creating an instance of it specific to that page.

When you use the setup on child pages UI, you are basically getting a UI to add an aliased instance of the block to all the children you choose. The setup on child pages UI isn't a set of flags your turning stuff on and on with, its a bulk copy tool...

I'll have Andy verify I'm not remembering this wrong, but I believe this is how it works.
andrew replied on at Permalink Reply
andrew
Franz, your description of defaults and the blocks on them and how they propagate is correct.

Marc - thanks for taking the time to describe what you're doing and what you're seeing. You've found a bug! Yes, right now there appears to be a bug in the method that is run to determine whether that "defaults" checkbox in the dialog box should be on for a particular instance of the page. In many cases it should not be on, but it is on anyway. Since the system thinks it should be on, and then you uncheck it, it tries to remove the block from the page. However, the block isn't actually on the page (as you've described) and that white screen is actually an error in the deleteBlock method that happens under these circumstances.

I've fixed this bug in svn and it should be released in our next release (very soon.)
marcM replied on at Permalink Reply
marcM
I will definitely test that out when it's released. Thanks guys!
accountnotinuse replied on at Permalink Reply
Many thanks Andrew your fix works perfectly.

Any beta developers with svn access, revno 1005 and 1006 fixes this bug.

Thanks,
RobertJNL replied on at Permalink Reply
RobertJNL
I have had the same problem for a while and been checking/testing/forum posting etc..

Franz mentioned this topic to me and I've downloaded the beta. I am overjoyed with this fix.

(80 pages, 12 page types, 14 blocks on each pagetype, lots of cross-referencing)

Thank you Concrete Team, you've made my day, ehm, month! :) Whooohooooo