Thread

Perhaps you’ve wanted global variables that you could use in tag parameters or conditionals, but do not have or desire to use FTP to create path.php global variables.  Or maybe path.php variables are fine, but you need them to hold ExpressionEngine tags or even PHP.  Or you need admins to have access to modify the variables, but don’t want them to have access to the templates.  Or maybe you are using MSM and would like some global variables to be installation-wide.  There are many uses, but this entry doesn’t need to get any more complicated than that, because the module is not a complicated one.  So, taste the freshness, and enjoy: Fresh Variables.

Make sure you read the instructions in the included instructions.html file!

Very nice, looks like I can scrap that module from my ToDo list 😉

Two things I noticed while trying this module:

1) it doesn’t have the look and feel of the other EE modules.
2) it overrides Template Global Variables.

First one isn’t really a problem, but to me it feels out of place (bit like a quick 3rd party mod)
Second is not a problem for me either, I tend to prefix globals with ‘global_’ anyway, but I can see some potential problems here.

Don’t get me wrong, I like it, great addition to the EE add-ons!

Cheers,
Elwin

1) Yes, it was a quick one-off, much like our other free first party add-ons that are not included with the application, hence the simple interface.  It actually began life as an extension only, so it was a simple extension settings form.  The need to allow some member groups access to it without giving them access to the Extension Manager, however, was reason enough to place its back end in the Modules section.

2) Yep, as do path.php global variables, which this emulates.  Both are intentional.

So Derek…I could use a field from a weblog (weblog:entries tag) as a variable, then use that variable as a parameter in a reverse-related entries tag? Can’t currently do that (well maybe with an embed) because of parse order, the related entries are parsed before the weblog:entries tag.

Derek, thanks for clearing that up.

2) might be something to mention on the docs though.
Adding the module to an existing site that uses Template variables, and allowing the client to add “path” like variables that could override them sounds like a lot of fun 😊

I can see many uses for this module, thanks again!

Randy: No, sorry.  Though I was thinking of you when I wrote this, something like that would require some modification of the base application or a specific extension of the weblog module.  I’ll keep it in mind for a rainy day, though.

Victor: Yes, these variables can be used in entries.  This however, doesn’t make any sense to me: {customvariable entry_id="345"}.  What are you intimating would be accomplished by that syntax?

You’re my hero Derek!

If this will do what I think it will. . . . yee ha!

Hmmm….

Like when I’ve wanted to define a date formatting once and use that everywhere?

Thanks, Derek. I was in the habit of putting the site keywords and description in global variables, but I didn’t like that someone had to have access to templates just to update those things if they wanted to. I’m sure I’ll find some clever usage for this!

Victor, you’re looking for a plugin or an extension, not a variable, as you are talking about multiple substitutions as well as processing that needs to occur.  Variables are simple replacements.  And oops, no, of course you can’t use it in weblog entries, I don’t know what I was thinking, except perhaps just wanting to say ‘yes!’ to every question.  Template global variables you can, but these variables are parsed much too early.

Like when I’ve wanted to define a date formatting once and use that everywhere?

Ayep.  And that’s an affirmative yes, unlike the misleading yes I gave Victor a few minutes ago.

No, they will remain dynamic.  If you turn on your Template Parsing Log, you will be able to see the order of things, as well as the list of your new variables, and where they are being parsed.

Ye gods, man.

Merry Christmas to me!!

You just made standardized custom date formatting something I can actually enjoy!

Thank you, thank you, thank you,(ad infinitum)
Philip

Hi Derek and all!!

This sounds like a really great module but I think maybe my mind is missing the point somewhere along the line. It is probably just that I have never had the need for anything like this before but was wondering if someone could possibly post some real life examples of how and more importantly when you would use this module.

I just can’t seem to understand the reason for it at the moment but would love to see where it can be used.

Thanks.

Best wishes,

Mark

This is great Derek, thanks.  Is there any performance gain by using fresh variables instead of an embed, say for a header or a footer or is that not an appropriate use for it?

Mark:  Take Philip and Boyink’s example of a custom format string.  Let’s say you like your dates listed as %F %d, %Y  %h:%i %A.  You could set that to a variable called {date_format}, and then:

{entry_date format="{date_format}"}

Or if you want to use a variable as a tag parameter.  {news_weblogs} could be a list of dozens of weblogs you have on a media site, and perhaps this list even changes or grows regularly.  All of your templates can benefit from this without having to update them as well by using:

{exp:weblog:entries weblog="{news_weblogs}"}

fodney: There’s not going to be an appreciable difference, but there are differences. The main difference Fresh Variables have vs. User-Defined Template Variables in that instance is that they can be made installation wide in the Multiple Site Manager.  The main difference Fresh Variables have over embeds is that the content is actually placed into the template before most of the parsing occurs.  Embedded templates are each parsed on their own.  So a Fresh Variable could not be used to embed a weblog entries tag inside another, for instance, as it would be identical to nesting them in the same template.  The easiest way to think of Fresh Variables is to think of them exactly as you would path.php global variables, except they can hold complex HTML and Javascript, EE tags, and PHP if necessary.