Skip to content
This repository has been archived by the owner on Feb 3, 2021. It is now read-only.

Passing data to templates #109

Open
mtahmed opened this issue Sep 6, 2019 · 4 comments
Open

Passing data to templates #109

mtahmed opened this issue Sep 6, 2019 · 4 comments
Labels

Comments

@mtahmed
Copy link

mtahmed commented Sep 6, 2019

Is it possible to pass data to a template? There is stuff like meta.title but is it possible to pass arbitrary data to templates from the post editor? E.g. in addition to the image for a post, I would also like to pass an image description and render it under the image as an image subtitle.

@claviska
Copy link
Member

claviska commented Sep 6, 2019

Sorry, this isn't possible yet.

@mtahmed
Copy link
Author

mtahmed commented Sep 8, 2019

I could try to implement it if I could get some pointers/help. I was thinking something like this:

  • The theme.json file inside a theme directory defines the additional variables it accepts. They could be 3-tuples: <variable_name, short_name, description>
  • The "Metadata" tab under the "Post Settings" renders all of those custom fields after reading the theme.json file. Alternatively, it could be rendered conditionally if the theme contains custom fields under another tab called "Theme Metadata".
  • Those values can then be set but the user and read into the meta variable or some other variable (e.g. theme_meta) and passed to the template files.

Does that sound reasonable?

@claviska
Copy link
Member

claviska commented Sep 9, 2019

The scope of this feature might be larger than we're considering.

I'm not sure it makes sense attaching custom data to the theme. That would mean switching themes destroys custom data (or at least renders it useless when you switch to other themes). Shouldn't it be attached at a higher level? Then supportive themes can use the helper API to access the data and use it however it sees fit. (I'm open to hearing use cases and alternative views here.)

They could be 3-tuples: <variable_name, short_name, description

It should probably include a type so the app can use an appropriate input or alternative (e.g. textbox, email, number, color, date, etc.). Taking it a step further (at least for the sake of discussion) it would be a good idea to add some kind of validation options as well.

Curious...how would short_name differ from variable_name?

@mtahmed
Copy link
Author

mtahmed commented Sep 9, 2019

Shouldn't it be attached at a higher level? Then supportive themes can use the helper API to access the data and use it however it sees fit. (I'm open to hearing use cases and alternative views here.)

Hmm you make a good point. Even if custom fields are a more high-level concept, unless all themes stick to the same set of variables, those custom fields would become irrelevant upon theme switch.

I guess the themes would get some dictionary and can lookup whatever variables are relevant to them.

Curious...how would short_name differ from variable_name?

short_name would be something like "Title Image Description" and the variable_name would be something like "title_image_desc". The first would be rendered on the UI and the second would be the internal variable name.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants