Hi,

Two way :

1/ Scrapbook :
a. Create a block in a scrapbook (dashboard > scrapbook)
b. Rename it, for example "footer"
c. Use this code in your template :


=> This block is share accross all the website : if you edit block in scrapbook, all pages with this block are updated too.


2/ Default block :
a. Go to Dashboard > Pages & Themes > Page Types
b. Click "Defaults" for your template.
c. Edit Area
d. Add block
e. Save

=> Then when you create a new page with this template a default block is created in footer but not share accross all the website.

moosh's response works if you're only concerned with a single block -- but it sounds like you want the entire footer area to be editable, in which case the single-block solution is not ideal.

This is unfortunately the one thing that I've found to be lacking in Concrete5's otherwise excellent editing experience. There are 2 solutions to the problem though, neither of which is perfect but should get you 90% there.

1) Use the Page Defaults as a way to manage the footer content. The drawbacks to this are that it's hard to find (buried deep in the dashboard), there are sometimes problems with it working correctly if you're not logged in as the super-admin, it's a very complicated and confusing UI (lots of buttons and messages that don't actually do anything or give incorrect information and instructions, very difficult to wrap your head around how it all works in terms of putting blocks on child pages via 'Setup on Child Pages' command -- which doesn't always do what you want it to do). Also, page defaults are on a per-page-type basis, so if you have more than 1 or 2 different page types in your theme, it becomes burdensome to maintain. Most importantly, though, any changes you make to the position of blocks in Page Defaults (via the "Move" command) do NOT apply to the child pages, so it often becomes useless in real-world situations.
Can you tell I'm not a big fan of this approach? :)

2) Use one of these 2 free addons:
http://www.concrete5.org/marketplace/addons/scrapbook-display-basic...
http://www.concrete5.org/marketplace/addons/global-areas...

The first one displays all blocks in a global scrapbook. The second one displays all blocks in another area on another page of your site. They have the same effect, just that you go to a different place to edit that "global" content. I personally prefer the "Global Areas" one as I find it easier to explain to end-users. The way I use it is as follows:
* Add the Global Area block to the Page Defaults for every page type. Set it to pull content from the footer area on your site's home page.
* Do a "Setup on Child Pages" from Page Defaults to put this Global Area block on every page of your site *except* the home page
* Now just tell your users to edit the footer on the home page and any changes made there will apply to the entire site.

The only drawback to this approach is that there are some kinds of blocks that don't work correctly with it. The biggies are the form block and the autonav block (in some situations). But these 2 can be addressed -- see my response in this thread for info on how to do that:
http://www.concrete5.org/community/forums/usage/change-positioning-...
But if you just have "straightforward" content in the footer like text and images, then this approach is perfect -- which I think would be the case for most site footers (as opposed to sidebars which generally have autonav listings of pages in the "current" section, which is what doesn't work without the code fix I posted in the link above).

Hope that helps!

-Jordan

Extremely useful information, thanks jordanlev. The 2nd method seems the only logical solution now since the scrapbook got removed from Concrete 5.5+. I'm very surprised a solution such as this isn't part of Concrete 5 as standard as most people will want global areas.

Global areas (that work like regular areas, but are global) have been part of c5 since version 5.5. We also have stacks, the Global Areas block (not the same as above), the Parent Area block, and various stack inclusion blocks.

@Jordan - The latter approach seems the sensible option then..

I thought this would be easier to be honest, surely it's a popular requirement?

Anyway, thanks for your time guys, appreciated..

Yeah... I sometimes feel like I'm in a bizarro-world when I bring this issue up, because there's a very small number of people on the forums who have raised this issue, but to everyone else it's like a bunch of blank stares -- not that they think it's a bad idea but rather that it just has never been an issue for them.

Having built dozens of C5 sites over the past year of varying sizes and budgets, I have a theory on where this matters and where it doesn't -- seems that the agency sites I work on (where there's a professional designer and maybe even someone else to develop and manage the content) don't have this issue, because the design is so highly customized that even the contents of sidebars and footers are planned out ahead of time. On the other hand, sites I've built for individuals and some smaller companies/non-profits where they don't even really know what content will be on the site before it's built out, those are the ones where this becomes an issue (I cringe every time I hear "so I need to move this block that's on the sidebar of 25 pages..." -- ugh).

