How to load templates with theme variables?

Hi, I am wondering how best to load L&L templates that set theme variables and are not directly rendered on the page, E.g. design elements and copy snippets. These templates must load before all other L&L templates. I assume the best place is inside the HTML <head> or is that too soon?

Potential solutions:

  • Load the template in the head with PHP
  • Use Elementor’s custom code feature. This can position the code in the head but I can’t see a way to make it process a L&L template.

I do have a working solution of simply positioning the templates at the top of the Elementor header but this seems a bit hacky.

Appreciate any recommendations you may have.


Hey Phil, that’s an interesting idea. I think the most efficient way to achieve what you’re trying to do is probably to load the template with PHP.

If you were wanting to approach this fully within L&L, I think the way I’d do that would be to just have a little conditional that checks whether a certain variable already exists in any of the templates that require the variable. If the variable doesn’t exist, it runs the template that creates that variable. Something like this:

<If check="{Get local=some_variable}" not_exists>
  <Template id=12345 />

You could put this same bit of markup in multiple templates and since the conditional logic would only be true the first time one of the templates ran, it would have a minimal impact on the overall load time of your page.

Even more efficient than this would be if you know which template is going to be the first to load on your page and you can just run the template that sets the variables once without needing to use conditional logic to check whether the variable exists.

Regarding Elementor’s custom code feature, you’re right that L&L needs to be written inside a template and other code widgets like that one won’t know how to render L&L markup.

That’s my two cents, I’d be curious to find out what approach you end up taking!

1 Like

Hey @benjamin, thanks for the info.

I should clarify that for my theme elements (titles, meta, buttons etc.) I am using the Template Variable, E.g.<Set template=page_title>, so they are not run until a page template calls on them. At least, that’s how I understand it from the docs.

I’m more focused on the structure than performance right now, but given how this particular variable behaves, I don’t think it’s having a big hit on performance yet.

I have another template called theme variables that sets some theme properties like button titles, E.g. <Set name="post_button_title">read more</Set>. These would run on every page load, but it’s a very small file.

This is just my novice attempt to create a simple design system using a DRY code approach as recommended in your docs here.

I imagine this could all be solved more tidily using Tangible Layouts, but I think that may involve creating an entire theme from scratch. :slight_smile:

Yeah, that’s right. The template variable saves whatever markup is between those opening and closing set tags as a template instead of saving the rendered output of the markup. So then the template only actually gets run/rendered when you use <Get template=page_title />.

Interesting idea! Are you doing actual calculations or dynamic rendering or anything like that within this ‘theme variables’ template? Because if not and you’re just using that kind of template as a place to store text variables like “read more,” I wonder if it might be cleaner to just use an ACF options page and then use something like <Field post_button_title from=options /> as documented at the bottom of this page. Seems like it might be more user-friendly to manage, but maybe it’s not as clean as having everything in L&L.

Okay, I just gave it some more thought and I’ve realized you’ve got three options, each with tradeoffs.

The highest performance approach would probably just be to write “read more” within your templates, but that doesn’t give you the ability to change that value across your whole site all at once.

The DRYest approach that provides some ability to manage things centrally would instead be to have an individual template called post_button_title or something that literally just contains read more and nothing else, which you could then render on your page using <Template name=post_button_title />. This is probably only slightly less efficient than writing out the text value each time but still gives you the ability to change this value across your whole site in one go. The downside is that if you’ve got lots of theme variables you want, that leaves you with lots of different templates to try to keep organized.

The easiest approach to manage is the one you’ve started pursuing: having a single template that holds all the theme variables. The downside is that this is necessarily going to be less efficient than the two approaches above. But I think I’ve got an idea for how you could make it work. My idea is that in the templates that you’re using to display stuff on your page, whenever you want to display the value of one of your theme variables, you write this:

<Template name=theme_elements theme_variable=post_button_title />

And then in your master theme_elements template, you’d have something like the template below. It checks if the current theme_variable exists and if it doesn’t then it sets all the variables in your theme. Whether or not the theme_variable existed when you first loaded the template, it finishes by displaying the value of the current theme_variable. I haven’t tested this, but it should work (or at least provide the starting point for something that should work).

<If check="{Get local=theme_variable}" not_exists>
  <Set name="post_button_title">read more</Set>
  <Set name="second_variable">second value</Set>
  <Set name="third_variable">third value</Set>

<Get name="{Get local=theme_variable}" />

Now obviously the performance tradeoff here is that you’re running some conditional logic every time you want to display a theme variable and you’re also setting all the variables even if you only really need to render one. In the case of some “read more” text, the conditional logic part might run (and render as false without setting the variables again) dozens of times on a single page or more.

So I think the second approach here is the best middle ground between performance and ease of management, but if you really want to be able to manage all your theme variables all in one place, then the third option would work. Alternatively, if you don’t actually need any of the powers of L&L and are just dealing with text/image/color/ACF variables, then using an ACF options page is probably the best approach. Eventually, once L&L is able to actually save data to the database instead of only being able to render/display stuff on load, then that’ll be your ultra-efficient L&L-only solution, but until then you’ve still got plenty of options.

Thanks very much for all the info. :slight_smile:

Yeah, that was my first thought on how to approach managing theme elements (Titles, Buttons, Icons etc.), and I may end up doing this, but while developing the theme structure, it is slow because a lot is in flux.

I am hesitant to introduce anything more advanced right now as I don’t want to make it too complicated for other people who may work on the theme.

I agree that creating small individual templates representing theme elements is the best approach. It’s not good practice to load unnecessary code on every page! Switching to using individual templates is simple, so I can leave it until the theme structure settles down.

For theme variables like colours, button titles and copy snippets, it looks like ACF’s Options Page feature is the best solution. I’m already using ACF, so I will move the data there soon.

1 Like