Add functionality for widget instances to have unique templates#26
Add functionality for widget instances to have unique templates#26tbartels wants to merge 3 commits intoscribu:masterfrom
Conversation
- create a simple way to have widget instance specific template files based on a configured suffix, similar in concept and execution to WP `get_template_part`
- add `scbWidget::input` text element for template suffix configuration
- add template tag `{{{suffix-input}}}` to widget instance form template
- adjust `Taxonomy_Drill_Down_Widget::mustache_render` to use a hierarchical array of temlate search paths with `locate_template`"
realized I was over-thinking some things and cleaned things up to hopefully be more readable and understandable
widget.php
Outdated
There was a problem hiding this comment.
I think replacing all that with a call to sanitize_title_with_dashes( $data['suffix'] ) would be both cleaner and more secure.
There was a problem hiding this comment.
Or rather, call sanitize_title_with_dashes(), and construct the $templates array later, instead of constructing and then destructuring it.
There was a problem hiding this comment.
Good call, and probably even better would be to use sanitize_file_name, I'll adjust and commit.
- procedurally add template names instead of trying to manipulate an array - use WP `sanitize_file_name` to clean the user input suffix
|
I figured out what I don't like about the patch: Instead of making the user write out an arbitrary suffix, we should show a dropdown, with the list of available templates in the theme. |
|
That was my original approach but it added the complexity of verifying the different modes against the templates. If I display a list of all templates the end-user could select |
|
I could see it working like this:
|
|
That's where I started, but found it to be a whole lot more UI than necessary. I'll see if I can find the time to re-implement it. |
2 participants
I needed a way to use unique templates for each Taxonomy Drill-Down widget. Inspired by WordPress'
get_template_partI added the ability to do something similar in the widget instance config. It is now possible to add a 'suffix' parameter to each widget which will make the template renderer look for the functional equivalent of"qmt-templates/{$mode}-{$suffix}.html"before the default template.