Probably TMI, but that's my take on it. I think the Global Areas addon pretty much solves this problem -- just need to fix a few things here and there in the core code so all of the blocks work with it (which is happening, so this solution will be even better after the next C5 release).

-Jordan

Must admit I've found this approach in C5 as rather infuriating. It's my first time using Concrete5 and I've not found a clean way of doing this. jordanlev's info is very useful but I expected, given the joys of in context editing everywhere else in C5, this would be possible.

What's needed is a 'Repeatable Area' or similar (I seen to remember MODx having something similar, snippets I think, but I wasn't a fan of many other things in MODx).

What would be great is:

1. define an editable region in the template e.g. notice I'e used 'RepeatableArea' rather than the normal Area.

This same code could be inserted into multiple page templates - any place you'd like the same Repeatable Area to appear.

2. In the Concrete5 edit (frontend) enter the edit mode of any page containing that Repeatable Area, add/edit the Repeatable Area contents and on clicking submit/save it just needs to pop up saying "Please note, updating the content of this area will also update any other page using this same Repeatable Area. Are you sure you wish to save?" If you save, ALL instances of this Repeatable Area are updated.

I think that would solve my problems in this respect. In the meantime I'll have to hard code, use the workarounds jordanlev suggested or use the scrapbook feature. All of which are fine for me but seem a little 'un-C5 like' for the end user where everything else is so wonderfully click and edit...

Great Idea!

This can do pretty much what you are asking for:

(one catch, this is a global "area" but only contains 1 block. If you wanted to have multiple blocks in the area in your template be repeatable throughout the site you will need to repeat this process for each block)

- Create a content or html block in your global scrapbook (can be any block actually)

- Make sure the name of the block has underscores instead of spaces

- Hard code the block into any templates you want

example:


Pros:
- client can still edit the content from the c5 dashboard
- if no global block available the area in template becomes a regular "area" that can have blocks added manually to it (fall back behavior)

Cheers

Quick question on this one - can the client update from the context editing front end this way, or do they need to edit the actual contents in the scrapbook?

has to be done through the scrap book.

To set it up for front-end "in context" editing you should NOT hard code the block into the template as I suggested but instead place the GLOBAL block onto a page default

Goto: dashboard -> Pages and Themes -> Page Types -> "Select page type you want to add default blocks to"

After pressing the 'default' button you are able to edit the page type default page which will be used to create all pages of that type.

The blocks you add to the default will be populated on the new pages you create of that type.

Those blocks are editable from each individual page.

By inserting a GLOBAL block into the page type default your client can edit this block from any of the pages using this page type and those changes will reflect site wide (because it's a global block).

(pretty much what moosh was say'n)

This way is pretty sweet too and maybe even closer to what you are wanting?

This does *NOT* do what the OP asked for -- this is only for hard-coding blocks. The important point here is that it's an entire AREA that needs to be global -- specifically so you can add new blocks, remove existing blocks, and change the order of the blocks around and have that persist to all other pages that the global AREA is in (not just one block). And having several of these blocks doesn't work either because you can't change the order of them (and also you'd have to know what those blocks need to be ahead of time, which kind of defeats the purpose).

The OP just said he wanted his client to be able to edit the "footer text" from the front end on any page and have that carry over to all other pages.

But yeah, the global AREA is a really great idea.

I'm sorry for not being any help :P

Hmm... I see what you mean. I guess it's more that the conversation veered off into the global areas direction. (And also the direction of "most people don't seem to understand this need because they haven't come across it before", so I wanted to clarify it further).

You can do this with another way actually by adding default blocks (scrapbook blocks) for a template.

Hi Moosh,

Sorry, I'm a little wet behind the ears with C5 - could you explain (like, as if you're speaking to a child ;)) in a little more detail how I'd do it that way?

