Three sliders, one option, and a few tears later

Yes, sliders have a special place in my heart. Granted a super tiny place in my theme reviewer’s heart. Now, I’ve created a few tutorials, guides, resources, links, what you will on this site in order to share some of my insights into WordPress theme development and perhaps some WordPress theme reviews along the way.

There are a lot of things I have learned and a lot of things I had to learn. I think the biggest takeaway from this post will be that integrating a slider plugin to a theme is fairly easy to do but a pain in the butt to fully integrate.

So, let’s get the show on the road!

First steps

Okay, we need to figure out first what slider we would like to play nice with, right? I chose sort of at random three different plugins that all create sliders.

I was going to use Meta Slider but they actually have a fairly extensive documentation section on theme integration. So major kudos for them on providing those code snippets!

As you can see we have our three sliders to choose from and now we need to determine if they are active or not. I know some will want to use is_plugin_active() but I will tell you not to. The reason for not doing so is so that you don’t load an extra file. So instead we will use some basic PHP functions to check.

function jc_get_sliders(){
	$sliders = array();
	if ( class_exists( 'Soliloquy_Lite' ) ){
		$sliders['soliloquy'] = 'Soliloquy';
	if ( function_exists( 'huge_it_slider_activate' ) ){
		$sliders['huge_it_slider'] = 'Huge IT Slider';
	if ( function_exists( 'wd_slider' ) ){
		$sliders['wds'] = 'Slider WD';
	return $sliders;

I know some of you are wondering why I chose to use the class and functions I chose to check for. Those are the classes and functions those respective plugins use when they are activated. If those plugins are not active they will not exist.

Now that we have our options for plugins we can create our theme customizer options.

add_action( 'customize_register', function( $wp_customize ){
	// Set up the section
	$wp_customize->add_section( 'slider-section',
		'title' => __( 'Select a slider', 'jc-domain' ),
		'priority' => 30,
		) );
	// register the setting
	$wp_customize->add_setting( 'slider-type',
		'default' => '',
		'sanitize_callback' => 'jc_valid_slider',
		) );
	// register the setting's control but only output if those sliders exist
	$wp_customize->add_control( 'slider-type-input',
		'label' => __( 'Select the slider to use', 'jc-domain' ),
		'settings' => 'slider-type',
		'section' => 'slider-section',
		'type' => 'select',
		'choices' => jc_get_sliders(),
		'active_callback' => 'jc_sliders_exist'
		) );
	// register the setting
	$wp_customize->add_setting( 'slider-id',
		'default' => '',
		'sanitize_callback' => 'absint',
		) );
	// register the setting's control but only output if those sliders exist
	$wp_customize->add_control( 'slider-id-input',
		'label' => __( 'Input the ID of the slider you would like to use', 'jc-domain' ),
		'settings' => 'slider-id',
		'section' => 'slider-section',
		'type' => 'number',
		'active_callback' => 'jc_sliders_exist'
		) );

Great! Now you can see that I am using an active_callback for the controls. This is so that the section will not show if there are no active plugins to choose from. That means we have to create that callback. Fairly simple:

function jc_sliders_exist(){
	if ( !empty( jc_get_sliders() ) )
		return true;
	return false;

As you see we can utilize the first function we created that gets the sliders to our advantage. If the array is not empty we return true, otherwise we return false. Straight-forward. Now, you may notice one function we may need to create and that is jc_valid_slider. This is what will check if the option is a valid option and return it. So, let’s create that shall we:

function jc_valid_slider( $value, $control ){
	return ( array_key_exists( $value, jc_get_sliders() ) ) ? $value : $control->default;

Yes, you can see we are still using jc_get_sliders() to get our values. No need to create another wheel when we already have one, right?

The output

I know you are now wondering, “But Jose, how will you display the slider?” Well, let me show you how! We use get_theme_mod() and do_shortcode() with a quick check to output our slider.

add_action( 'jc_slider_area', 'jc_create_slider' );
function jc_create_slider(){
	// get the setting for the type of slider
	$type = get_theme_mod( 'slider-type' );
	// get the setting for the ID of the slider to use
	$id = get_theme_mod( 'slider-id' );
	// Check if we have chosen a slider
	if( !$type ){
	echo do_shortcode( "[$type id='$id']" );

Great! But I know you are probably wondering why I’m using an action hook rather than creating a function and calling it. What’s super cool about using a hook is that this can be extended or removed with a child theme or functionality plugin. Super great way of making your theme extendable and child theme friendly. So, in the last step all we need to do is create that action hook.

<?php do_action( 'jc_slider_area' ); ?>

By adding that to where you want the slider to show, you can create a great hook for any theme developer to utilize.

Minor note

If you hadn’t noticed, I registered the customizer settings using an anonymous function. This will work on PHP versions 5.3 and higher so please make sure you are aware of what your environment you are developing for. So go, explore and try to break things along the way!

One theme reviewers point of view

How to begin? Well, back in 2012 I took the plunge and began my first theme review. It was a great experience because I got a chance to not only learn something but give back as well. I was already looking at themes because I love design. I wanted a different theme for my site and wanted to learn how to create themes. Of course, at the time there was only one in-depth tutorial on creating WordPress themes.

I’ll skip ahead a little bit and get to the part that may be juicy for some. After some time I was able to assign my own themes to review. This was a different time. The capabilities have changed a little over time. The process has – to a degree – changed. Some parts for the better.

Now, what I’m going to share may startle a few and rattle a few cages, but I’m okay with that. Reason is because I know I’m not alone when I feel this way. The process has slowed down too much. What used to take a week is now months. It’s not that reviewers don’t have time, it’s not that we don’t have the people, or the know-how. A lot of it is because there is so much to look over.

Today, I began to think about what needs to be looked over by one person. Yes, one person does a review of one theme. Then an admin looks over and sets the theme live. This process is being worked on.

Now, as I said, I actually counted all the requirements that need be addressed before any theme can be made live. Let’s count them by the sections they are listed:

  • Code: 6
  • Core functionality/features: 11
  • Presentation/Functionality: 1
  • Docs: 1
  • Language: 4
  • Licensing: 4
  • Naming: 2
  • Options/Settings: 4
  • Plugins: 2
  • Screenshot: 2
  • Security/Privacy: 4
  • Selling/Credits/Links: 2
  • Styles/Scripts: 6
  • Templates: 4

Wow! That is a lot to look over, right? Looking at the core functionality and features is a daunting one. Eleven items! Eleven! Add them all together and you have fifty-seven requirements that a theme must meet in order to meet the standard and pass. Now, that does not include the accessibility audit if a theme has the accessibility-ready tag listed. Yes, that too has a few requirements that need to be addressed.

So you can kind of see why it can take some time to conduct a theme review.

The other part is the time frame. Theme reviewers give up to a week for the theme’s author to submit a revised version of the theme with all the fixes. Does it always happen? No. A lot of the non-approved themes are because they didn’t reply in time or didn’t submit it in time. It does happen.

The downside is that some will submit a revised version on the last day before the “deadline,” and the process can then be resumed. The reviewer will look over the changes and make note of any missing requirements. As you can see the time can add up. As that happens, new themes are being submitted and sort of left there without a review.

You can see how they can quickly add up. Currently the wait time to have a reviewer assigned is about seven weeks. You read it right. Seven.

One thing that may make it faster is closing a ticket if the theme does not meet half of the requirements. Okay, great but not all themes have that many issues, correct? It is possible but how many are there that do?

Or perhaps not approve the theme if it doesn’t meet all the security and core requirements? Makes more sense to do something like that, right? At least then we can focus a little more on teaching about better practices and posting on the make blog about theme development.

Don’t get me wrong, this hasn’t stopped me from reviewing themes at all and it won’t. I just wanted to share a different point of view on an ever-evolving process.