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>
</If>
<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.