I'm trying to do things in a best practice way on this first site, despite the learning curve so I get into good habits for future C5 based sites.

Thanks - Ben

Once again, this misses the point of what we're talking about here -- we're not concerned with adding single blocks but rather an entire AREA. The user needs to be able to add blocks, remove blocks, and change the order of blocks that are on the pages. Using global scrapbook blocks does *NOT* solve this problem in any way whatsoever.

While I'm glad other people in this thread are assisting with getting this working with existing concrete5, I just wanted to mention that this has been on our list for awhile (well, at least my personal list. ;-) ). Something about the page defaults way of doing has never set right with me, even when we did it way back when. For example, it's currently far more difficult than it needs to be to have a header nav area that has a header nav block in it, and then add something like the eCommerce add-on, which then adds new pages, but obviously without the header nav block in them. Sometimes due to the way that those pages are built, it makes it extremely difficult to actually add content to those areas.

I think the solution is something like what you've identified, although we'll probably go with

<?php

$a = new GlobalArea("Header Nav");
$a->display($c);

?>

all existing Area()'s are still page specific, but global areas are really used only one, universally, across a site. You could edit them from the front-end, treat them like regular areas, but they are universal.

This isn't the easiest thing in the world to implement and make work for all block types, but I wanted to mention that it's definitely on our radar, and we recognize why it's a problem (and as cool as the solutions are in the marketplace that address this, something built-in would be really nice.) I think Jordan actually coded something like this up at one point, but it needs to be baked in even deeper to the core than he was willing to go.

I tried this a while back, check out this thread:
http://www.concrete5.org/community/forums/usage/a-new-approach-to-a...

The problem with it (other than the fact that it doesn't work with certain blocks -- see my comments above) is that you can only edit it from one page, not any page.

wow, you almost got it!
so jordan... now that it's been about year since you worked on the global area experiment are you feeling like doing any more 'baking' ? :)

This may just be one of c5's "blind spots" and, if global areas were figured out, would certainly be intuitive from a user & developer standpoint... holding my breath for global areas

Baking?

Not sure what that means -- well, not in this context anyway ;)

I agree that this is one of c5's blind spots (I call it "the missing piece") -- it's actually the ONLY blind spot in the editing experience as far as I'm concerned.

Anywho, Andrew's response gives me great hope for the future -- it's actually the first time I've seen someone from the core team acknowledge that it's even a problem that needs addressing.

-Jordan

Andrew said: "I think Jordan actually coded something like this up at one point, but it needs to be baked in even deeper to the core than he was willing to go." :D

Oh, I get it :)
Yeah, probably not going to happen -- I have too many other things on my plate, and I've found the "Global Areas" addon to suit my needs so I'm not too motivated to find a fix anymore (on the other hand, I would like to put in some effort to ensure that all kinds of blocks work with that solution -- Andrew already has a fix for autonav in there, for example).

Unless I've missed it in the thread above, I've always thought this was quite easy to do in a template:

In a template file, add this:



This will make an area only editable on the home page, but display on every page.

Works great for sitewide footers or headers. If you add multiple areas like this, you don't need to repeat the whole lot, you just pass in the $colletionc object to your display functions.

This is a good tip – but I don't think it'll work for automated header items in certain blocks. That's one thing we'll address when we bake it into the core. However this definitely works for certain blocks like images, titles, etc... and we've used it on our own sites as well.

It agree it will be great when it's in the core, but for now i'm interested to hear what blocks you have had troubles with using this method.

I've used it for content, autonav, pagelist, html, search and rss blocks without any issues.

What blocks can you think of that might be problematic?

The two kinds of blocks I've found to not work are ones that rely on the "current location" in the sitemap, and ones that have forms.

For example, it doesn't work with autonav if you have it set to show pages at the "current level" (it will show pages at the level of the original page the block was placed on, not the page that's currently being viewed). There's a pretty easy change you can make to the core code to address this (and if I recall, Andrew has integrated that change into the development version so it will be there in the next release as well).

