Moving blocks on Page Defaults not updating on pages
Permalink 1 user found helpful
Just ran into this on a new install of 5.2.1 - not sure if anyone else has had this problem: When moving a block above another block in Page Defaults it saves the positioning correctly within the Page Default, but it doesnt move on all the pages. I even updated both blocks to "setup on all child pages" and cleared the site cache and tried it again. Still no luck. Any ideas?
just added this to bugs.
the pagetype default doesn't "know" the block order of each area collection by default, so it appends to the "end" of the area in the collection that the pagetype you updated is associated with.
Should it? Sure. There are functions to get all blocks in an area in a collection, so to index that wouldn't be a big deal, but this also assumes that you want this block to be at x position in an area in all collections that use this pagetype as a view. It seems easy, maybe allow to append to top or something, but the positioning of the pagetype default IE in the pagetype this is index [1] on main_content so make that on all pagetypes wouldn't work and would require manual intervention regardless. You can only hope for a best case guess at where the block can be, either "top" or current "bottom"
I think "move to top" is valid ie insert at top instead of just the "bottom", but auto-magic won't work.
Should it? Sure. There are functions to get all blocks in an area in a collection, so to index that wouldn't be a big deal, but this also assumes that you want this block to be at x position in an area in all collections that use this pagetype as a view. It seems easy, maybe allow to append to top or something, but the positioning of the pagetype default IE in the pagetype this is index [1] on main_content so make that on all pagetypes wouldn't work and would require manual intervention regardless. You can only hope for a best case guess at where the block can be, either "top" or current "bottom"
I think "move to top" is valid ie insert at top instead of just the "bottom", but auto-magic won't work.
more of a feature request..
I like the idea of adding a "bounce to top" command to the move interface..somehow..not sure how...
but yes, you've got the one sort array at default level, and then you've got the real sort array at page instance level.. how to merge the two is gonna be a very real problem with no "correct" answer
I like the idea of adding a "bounce to top" command to the move interface..somehow..not sure how...
but yes, you've got the one sort array at default level, and then you've got the real sort array at page instance level.. how to merge the two is gonna be a very real problem with no "correct" answer
I was having the same issue.
Luckily, I only had three blocks for which I wanted to change the default block order so I deleted them all and re-added them in the right order, and then added their content which I had previously saved.
Next time, I'll pay attention to the original block order when I make a page type.
Luckily, I only had three blocks for which I wanted to change the default block order so I deleted them all and re-added them in the right order, and then added their content which I had previously saved.
Next time, I'll pay attention to the original block order when I make a page type.
I just recently came across the issue as described here. I found this thread, which is more than one and a half years old now, by using the search before posting.
Actually i find this behaviour quite irritating. By playing around with blocks in page type defaults on a test site i ran into problems, where even removing all blocks in page type defaults did not remove them in any of the pages using this page type.
I think this is more than just a feature request, it's a problem, that is still not solved, and i find this much more important as it is regarded in the statements above. It means that every change made by moving blocks to the page type defaults works only for newly created pages and has to be applied manually for all existing pages...
Actually i find this behaviour quite irritating. By playing around with blocks in page type defaults on a test site i ran into problems, where even removing all blocks in page type defaults did not remove them in any of the pages using this page type.
I think this is more than just a feature request, it's a problem, that is still not solved, and i find this much more important as it is regarded in the statements above. It means that every change made by moving blocks to the page type defaults works only for newly created pages and has to be applied manually for all existing pages...
I absolutely agree that this is a necessity and more important than just a feature request.
The best work-around I have found is to:
1) save all blocks in the area to the clipboard
2) in page type defaults, delete all blocks from the area (including child pages)
3)Re-insert blocks from clipboard into page type default, and apply to child pages
That beats reordering blocks for 300+ pages by hand, but its still pretty ridiculous.
The best work-around I have found is to:
1) save all blocks in the area to the clipboard
2) in page type defaults, delete all blocks from the area (including child pages)
3)Re-insert blocks from clipboard into page type default, and apply to child pages
That beats reordering blocks for 300+ pages by hand, but its still pretty ridiculous.
I just found out, that, after having moved blocks on a page type default, deselecting all child pages, confirming that, and then reselecting all child pages again, helps to get these changes applied to all existing pages, exept for those, where changes to the order of blocks previously have been made.
Yes, I see now that the blocks don't have to deleted at all in step 2 above; they just have to be removed from their child pages and re-applied. Thanks, maybe it's a pretty good solution after all.
Thanks, just stumbled over the same problem and also this old thread. I thought it's a bug. Well, glad it's not such a big problem with deselecting and selecting again.
i wonder if someone has some modification to this, so there no need to "deselect an selecting" again the block.
example, if you have 300 pages with 5 block in sidebar area, it's sure hard to maintenance them for re-ordering.
it's good if there is feature hide/visible block, i will try add 1 field in block table :)
example, if you have 300 pages with 5 block in sidebar area, it's sure hard to maintenance them for re-ordering.
it's good if there is feature hide/visible block, i will try add 1 field in block table :)
Bah... this is one of the things which is a complete time waster. Don't get it. Please fix that!
i mean, if the block is aliased from the defaults to many subpages, its pretty easy to make sure the single instance gets changed on edit mode..
what do we do about sort order from defaults on page instances when those instances have their own blocks added to the area??