Site-wide content - a manageable approach

Hello,

I've been reading about how to organise content that would appear throughout a site, such as in a sidebar, footer etc. In my case I want a way for the editors to be able to edit contact details, that will always appear in the footer.

The technique should ideally adhere to the following:

1. The content editors mustn't have to touch any code (other than perhaps entering a URL) - i.e. not a chunk,
2. The method of retrieving the data and inserting it to the footer should be efficient

At the moment my approach would be to create a resource called something like "general site data", in which there would be the necessary TVs to hold the data, along with any other site-wide info that might be required.

From what I've read, I could then create a TV that's accessible by all other templates and use an @DOCUMENT (now called @RESOURCE, I believe?) binding, to reference the general site data. However, wouldn't this also gather all other data from the resource, not just the footer info? My other concern is that it appears quite long-winded; a document referencing a TV referencing a document referencing a TV.

Instead, would it be a good idea to use an @SELECT binding to gather results from the db - or would this require a significant amount of data formatting, offsetting its directness with excessive data manipulation?

Any other techniques or suggestions would be very gratefully considered.

Chris

Greetings Chris,

Check out the extra "ClientConfig" -- suspect it'll do just what you want. Works very well for me. Big pat on the back to MarkH for its creation.

http://rtfm.modx.com/extras/revo/clientconfig

Hi,

Thanks for the suggestion - it looks promising. I've followed the tutorial so far and set up a basic setting, but it's not clear how to set the an input type and dictate formatting. As far as I can tell, I'd have to rely on the content editors to know how to correctly format a <ul> and all corresponding child elements. This is elementary stuff to you and I, but not necessarily for the intended user.

Could you offer any guidance on this?

Edit: I'd also like to offer the client the ability to add/remove items as they wish - I think this is vital when considering something like a list of social media links. [ed. note: chr.s last edited this post 12 years, 6 months ago.]

Hello Chris,

Quote from: chr.s at Mar 13, 2014, 01:47 PM

...how to set the an input type and dictate formatting. As far as I can tell, I'd have to rely on the content editors to know how to correctly format a <ul> and all corresponding child elements

I've not had need for it, so can't assert that it'll work for sure, but you could set "Field type" for the applicable field to "Rich Text". It should -- again, untested -- then fire up whatever rich text editor you have set for the site.

If that doesn't work, there are other ways. For instance, on some installations, I've also created hidden (no-search, not-on-menu) resource documents that are strictly used to contain & easily edit common content, then inserted the common content into the template via the getResourceField (http://rtfm.modx.com/extras/revo/getresourcefield) snippet.

you would create a setting for each client-field and a chunk for your footer with something like that:



The Client just needs to fill out the fields within the clientConfig - CMP

The same could be done with your origin idea with the Setting - Resource.
You can get a processed footer-chunk for example with getResources

Thanks to you both for the replies.

you could set "Field type" for the applicable field to "Rich Text". It should -- again, untested -- then fire up whatever rich text editor you have set for the site.

This works exactly as you assumed it would - my only concern is that it's not quite foolproof enough. I've worked with content editors before who simply can't/won't follow rudimentary guidelines for formatting richtext; and then wonder why their site doesn't work properly.

@Bruno - this would appear to be much closer to what I'm after. I still wonder about its efficiency, but in the absence of a quicker alternative, I'm more than happy with this approach so far. For your help so far, and MIGX invention, I'll definitely be buying you a well deserved beer soon.