With the "form" block, what happens is the form is posted to a different page. This can be addressed by using the free "Ajax Form" addon in the marketplace. But there are other blocks besides this built-in form block that won't work properly as well (I know off the top of my head that my Email List Signup block doesn't work with this).

I can't comment on the using the form block this way, but for the autonav, I wouldn't expect it to dynamically change depending on what page it is on. The code is asking for the blocks from an area off of the home page, as if they were actually on the home page. This is the behaviour I would expect, at least for the code snippet I posted.

For blocks that are dependant on the particular page, I think that's where page type defaults and setting up on child page feature comes into play.

Some might disagree, but I see the task of setting up 'global' areas the task of the theme/site developer, and not generally the end user/client, so for me it makes sense for the developer to determine what should be coded in the template and what should be set up as a page type default block. I've found that sub-navs tend not to be edited once in place, while clients often want control of the footer.

For the OP's original question, I'm fairly certain the snippet I posted will do what they want - provide an area for a footer that will be editable in one spot but displayed across all pages exactly the same.

I love the fact everyone has ideas about this though, shows that the community has high standards and doesn't want to settle for cheap hacks!

Is it possible to have this area editable on all pages (not only home page) while being displayed on all of them ??

No, unfortunately not. I recommend using the free "Global Areas" addon which is a more robust approach than the code @mesuva posted above, and it also displays a message telling you which page you need to edit the global content from:
http://concrete5.org/marketplace/addons/global-areas...

My thoughts on this topic + info on global areas from a different CMS (gasp!):

