Percentage sign in default value

[pixedelic]

Hello, I need to use the "%" sign in default value, but it doesn't seem possible... am I right or missing something? I would like to set at default value:

calc(50% + 500px) calc(100% - 100px)

to let the user understand they may use custom background positions as well in some cases.

P.S.: related with this, but maybe I need to open a new issue... is there any way to put a link into a description? I would like to link some doc pages to some fields, but the tags are always removed. Also tried to wp_kses to escape them, no luck.

TIA, Manuel :-)

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[aristath]

@pixedelic what type of control are you using? Is it a text control?
Can you please post the exact code you're using?

The problem with both issues described in your post is sanitization. Kirki is used by many theme authors, and in order to be compliant with the WordPress Themes Review Team we have to sanitize everything.
Perhaps if I see your code I may be able to add some filters so that devs can override the default sanitization functions with their own...

[pixedelic]

Yes I know, I'm a theme author as well, even if on a marketplace, and you did a great work, sincerely!

However, here is the code:

    $fields[] = array(
        'type'        => 'text',
        'settings'    => 'pix_404_bg_position_custom',
        'label'       => esc_html__( 'Custom background position', 'logan' ),
        'description' => esc_html__( 'Select "Custom" in the field above', 'logan' ),
        'section'     => 'logan_404_page',
        'default'     => 'calc(50% + 500px) calc(100% - 100px)',
        'priority'    => 10
    );

When I load the customizer it displays as default value: calc(50x) calc(100x), but if I enter a string with the % sign, everything goes fine and the value is saved correctly.

About the link: as I said I tried to escape the description by myself, but Kirki escapes it again I'm afraid there's no workaround but edit Kirki itself (and I don't want to do it, so good bye links).

Are those the info you needed?

[aristath]

Yeah, that was all the info I needed...
It's a really bizarre issue!

I added a new text control overriding the default WP control but the issue still remains... really puzzling!

As for the link in descriptions, I'll see if I can add some filters that will allow getting around the extra sanitizations.

[aristath]

Ha... No need for any filters to allow links in descriptions, you can already do that.
Instead of this:
'description' => esc_html__( '<a href="#">link</a>', 'logan' ),
you can just use this:
'description' => __( '<a href="#">link</a>', 'logan' ),
and ideally this:
'description' => sprintf( __( '%s link %s', 'logan' ), '<a href="#">', '</a>' ),
It seems to be working fine for me :)

The 3rd option (using sprintf) will allow translators to translate the text of the link without messing with the link itself. ;)

[pixedelic]

Thank you for investigating, really appreciate.

About the link in descriptions, do you mean in this way?

    $fields[] = array(
        'type'        => 'text',
        'settings'    => 'pix_404_bg_position_custom',
        'label'       => esc_html__( 'Custom background position', 'logan' ),
        'description' => __( '<a href="http://kirki.org/">Click here</a> for more info', 'logan' ),
        'section'     => 'logan_404_page',
        'default'     => '50%',
        'priority'    => 10
    );

Since I just tried, but no luck... I'm still running v.1.0.2, should I update to 2.0.alpha? Here is a shot however:

[aristath]

@pixedelic yes, you should definitely try switching to the new version from github!!
Lots of things have changed and many, many things have been improved!!

[pixedelic]

You did a great work here... but the new version seems a different tool now actually, I can't update, I have to migrate I'm afraid...

[aristath]

What is it that makes it seem like a different tool exactly? Could you please be a bit more specific? I'd love to make adjustments but I'll need more info...

[pixedelic]

Yes sorry, you're right, maybe I was a little melodramatic, however I don't want to say you have to make adjustments for this, your plugin is great, I only want to say that many of my custom fields simply do not work now, and it is just a personal opinion based on the use I make of your plugin.

However, to add more details: first, the way to create "stuff":

add_filter( 'kirki/fields'...

vs.

Kirki::add_config( 'my_theme', array(
...
Kirki::add_field( 'my_config', array(

Second: you removed chosen, but selectize is very different in many things, for instance I can't store option data through data attributes anymore, since selectize seems to delete the original select options. They were very important for me, since I created a custom Google font manager that stored font weights and subsets available for each font family as data attributes of the options themselves. Once you selected a particular font family I was able, in that way, to hide weights and subsets not available and let you select weights and subsets available for that particular font only.

Third: sliders don't allow to type a value anymore, that was a useful thing instead.

Fourth: color pickers look inconsistently, is it an anticipation of WP 4.4?

Ok... not so many differences actually, but they are the first I've seen and are important for me. I like the new features, but I already developed my personal versions of Google font manager and "repeater D&D control" so... I'm still considering if I should face this "migration" :-)

[aristath]

first, the way to create "stuff":

The kirki/fields filter still works, there's no reason for you to switch to the Kirki::add_field() method!

Second: you removed chosen, but selectize is very different in many things

The switch from select2 to selectize was necessary for us... the reasons for that switch are explained on #516

for instance I can't store option data through data attributes anymore, since selectize seems to delete the original select options. They were very important for me, since I created a custom Google font manager that stored font weights and subsets available for each font family as data attributes of the options themselves. Once you selected a particular font family I was able, in that way, to hide weights and subsets not available and let you select weights and subsets available for that particular font only.

Would you be interested in joining forces so that we make the new typography field work this way? I'm sure if we both work on this we can get it working in no time.

Fourth: color pickers look inconsistently, is it an anticipation of WP 4.4?

No, that was actually an error. These styles were for a specific WP theme that I'm working on and somehow I committed them to Kirki instead of the theme's stylesheets.
This will be fixed.

[pixedelic]

Would you be interested in joining forces so that we make the new typography field work this way? I'm sure if we both work on this we can get it working in no time.

It would be great, thank you for the offer, but I'm afraid I don't have time before the end of the year... I need to release a new theme if I want that my children have something to eat :D

[aristath]

ok, I can understand that.
It is on my to-do list however, so it will be done. I just don't know when...
If at some point you have some free time and want to work on this together I'll be here.

[aristath]

Is this ticket still valid?

[pixedelic]

@aristath I'm afraid I'm asking too much :D However it should be great to use percentage sign somewhere, if possible, yes

[aristath]

Wait, you mean you still can't use % in the font-size for example?

[aristath]

Oh, wow... I see I completely misunderstood the point of this thread again.

So... Where do we want the % exactly??
In descriptions? allowed in textfields? I still don't get it.
Sorry, it's just been a hard weekend.

[pixedelic]

No, please, really, I don't want anything, please consider these as suggestions only. However percent sign could be used if you need to determine a width or a background position. Maybe it is an edge case, however in my original post I only asked why percent sign was removed from default values.

[aristath]

@pixedelic I believe the new value_pattern argument in the output arrays solves this issue...