Make template variable changes apply to all pages

Hi,

I hope this isn’t a repost, but I’ve been unable to find out how to do this after weeks of searching. I have a client who would like to edit an area of the page, so I set up a template variable for it. This works, except the area must be changed on every page of the site, and this isn’t something the client has time to do.

Is it possible to have a template variable that is the same on every page and can therefore be changed once? The client is not confident enough to go through the admin area and edit a chunk.

Thanks in advance,

Don

If you set a default value for the Template Variable it should carry over to all templates the variable is assigned to.

Thanks for the reply, but the issue isn’t the default value. When the client changes the content through the front end of the site, the edit only applies to the one page editted.

I tried putting the snippet getField onto a second template and applying it to the other pages, but I can’t seem to get the getField snippet to output anything.

I am confused why something so fundamental would be omitted in this CMS.

That is the way template variables work.  QuickEdit does not provide the ability to edit the default value for template variables from the front-end; the users would have to edit the default value of the template variable in the manager interface.  If it’s something that should be editable site-wide on all pages and always reflect the global value, a Chunk is more appropriate, but is still not editable from QuickEdit.

Also note, QuickEdit is an add-on to MODx, so you can extend it to do these things (I’m surprised no has yet TBH).

Thanks for clarifying.

I guess what would be ideal would be to extend QuickEdit to allow tags like {{#content}}, making chunks editable by clients.

Till then, I’ll just have to dream

Quote from: ganeshXL at Sep 08, 2008, 08:41 PM

GetField works fine, maybe you’re just doing it wrong? Make sure to use backticks ` not single quotes ’. Also, remember that snippet names + parameters are case-sensitive. Maybe you used getField instead of GetField? (just some hints)

Also, one of many ways to include some piece of html in another page/template, is with a TV that pulls the content from a document via @DOCUMENT binding.

http://wiki.modxcms.com/index.php?title=%40DOCUMENT_Binding
http://modxcms.com/document-binding.html

So, if you include document 123, just go to index.php?id=123 and you can edit it with QuickEdit just like every other regular page. Just make sure it doesn’t accidentally turn up in searches or sitemaps. When I do stuff like that, I usually keep all those special documents in a separate folder, so they’re easier to find + exclude with WF/Ditto etc.

Nice tip ganeshXL!

Quote from: Breezer at Sep 08, 2008, 07:08 PM

If you set a default value for the Template Variable it should carry over to all templates the variable is assigned to.

Hi Breezer -

For me this isn’t working.  I have set a default value for a template variable that is "@DOCUMENT 142."  This is so the client has an easy time editing the short block of content by just editing the stated document.

Then I activated this TV so that it should appear on every page sitewide in the sidebar. 

Looked great when I applied this to existing documents. 

But when we make edits to a document and resave it, instead of parsing the binding @DOCUMENT 142 and retreiving the content from doc 142, it doesn’t parse/process and on our website it just shows "@DOCUMENT 142" as plain text.

Any thoughts?


Edit:

1.) I found another thread that deals with this same issue or similar. Is this a bug?
http://modxcms.com/forums/index.php?topic=25453.0


2.) Here are the instructions for using @DOCUMENT the way that I did it -- seems like I followed all the steps...
http://modxcms.com/forums/index.php/topic,27428.msg166594.html#msg166594


3.) If there’s no other solution, this seems to be a snippet-based workaround (but a pain) ---
http://modxcms.com/forums/index.php?topic=26866.0

What version of modx release are you running. I just tested this in the latest version and had no problems with the @DOCUMENT biding. I have noticed this sort of behavior before when using the @CHUNK binding in a project a while back but have not noticed it recently. I am guessing that it is somehow related to the cache, so maybe try changing the cacheable settings for the documents as a test.

Apparently what you have done, should work fine. Make sure that you aren’t using RTE on that particular TV.

I added these instructions to the wiki and made a note about the RTE issue that was the problem.