One single Block editable from all pages1 user found helpful
I'm using two different templates on my site. Now what I want is to have the same slideshow on every single page. I know I can define Default for page-types, but this would only enable me to edit the slideshow-block for these page-types. E.g, if I want to add a new picture to my site's slideshow, I have to edit all page-type defaults for it to be viewable on my whole site. This means a double of work for me.
Can a block maybe aliased by directly including it into the template's code?
I need to share blocks just like you, on multiply pages.
You can add an image there, updates across the whole site, sounds super...
The complaint is if you need to make the same change on more than one page type, you have to do it again in the second page type?
Have you played with the scrapbook at all?
1. Edit defaults of pagetype 1 and change the slideshow-block here.
2. Copy the slideshow-block to the scrapbook
3. Edit default of all other pagetypes, delete the existing slideshows and reinsert the scrapbook slideshow-block.
So when I have let's say 5 different page types, I need to do step 3 for 5 times, right?
Wouldn't it be easier if there where "global"-blocks? I'm asking 'cause I know my customers: "Why do I need to repeat step 3 for 5 times? Can't this be done all at once when I simply want to add an image to the site's slideshow?"
yes, i understand the extra work...
1) there have been times on sites where we've made a hidden page and dumped some content on it to re-use throughout a site. I don't think i'd call that a "hack" cause it's not changing anything deep, but it is a bit of a site specific work around... You /know/ a certain collection ID exists with a specific block area in it, and you can grab that in a template file..
2) I'd be concerned about adding deeper hooks into the system to alias blocks from one part of the site from another. In fact, we did a lot of this in previous versions of concrete and what would happen is you'd get weird loops and an confusing path to follow - even as a developer... "wait, WHERE is this blocking coming from??.. Woah, i just wanted to change this, why'd all THAT change?".. etc..
that being said, yeah there's potential for that and I can imagine something in the dashboard that might act as a repository of centralized stuff like Ads you'd want to include from anywhere.. I want to be very careful about this because it very quickly starts to feel like thinking in Drupal terms - but we'll keep bringing it up in brainstorming sessions here...
A new block "show area/block".
1. It would basically allow you to select an existing page.
2. After that it would show you a list with all the area's in it
3. In a second drop down you could see all the blocks (problem: they don't have a name, maybe only the block types)
This way I could easily create a page "footer" with an area "Main Content" that contains a "content block".
1. Page: Footer
2. Area: Main Content
3. Type: Content
It's basically what you wrote but maybe a bit easier since it's just click & play ;-)
Thanks for your feedback!
Hey real beer tastes better than paypal beer ;-)
It worked pretty similar except the centralized stuff was in the dashboard.
You can define a new ad group in the dashboard, inside of the ad group you can create multiple ads.
When you later place an ad block on a page, you can pick from a group (it randomizes them on page load) or a specific ad.
This way the ad counts are still centralized and you can change the ad in the dashboard in one place, and everywhere that calls it will be updated..
What I like about it is as a developer, you know where this centralized content is coming from, and it's always one place. My concern about the "Grab something from any collection" approach is while it does sound more flexible I could see it becoming a cross linked mess of stuff before long... If Page A is grabbing a header from page B, and page B is grabbing a sidebar promotion from page A... it's easy to see this becoming a performance nightmare on bigger sites...
The only functionality this would provide is for end users who you don't want getting into the page type. If they want to update a block that has an image that has "15% off" on 20 pages, now wants it to be 16.8% off they would want to do it right there like they do with the rest of the editing of the site, swap the image and call it a day.
As of right now to get a block to change across multiple pages (that I am aware of) is you have to go to dashboard then page types and edit that for the changes to reflect back on all the pages.
edit:off to play with the scrapbook :)
I'm used to have a few "page parts" like header, footer and stuff like that. They reside in a folder "elements". From there I included them..
I don't want to be able to edit the footer on every page.. I never wanted and I still don't want.
When you use such a concept you have to think about it first. What are the elements I really need, where do I have to include them...
But I'm still not really conviced what the best way is. I'm not a huge fan of "Defaults". I guess I prefer to know that a content is fetched rather than duplicated...
Since the function already exists to duplicate a blocks content since it is used in editing, it would seem that it would be beneficial to not have all blocks of this type read and write to the same row of a db, as I originally thought.
DB space is cheap, especially since we aren't on MSSQL where they charge by the lb :)
Later on down the line you can change a field in your block to decouple it from the mirrored collection of duplicate blocks. A save on any of these blocks types should run an additional query that updates the other blocks fields if they are still in a shared mirrored collection.
Does this make sense? Beneficial?
With respect to this discussion on shared blocks, a PageType hierarchy could allow you to specify Defaults at the base PageType level that would filter down to all its children.
Haute's problem would then be solved by changing the block in the base PageType's default.
This solution provides a number of other tidy bits. In Umbraco you can inherit what page attributes are available from the base PageType. I think that in C5 you just select which of the global attributes you wish to use on that PageType, but with a PageType hierarchy you could have much more control and not have all these many global attributes kicking around.
What do you think? Quite a lot of work would be required but it should be fairly backward compatible.
basically, that once you use the page type defaults, future changes to the existing blocks replicate down to pages created after the edit, but additions of new blocks to the page type default have no impact on existing pages. So a hierarchy may fix that, right?
For the posted question at the top of this entry, what about a header/footer-less simple page type. Create several that represent the pieces you would use to build out another page. Then use something like the iframe add-on to go and grab those individual pages and place them around a normal template page. so, if there were a block-type with auto growth, the content of which would come from a different page, that wouldn't have a frame (would behave like other blocks), that would be cool, right?
A re-usable block section in pages in dashboard.
You can place any type of block you want on this page, and you can grant permissions based access to the page and blocks on it (unlike defaults which is hard coded to only use Admin for security reasons).
You then have access to these blocks from your Scrapbook when adding a block.
When you add one of these blocks from your scrapbook to a instance of a page, you are actually creating an alias - not a new copy.
You can also place these on Defaults the same way you would any other block..
What does this mean?
You might create a "what's hot" block in the re-usable blocks section, place it on some Defaults for page types, remove it from some specific page instances like Contact Us, and then grant permissions to edit what's hot to the marketing department without having to give them the root admin account.
I'm sure you can see all sorts of other exciting uses for this many to many type relationship as well.
So the Global Block feature is very useful - basically emulates a "php include" if you were building a site native.
My question is, how can I add a global block to a page template so that when I add a new page based on that template my bocks are already preloaded into the page?
At the moment Im having to manually add all the global blocks to the page each time which is a bit of a pain :-(
Any pointers much appreciated! Thanks..
As a minor observation, in the back end admin the left hand options are super clear but its actually quite easy to miss that there is a top navigation also.
I think the buttons would stand out better if the selected one was higher contrast? Its also white text on grey BG which isnt ideal..
See attached to illustrate what I mean.
Otherwise great work - am loving the system!
This "master scrapbook" aliasing works beautifully.
Am I missing something?
So in your case, you would have to delete all the blocks on the various pages. Then recreate one block on the Scrapbook in the Dashboard (be sure to click the Global tab). Finally, add this new block from the global Scrapbook to all your pages.
I believe that should work :)
The idea was to have the same footer on everypage, and they did it with this code
<?php $global_footer = Page::getByID(1); $ah = new Area('PiePagina'); $ah->setBlockLimit(1); // this is optional $ah->display($global_footer);?>
This way, you just can edit the area on the page thas has an ID of 1 (ussually the home page) and on every other page that has that template the contents will be the same.
Hope that works...