Including standard content

Permalink
Is there a way to specify a block of content and then have that block included by reference on multiple pages? For example, if I have a footer I'd like to include on all my pages, but only edit it in one spot.

I can get it to show up on all pages using the Page Type defaults and adding it there, but that only works for pages created after the block is added to the page type, and it also doesn't propagate changes to pages using that page type.

This seems like a critical piece, but I can't find a way to do it. Any help?

jinglesthula
 
Remo replied on at Permalink Reply
Remo
I started a discussion about the same problem on sourceforge a while ago..

Unfortunately there's not such way at the moment. The only thing you can do, is to create an element in your theme that contains the content of the footer.
This would of course mean, that you have to update that file (using ssh, ftp or whatever)
andrew replied on at Permalink Reply
andrew
It's just not very clear.

Once you add it to "defaults", click on the block you just added. You should see "Setup on Child Pages" as an option.

If you select this you should see a list of all pages in your site that share this page type. Then there are check boxes that show which pages of this type this block shows up on. If you _just_ added this block then it probably won't be on any of them. Select all the pages using the check box in the header, or select individual pages, and click save. The block should then be aliased out to those pages.

Changing the block in the "defaults" section should then propagate its changes out to all the ones you've selected (as well as automatically be added to new pages of that type.) If you change the block on any of the child pages, it'll override those settings and create a new instance of the block.
Remo replied on at Permalink Reply
Remo
isn't that action restricted to the admin?

I don't want to let my users have access to all dashboard options...

I think there are easier ways to achieve that. At least, you wrote that the idea of this feature is interesting ;-)
http://sourceforge.net/forum/message.php?msg_id=5052582...
andrew replied on at Permalink Reply
andrew
I think I may have misunderstood you. Yeah, we're using elements at this point to do what you're describing and it seems to work decently. I've just come across a number of people who don't know that you can setup blocks to be inherited across page types.
jinglesthula replied on at Permalink Reply
jinglesthula
Ok, this looks like it will work for me. I'm okay with it overwriting, since I'll likely only be using it for footer (and maybe custom nav that autonav won't work for).

In looking into the 'how to create your own blocks' section in the dev docs I noticed that it requires all tables specified in a block's controller to have bID, which would imply that you can't really specify a table that's shared among blocks of the same class but whose records are block-instance independent. That's what I'd envisioned with this type of block. The blocks editor would contain:
- dropdown for selecting an existing content piece
- button to use the selected piece as the include content for the block
- button to delete the selected content piece
- button to create new content piece (w/ name textbox) which adds the new piece to the list
- button to edit the selected content piece (loads into the rich text editor w/ save button)

But a better way might be adding an Includes tab to the C5 dashboard and putting user/group privileges on individual include pieces. The editing of the content would take place in the dashboard, and the Include block editor would then be a simple dropdown.

For now I'll use the methods you've given, but I really think this would be handy for people who need to grant non-admin users the ability to edit 'included' content on pages. DRY content and all that. Thanks much, by the by, for the quick and helpful responses.
frz replied on at Permalink Reply
frz
play with the scrapbook, it will save you time and is often overlooked.. won't help with giving people parts of a site to manage on their own, but is nice for quickly making massive changes.

check out wizards. Andy might step in and tell me, "actually thats completely gone" but in the previous version of concrete we had a way to turn "wizard" permission on for a particular user or user group, and then a separate set of php files would be called for edit mode on that page if you we're logged in for that user. This is how sites like Indie911.com or SchoolPulse.com have super simple to understand form based UI for their user base, but also in-context editing for their admins.

I would love to understand the specifics of your challenge better, I'm always afraid of architecture getting out of control and ending up being confusing and overwhelming for everyone..
andrew replied on at Permalink Reply
andrew
Sadly, I'm about to step in and tell you that that's completely gone, since nobody really understood it and it was often more trouble than it was worth.

In its place we have a pretty solid actual MVC-style framework that makes building forms and special apps much easier.
jinglesthula replied on at Permalink Reply
jinglesthula
In testing out the 'set up on child pages' feature I tried changing an image block on one of my page types.

I edited the block, clearing the image and selecting a new one. After saving the block I used the 'set up on child pages' and selected all pages on the site. In viewing the site it appears that a new block was added, rather than changing the old one, so that both images appear.

Is there a way to just edit rather than adding, and is there a way to remove a block on the page type defaults and have the delete action propagated?
jinglesthula replied on at Permalink Reply
jinglesthula
On further inspection it appears that the checkboxes on the 'set up on child pages' toggles the inclusion of the block on child pages. But it would be nice to remove a block entirely from the page type and have that propagated.
tsidell replied on at Permalink Reply
Im sorry this might look like a dead issue but I was curious. Andrews first post said to add the block to "defaults". Where would I find defaults?
LucasAnderson replied on at Permalink Reply
LucasAnderson
If you login to your dashboard and then click the link on the left toolbar for Page Types, there is a Defaults button next to the specific page type your are going to be adding default blocks.

This opens a 'master' template in which anything added to it gets automatically added later on when a new page is created using that Page Type.
tsidell replied on at Permalink Reply
Thanks LucasAnderson that definitely helped
frz replied on at Permalink Reply
frz
http://www.concrete5.org/help/faq/i_want_to_share_content_across_multiple_pages_
tsidell replied on at Permalink Reply
Yeah i realized that the second after I sent out the message. Thanks.
LucasAnderson replied on at Permalink Reply
LucasAnderson
While you are editing Page Defaults, when you click on a block that you just added to the master template, there should be an option to 'Setup on Child Pages'

This will give you a list of pages that use that specific Page Type. Check all the ones you want to add this block to, then click Update.
Jsn replied on at Permalink Reply
Jsn
I'm sorry to say that I can't find the reference to "Child Pages" on any of the commands attached to a block, and I've been searching for quite a while. I'm in the Defaults mode of the page type, but no go.

What am I missing?
frz replied on at Permalink Reply 1 Attachment
frz
not here?

(see attached)
Jsn replied on at Permalink Reply
Jsn
That command is definitely missing from my equivalent menu. Interesting. I'm using Safari, by the way.

Thanks for the follow-up, though.
Remo replied on at Permalink Reply
Remo
..for me..

and all the other webkit browsers.

what version are you using?
admin user?
Jsn replied on at Permalink Reply
Jsn
Just to make sure I wasn't hallucinating, I made absolutely sure that command wasn't being displayed. And it wasn't--not on Safari, not on Firefox.

So, I did a clean reinstall. Now it's there. Go figure. Perhaps it was some farfiddle in the permissions schema.