Hot answers tagged theme-customizer
9
There's a few bits here that apply, but the short of it is this code in customize-preview.js:
this.body.on( 'click.preview', 'a', function( event ) {
event.preventDefault();
self.send( 'scroll', 0 );
self.send( 'url', $(this).prop('href') );
});
The event.preventDefault prevents the links from actually working. The following code then sends a ...
8
The premise of the question is flawed. The Customizer API is not an options API, but rather an options preview API. The Customizer API relies on either the Settings API or the Theme Mods API to register controls for existing settings added via either of the two APIs.
The Customizer does not - and cannot - define/register new settings that have not already ...
7
Example and class for usage
You can see on my current theme, how it's possible to use this. Also you can usage the class. See this class on Github an check the functions.php for include this.
Start & init
You can register your custom settings for the theme customizer via the customize_register hook:
add_action( 'customize_register', ...
6
Our journey starts here with the WP_Customize_Background_Image_Control class, which is a WP_Customize_Image_Control.
I'd imagine offering these built-in backgrounds in a new tab alongside the existing Upload New and Uploaded tabs. There are at least two ways of achieving the following: either creating your own modified class based off of the ...
4
As simple as things can sometimes be: The Settings API is not the Theme Customizer. Both are different things for different tasks.
Settings API
You're either writing a plugin or have a theme that doesn't have options that won't need any visual feedback? Go with this option.
Theme Customizer
You need to have options that have a visual impact that the user ...
4
Okay, first, let's set things up properly, with a callback hooked into an appropriate action hook:
<?php
function wpse55227_enqueue_scripts() {
// Enqueue code goes here
}
add_action( 'wp_head', 'wpse55227_enqueue_scripts' );
?>
We'll put all of our code in to this callback.
The next step is to add our if ( ! is_admin() ) conditional wrapper:
...
3
Here is one way to do it by extending the control you want to use.
Below is an example where we extend the text control and add an extra description like the one seen here on the screenshot:
function mytheme_customizer( $wp_customize ) {
class Custom_Text_Control extends WP_Customize_Control {
public $type = 'customtext';
public ...
3
This drove me mad for a while, but I got it to work by adding them with the full arguments that are used in the admin script loader rather than just referencing the handle. When I print the $wp_scripts global on the front end, iris and wp-color-picker are nowhere to be found, though all of their jQuery UI dependencies work. Anyway, not sure this is right, ...
3
If you need them in a specific order, then give a priority value to the controls. Otherwise, their order is not defined and cannot be guaranteed.
If you don't define a priority, then the control gets the default priority of "10".
When two controls have the same priority, then the resulting order is undefined, because that's how PHP works.
3
You're never using your class. Try passing a new instance of your class to the add_control method:
$control_args = array(
// your args here
);
$my_control = new WP_Customize_Palette_Control(
$wp_customize, 'themename_color_scheme', $control_args);
$wp_customize->add_control($my_control);
Also, I don't think WP knows that the option ...
3
I found out the WP_Customize_Manager class has a function called remove_section(). In your function hooked to customize_register you can just do:
$wp_customize->remove_section('nav');
$wp_customize->remove_section('static_front_page');
You can find the ID of the section (i.e. 'nav') if you inspect the accordion title bar of the section. Look ...
3
As in this question: How to execute conditional script when on new customize.php (Theme Customize) screen
global $wp_customize;
if ( isset( $wp_customize ) ) {
// do stuff
}
2
Ok, here's how to do this. Seperate your control class(es) to one or more new files.
You have a function or method hooked on customize_register, right? In that function or method require once your new files just before adding your custom controls. Then PHP won't complain about redefining classes.
Note: This will not work out of the box, but shows the ...
2
Accoring to OTTO
One final thing you can add to a section is a “theme_supports” option.
This will make the menu not appear unless the theme supports
something. If you’re putting this code in a theme itself, then you
already know what the theme supports, so it doesn’t make much sense.
The core uses this to not show the header and background ...
2
The color picker thing is registered as a jQuery UI widget, so you could modify its prototype object before the widget is used in the page:
add_action('customize_controls_print_footer_scripts', function(){
?>
<script>
jQuery(document).ready(function($){
$.wp.wpColorPicker.prototype.options = {
border: false,
// ...
2
If your settings are stored as Theme Mods, rather than as a Settings API option, then you need to pass the appropriate value to the type parameter to $wp_customize->add_setting():
'option': Settings API option (get_option())
'theme_mod': Theme Mods API option (get_theme_mod())
Try changing this:
$wp_customize->add_setting( $this_theme . ...
2
is_plugin_active() expects just the base name of the plugin as parameter:
So use:
is_plugin_active( 'woocommerce/woocommerce.php' );
The function will use the option 'active_plugins' which is a list of plugins paths relative to the plugin directory already.
On a multi-site installation it will search in get_site_option( 'active_sitewide_plugins') too.
...
1
The solution, needs a custom control object extending the original image control, and does an SQL query to grab the GUID and associated attachment ID on sanitisation. Not nice, kludgey, but it works
$wp_customize->add_setting( 'customimage', array(
'default' => $default,
'capability' => 'edit_theme_options',
'type' ...
1
If someone has a better solution, I'm open to it, however, what I came up with seems to work fine.
Basically the following code is just waiting for the image to finish uploading and then hooking into the add_attachment action. Once the first is added, we hook in and then generate the new images via the post ID (for the image attachment) which is the only ...
1
Hook a function to the customize_preview_init action. In that function, do your add_action for the wp_head.
The customize_preview_init action runs in the call that renders the frame that the preview page is displayed on, and happens early enough to hook onto wp_head.
1
If you mean a hook that fires when you are actually customizing the theme at wp-admin/customizer.php, with the tool bar on the left, then there are several hooks on that page. For example (but not an exhaustive list)...
do_action( 'customize_controls_init' );
// ...
do_action( 'customize_controls_enqueue_scripts' );
You should be able to narrow things ...
1
Thanks to @chip_bennett to point it out!
I registered the settings using settings api and I was trying to add the settings on customize api by the type of theme_mod that's why it was showing the error. After changing the 'type' => 'theme_mod' to 'type' => 'option', it worked :)
1
Yes this right. The var is only for customize the theme and works not in frontend, overhead and not usefull. After the user customize the theme, than was saved in options. Use the default functions to get the data, like the function get_option().
See also this theme file as example. It add stylesheets in frontend and use the data from the customizer. But ...
1
With @Otto's tips, i found the problem.
I was calling theme settings in functions.php and was calling settings as global variable in theme files. This was working properly except temporary changes was disappearing in theme customizer's live edit when you change page with clicking links.
After this experience, what i am suggesting:
If you have some ...
1
CleanUp
Iterating is much easier for debugging, as you'll see step by step information:
»What happens, after I added this to that?«
So simply start with a clean up and see how it gets added.
foreach ( range( 1, 7 ) as $nr )
{
$wp_customize->add_setting(
"tonal_{$themeslug}_settings[link_color{$nr}]",
array(
...
1
There are no hooks to that part of the Dashboard.
It has to be done with CSS (or jQuery if you want to convert it in another thing).
add_action( 'admin_head-index.php', 'hide_customize_button_wpse_82424' );
function hide_customize_button_wpse_82424(){
?>
<style type="text/css">div.welcome-panel-column:first-child {display:none;} ...
1
There's very little documentation on this class, but here below is the full example from WordPress core (here's github). Note you'd be using the $wp_customize object you get as argument to your custom_register callback and not $this as does the core class. I've done a search and replace below and it works.
/* CORE COPY PASTE */
...
1
I believe that all you need to do is pass defaults to get_option
function init_theme_options() {
// check to see if theme options are set
// Not sure how your options are organized but...
$defaults = array(
'opt1' => 'stuff1',
'opt2' => 'stuff2'
)
$theme_options = get_option('theme_option_name',$defaults);
}
If you want to see a ...
1
Just an idea:
Make a user called 'Guest' and look up the user ID
When redirecting your potential clients to the admin page, redirect to a script that's logging in your clients as the guest user (Code #1)
Add an WordPress action to disallow the user when logged in as 'Guest' and not on customize.php (Code #2)
Code #1
$creds = array(
'user_login' ...
Only top voted, non community-wiki answers of a minimum length are eligible
