One single Block editable from all pages
Permalink 1 user found helpful
Hello,
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?
Hauke
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?
Hauke
I agree that it should have something like this.
You've got the image slideshow in page defaults.
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?
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?
As far as I understood the scrapbook, this would work like the following:
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?"
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?"
okay i see what you're saying..
yes, i understand the extra work...
two thoughts.
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...
thx
-frz
yes, i understand the extra work...
two thoughts.
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...
thx
-frz
I've got an idea, let me know what you think about this.
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!
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!
I'll paypal you a beer or four.
I'm a bit busy but I guess I could need such a block too.. Might take a while but I think I'll implement that..
Hey real beer tastes better than paypal beer ;-)
Hey real beer tastes better than paypal beer ;-)
we have an ad block we've only partially ported over to v5...
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...
no?
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...
no?
When in page edit mode ideally or edit mode for the global block, I would expect the block to have a visually different "effect" around it that signifies that the block is a common shared content block and be able to maybe even see how many times it is being used.
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 :)
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 agree.. This could get messy but on the other hand if you start working like that it should be okay.
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...
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...
I like Remo's idea of a type of cross-linking area block, that can pull a areas/blocks from another page. We do this kind of thing all the time at the code level, where we grab an area's contents from one page and output it on a new page. The default page type approach is ok, though a bit buried for people that don't know it's available... but I can see the desire for something like this. It wouldn't require any changes to the core, and probably shouldn't be a default block, but it would definitely come in handy in some situations.
I think the duplicate areas or blocks would be a great thing to have, as I have stated earlier.
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?
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?
How about having a hierarchy of PageTypes. They do this in Umbraco very well.
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.
Pete
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.
Pete
I like the idea of something like a pageType hierarchy. If i understand it, it would solve the problem i just posted here:
http://www.concrete5.org/index.php?cID=576...
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?
-tmcguire47
http://www.concrete5.org/index.php?cID=576...
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?
-tmcguire47
something we're working on with the upcoming release of 5.3:
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.
Coming soon.
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.
Coming soon.
this will be very powerful. thanks for the quick update and that just boosted my excitement for 5.3.
thanks!
thanks!
:) works very well in beta.
I finally got around to upgrading one of my sites to 5.3 an I don't see the reusable blocks feature in here. Am I missing something, or was it removed from the final release?
scrapbook in your dashboard.
Didn't notice that. Thanks! This is a most excellent feature!
Hi, Im fairly new to this but running 5.3 and so far so good.
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..
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..
Look at the screencast for the scrapbook and page defaults:
http://vimeo.com/3023508
http://vimeo.com/3023508
Thats great - appreciate the fast response ;-) I knew I had seen the page somewhere to edit the default but couldnt find it.
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!
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!
I'm just a user like you but completely agree about the second level admin tabs but once you get used to it (and it is only you seeing them) then it's no bother...
have fun
;-P
have fun
;-P
was this removed in the latest release?
I would have found this *before* shotgunning a block onto about 40 pages using the "child" method. <sigh>
This "master scrapbook" aliasing works beautifully.
--Dirk
This "master scrapbook" aliasing works beautifully.
--Dirk
I'm using the latest version of c5, and I tried to use the global block functionality. I copied a block to the Admin scrap book, and then placed a copy of the block in multiple places on my site. Then I edited one of the blocks. However, the edit to one of the copies(aliases) didn't show up on any of the other copies.
Am I missing something?
Am I missing something?
I'm currently running 5.3.1.1, and I believe in this version, you need to create a block in the global Scrapbook within the Dashboard to enable the sharing functionality.
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 :)
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 :)
I am running 5.4.0.5 - I don't see this in either dashboard/scrapbook, or dashboard/pages - Has it been moved/removed in this version?
This is an old thread, but I found another thread with something I think that may work for this case.
The idea was to have the same footer on everypage, and they did it with this code
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...
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...
I need to share blocks just like you, on multiply pages.