-
Notifications
You must be signed in to change notification settings - Fork 330
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor the background fields. #952
Conversation
Related to #847
Some data (image URL) for the original rendering but we don’t want to save it in DB. Fixes #849
# Conflicts: # assets/js/controls/repeater.js
I don’t think it is serving any purpose and was conflicting with other things.
CSS fix on hidden fields. Related to #833
Change markup for the Editor Field
Repeater control bug fixes
Don't output fields with unmet dependencies
@aristath is there going to be support for this new background control in repeater fields? |
It's too early to tell... currently there's nothing implemented. |
@aristath : just wondering - I see that "background" field is set for 3.0 milestone and not in docs anymore. Are there going to be changes in arguments array ? So i know whether to ditch momentarily "background" field, and go to "combo / image / dropdown(attachment,position,repeat,size) / color" for element background ... Thanks |
The background field is a big mess... $saved_option = array (
'image' => 'https://domain.com/image.png',
'color' => '#ffffff',
'background-repeat' => 'no-repeat',
...
); The control hasn't been in the docs for about a year now, because I never liked the implementation. It was done way back when I was starting to explore the customizer API and I just needed something quick and dirty. Please avoid using the background control.... If you really need one, I would advise you to just create separate fields for the fields you need. |
@aristath : Thank you so much for very fast and very helpful reply ! :) Wouldn't it be good to implement solutions from "repeater" fields in ? Since "repeater" is actually a custom combo, "background" would be simpler, non-custom combo ... Just a thought, but you probably considered that a while ago ... I wish if I only had more knowledge and time to contribute here ... And money to donate ... 😞 |
@aristath: Thank you for all good stuff. Today i am work on background field for kirki. this is my results for now: the saved value is array : handle live preview with this simple code: wp.customize( 'header_background', function( value ) {
value.bind( function( to ) {
to = JSON.parse(to);
$('.header').css({
'background-color': to.color ? to.color : '',
'background-image': to.image ? 'url('+to.image+')' : '',
'background-repeat': to.repeat ? to.repeat : '',
'background-size': to.size ? to.size : '',
'background-position': to.position ? to.position : '',
'background-attachment': to.attachment ? to.attachment : '',
});
});
}); it still need some tests .. i think it will be complete tomorrow if you still interest in this field i can send it for you |
@lionhurt hey there! So you refactored the background field? |
@aristath i will create a pull-request as soon as possible (i think it will be tomorrow) Thanks |
Awesome work guys On 13 Oct 2016 5:29 AM, "lionhurt" notifications@github.com wrote:
|
Wow, it would be great if you could merge that asap ... :) |
Will it work for repeaters? On Oct 13, 2016 13:51, "Anydog" notifications@github.com wrote:
|
I create a new pull request here : #1140 |
i don't test it yet. |
The new background field should save settings in an array instead of creating individual separate options/theme_mods.
The hard part here is making sure we don't break anyone's themes since the format will completely change.
In order to do that, we'll have to add a separate filter for options, serialized options as well as theme_mods, for each of the background sub-fields separately.
The old settings were:
So we'll have to create 18 separate functions & filters in order to keep backwards-compatibility.
These will have to go in the Kirki_Field_Background class.
The desired functionality is this:
Theme using this code:
should check if we have a
my_bg
background field that has acolor
defined in its default values.If we do, then we have to get the value of the
get_theme_mod( 'my_bg_color' )
.If it exists, then the db has not yet been migrated, so we have to get the value of
my_bg
, check if we have a color there. If not, then inject the value of the previous theme_mod, and remove the theme_mod.If the theme_mod does not exist in the db, then get the value of the new theme_mod like this:
After the migration functions & filters are complete we can proceed in building the actual control.