Fallbacks and Conditional Css Tags
theperfectwill opened this issue · 7 comments
Thoughts on this? I was just thinking it over and looking at the css and there is no fallback or conditional tags. So looking forward it seems a little problematic at the moment to use WP Dynamic Css on a greater scale.
For example...
/*
Examples...
*/
/* Default H1 Setting */
h1 {
color: $default_font_color;
}
/* Single Post H1 Setting */
/* (if this is NOT set, how to fallback to the above default setting?) */
h1 {
color: $post_font_color;
}
/* Single Post H1 Setting */
/* (if a post setting is NOT set AND no default settings are set how to return a default value? Or return nothing and empty the line of css?) */
h1 {
color: $post_font_color;
}
/* If the above is not set then the below will print */
h1 {
color: ;
}
I had some ideas and tried to make it simple. I think it should operate like php, so I was thinking something like this to make my point... and used HTML syntax since it would likely be familiar and a little easy on the eyes when writing the css.
/*
Examples...
*/
/* Default H1 Setting */
h1 {
color: <iftrue>$post_font_color</><else>$default_font_color</>;
}
h1 {
color: <iftrue>$post_font_color</><elseif>$default_font_color</><else>#555</>;
}
Any ideas or feedback? How to go about this?
I only see one way which is to use php to find the option value then load the css file based on that value, but this can end up including a lot more css files than needed or user friendly.
My thoughts example...
If $post_font_color
is true then...
wp_dynamic_css_enqueue('user-generated-styles', '/post-font-color.css');
If $post_font_color
is false then...
wp_dynamic_css_enqueue('user-generated-styles', '/default-font-color.css');
But you can probably see how that can quickly become a lot of little css files when using multiple css properties for one css heading and others.
I would address this from a different angle, and have my callback return the defaults if the value was not set. The documentation has a simple example that you can improve to meet your needs: https://github.com/askupasoftware/wp-dynamic-css#setting-the-value-callback
In short, you should be using get_theme_mod()
and pass it the default value for each option. That function will automatically return the default value if the option was not set yet by the user.
Since the dynamic CSS files are compiled in real time, I would refrain from making the syntax more complex since that will result in longer compilation time and have a greater performance impact on the site.
Ok.
You mean this... ?
function my_dynamic_css_callback( $var_name )
{
return get_theme_mod($var_name, @$theme_mod_defaults[$var_name]);
// @$theme_mod_defaults[$var_name] being the default
}
wp_dynamic_css_set_callback( 'my_dynamic_style', 'my_dynamic_css_callback' );
Yes, if you take a look at the Get Theme Mod Docs you'll see that the second argument is the default value, and it will be returned if the user hasn't made changes to that option yet. The @
symbol is just used to suppress any PHP warnings incase the $defaults
array doesn't have a certain value.
Read this great article on how to create settings pages for themes: https://developer.wordpress.org/themes/advanced-topics/customizer-api/
Thanks, I see.
So for what I am asking I see what you mean. I could just tweak it so that it would get the post_meta value first, then if that is not available it would get the settings value, and if that is not available then it would get the default value defined by me.
That may or may not be in my ability just yet, since I'm new. Are you available for freelance on something like this? If so, I can email to get an idea of cost and best implementation.
Oh by the way, I'm not using this for the customizer API. I'm using the Codestar Framework. Which integrates with the Customizer API.
Yes I can help you with that, you can contact me here: http://askupasoftware.com/contact-us/ and we can further discuss your requirements.
You might want to look into different frameworks that support the customization API, like the Redux Framework or Kirki since that's the proper way of doing it.
Thanks.
I agree and Codestar framework does support the Customizer API, I just haven't got to that part yet using Codestar or the Customizer yet, I was referencing personally. No fault to the framework, which is still be developed.
I chose not to use Redux because it is just to heavy a product for me, I don't like it's UI and I'd rather have something more unique. It is also missing a few features that I need from Codestar that I don't want any Redux user to know about. Finally, Codestar offers everything upfront (metaboxes, customizer, all fields, etc.), which allows me to work on my first premium theme and become profitable before paying for extensions while still in development, instead just donate and help promote. I'm actually just going to pay for some of the features available in Redux to be developed in Codestar as needed, with which maybe you can help develop too for a cost.
In the end I'd rather just pay to have Codestar developed than pay for Redux. I like the experience much better and that is lightweight.
I'll use your contact form to get the conversation started and touch base.