1. I agree with Jordan + company about making certain areas global is a real challenge & needs some TLC.
2. We have to think though, is adding a new snippet of code the best way to address this? Seems like an option on the flyout menu (http://www.concrete5.org/download_file/-/view_inline/14098/... ) of an editable region could be a better solution (that way people would choose what blocks they want global and could still have the ability to switch things up on other pages if they need to).
3. Case study:

Another CMS that I work with handles this in a similar way. Basically, the user enters content into a editable region. Then, if they want to make that region "global", they hit a heart icon (see attached images). Afterwards, that content is default to every region with the same name (eg if each page template has an editable region named "Contact", all of the "Contact" editable regions display the same content--regardless of page type.

Then, on pages other than where the user originally entered the content, the region appears grey with a message, "Please visit the XYZ Page to edit this content". Obviously, XYZ Page is a link to that particular page (this may not be the cleanest solution, but it gets the point across).

Overall, we've never had anyone that was totally bewildered by this method of global content areas. People seem to get it. We've never had anyone complain about it being too easy to make content global either (if someone de-globalizes the region, the content that was originally on each page shows back up).

More deets there:http://slatecms.wvu.edu/screenshots?set=72157600011276649...


So, a few questions:

What do you think of adding "Make this block a global area" to the context/flyout menu?

Should we add another code snippet that people have to learn?

What if we DO change the snippet to what Andrew suggested, and someone wants to add something to that region that is not global? (devils advocate here ;-)

My .02 cents.

This makes sense to me. It probably wouldn't be that hard to do, either. Underlying fuctionality would be the same - it would just all an admin to choose through the GUI.

Sent from my iPhone

Hey Adam,
I think this is great that you're bringing up alternate options for the implementation of this. I like the idea of keeping things more flexible in theory, but I'm not sure how this would work out in practice. Seems to me that basically what you're describing is how Page Defaults already work -- you have default blocks and you can do the "Setup on Child Pages" to put them on other pages, and you can override those on individual pages. But there's no functionality available to rearrange the blocks, and in discussions with Franz it became clear that this is because there are so many different configuration possibilities that it would be impossible to make it work sanely -- for example, what if you move a block in a global area to a different position in that area, then on other pages there's different block orders or different blocks entirely -- how do you know where to put it?

In my humble opinion, the method of putting a special "Global Area" in your page type template is a better solution overall because it's much simpler and easy to wrap your head around. It's just very straightforward and relatively easy to implement in the system (I tried once to improve the Page Defaults so that blocks could be re-ordered, and I soon realized that due to the architecture of C5 it's a *very* complicated job).
I understand though that sometimes you want that area's content to be different than the global content, and what I've done in this situation is to create 2 page types -- one with the global area and one without -- so users can flip the page type to turn the global thing on or off. Obviously that won't work well if you have a lot of different page types in your site, but worked great for a site I did that really only had one page layout for the entire site (just a right sidebar basically).

Jordan, you bring up some valid points. I also like what @Mesuva said. Something to the effect of, "The site admin usually sets up the global areas and they seem to rarely change."

Having a snippet that would make an area a global area is definitely the most straightforward (although, one more thing to remember for newbs). And, if you needed something on a per page basis, you could just add a regular editable region/block area directly below/above the global one.

I should say that the CMS I mentioned above does have the ability to "Revert to a normal content area" where that area would be excluded from the global area & have it's own page-specific content.

I suppose I am on the fence about which way to make this happen (not very helpful I know). Seems like both approaches would work well. Maybe either way this issue unfolds, someone could create an add on to account for the other side of the fence ;-) I know, a lot easier said than done.

What do other people think?

For my current needs, the ability to define Gloabl Areas in a template would be great. To my mind the other solutions are a bit of a semantic kludge. Where I want to provide the ability to do something a little bit different on individual pages, I could extend the template to put a regular Area above or below any Gloabl Area, so that blocks can be prepended/appended by using the regular Areas on individual pages. I just think of it at it as a more flexible solution but similar to coding blocks directly into the template.

Hello. WTF? Seriously? There's no "global header" option in Concrete5? Nope. Just go create new header for every single page in your site.

OoO

SO, all us nerds are sitting around trying to figure out the best way to have ONE header and ONE footer for a website?

Really?

Really??

:D

By the way, hi everyone!

Well, there are various ways of doing it, but none of them are called "global header".

The best way I've found is to get the free "Global Areas" addon from the marketplace, add a global area block to the Page Defaults and point it to the home page. Then the home page header (or sidebar or footer or whatever) becomes the "global header" -- edit it there and it will automatically update all across the site.

But if you're a web designer/developer building a site for someone else to manage, this probably isn't the best approach -- instead there are various other options like hardcoding things into the page type templates and putting in global scrapbook blocks. The point is if you're designing and building a site for someone else then it's likely you want to lock down those global headers/footers more and intentionally prevent users from editing them too much (in other other words, you want them to be able to edit content that's already there but probably not change the layout of it or shuffle the order of things around).

But if you're not a web designer/developer and you're just building a site for yourself or your organization, then the "Global Areas" addon method I mention above is probably your best bet.

-Jordan

PS - Concrete5 is an open source project, is still relatively new, and is continually improving and growing. As you can tell by this thread the community is still trying to figure out how to set this stuff up and then how to get it built -- so it's not a situation where someone sat around and said "I want to intentionally make this hard for people to use" -- it's just that there are so many things to do and only so many people helping out that not everything has been done yet.

Thank you for Global Areas suggestion. Quick and easy - perfect solution. Just as easy as adding an include to an html page.

Loving Concrete5!

Hey Adam, I just had an idea based on the concept of combining the global area "snippet" with the ability to put blocks into said area and override the global behavior on a per block basis.

- So we code the global area into the page template.
- User adds blocks to this area on any page and area is updated site wide.
- Page specific content: user adds a block and then through the blocks editing interface can select to make this block page specific, effectively overriding the global area.
- The global area code checks the global areas for all blocks without the page specific override.
- When a previously global block is set to be page specific the global area needs to be smart enough to leave this block on this particular page alone without re-adding the global version of the block (which is site-wide in the global area).

So there would have to be a way to add an option to the blocks GUI when placed in a global area in order to override the default global area behavior.

Just an idea that might help form a solid vision for this whole global area thing :)

I like that idea. Thanks for sharing. Easier said than done though ;-)

haha good point... isn't everything easier said than done?