Data Shows 24% of Themes Hosted on WordPress.org Support the Customizer

Aaron Jorbin, who contributes to WordPress core on a regular basis, has published a script called WordPress Theme Directory Slurper. The PHP based script downloads and updates a copy of the latest stable version of every theme in the WordPress.org theme directory. Devin Price put the script to good use and has published a series of data points related to the theme directory.

It took Price 112 minutes to run the script and download nearly 4GB of theme code. In his report, Price answers the following questions:

  • How many themes are based on Underscores?
  • How many themes are on WordPress.org?
  • How many themes have lite in their name?
  • How many themes use the latest WordPress functions?
  • How many themes add an options page?
  • How many themes use a bundled options framework?
  • How many themes use TGM Activation?

How Many Themes Support the Customizer?

Last week, we reported on a significant change to the WordPress theme directory guidelines. Beginning on April 22nd, themes submitted to the WordPress.org theme directory will have to use the customizer to build theme options. Themes already hosted in the directory have six months to comply before the Theme Review Team will enforce the new requirement.

By searching the directory for themes that use $wp_customize->add_control, Price was able to determine that 761 themes or 23.8% currently support the customizer. The low number coincides with Justin Tadlock’s assessment that adoption has been slow, especially when you consider that it was added three years ago to WordPress 3.4.

One thing to keep in mind is that after the six month cutoff date, themes not using the customizer will still be able to be downloaded from and hosted on the directory. However, the theme code can not be updated unless it follows the new guidelines.

It will be interesting to see what the data looks like three months from now as it would indicate how many and how fast, themes are adopting the customizer. Price is taking requests for what data you’d like to see, but if you want to do the research yourself, Jorbin’s Theme Directory Slurper is available for free on GitHub.

25

25 responses to “Data Shows 24% of Themes Hosted on WordPress.org Support the Customizer”

  1. Those are actually better numbers that I’d hoped for — 23.8% using customizer and 49.73% probably using a theme options screen. I wonder how much crossover there is between those numbers. I know that some themes both utilize the customizer and add an admin screen. It’d also be interesting to see some comparison data since the date the customizer was added.

  2. Axe to grind? I would drop the “Only” and add a bang to the end of that headline: “24% of Themes Hosted on WordPress.org Support the Customizer!” 761 themes is a goodly number. I wonder how many of the remaining 75% are themes with no or limited options or themes that have not been updated in ages. That one number is isolation does not tell us much.

  3. I believe the “Slurper” script does grab all the published themes, not just the ones that have been updated within the last two years. Customizer use would obviously be much higher in newly published themes. I’ll see if I can figure out how to pull that data.

  4. I’m intrigued by the reactions here. I’d also be interested in seeing the filtered data for themes updated in the last two years.

    But taking the data as it is, for me, it’s actually quite surprising that after three years (and fair pressure), only 24% of themes use the customizer. But the number that’s even more notable is that 50% of themes have a options pages.

    That means that the decision to require the customizer instantly renders 50% of all themes in the repository out of compliance, and compels them to adopt different approach or face obsolescence. That seems epic to me. It’s also worth noting that there are two times more themes using options pages than use the customizer. In that sense, we’re also imposing what is currently a minority approach on the majority.

    Everyone seems to be assuming that the themes using options pages are old or are out of date. That could be, and that’s what I’d be interested to see. But an alternative and equally plausible interpretation for now – and one that’s generally supported by the theme market outside the repository – is that many theme authors and users just like options pages more than the customizer, at least for certain uses.


    Anyways, apart from all that, neat data and I’ll be interested to see what else comes out of it.

    • Spot on.

      Furthermore, of those 24% that support the Customizer, how many of them also offer an additional options panel and simply support the Customizer in addition to their own option panel?

      If you also factor in that Automattic has around 60 themes on the repo, and many themes on the repo are based on underscores and by default are customizer enabled this 24% is actually inflated. I would argue that the number of themes using the Customizer only is significantly lower.

      I know most of the CyberChimps themes support both the Customizer (not because we wanted to but because TRT recommended us to support it), and our own theme options. CyberChimps is also the second largest theme company on .org behind Automattic, and we’ve got nearly the same number of downloads with 1/3 the number of released themes. This alone proves that custom theme option themes are significantly more popular than Customizer only themes even on WordPress.org.

      As someone who has sold both Customizer only themes, and a custom theme options panel with drag and drop and a variety of other custom options the Customizer only themes do not sell well by comparison. It isn’t even close. Even Responsive by far the most popular theme on the repo has a separate theme options page.

      The Customizer failed to achieve major adoption in 3-years, and what adoption it did receive was pretty much forced on us by TRT and Automattic, or slipped in because of the default support in underscores.

      The logical and reasonable conclusion to be derived from this data is that the majority of theme authors, and users prefer non-Customizer theme options. The Customizer is applicable for less then 25% of themes currently on the repo, which is beyond a failure in my eyes further illustrating the fact that the new TRT rule of Customizer-only themes in 6 months is entirely unreasonable.

  5. I took sometime messin’ about with Customizer. I do not know why any coder would say its hard to use. Its easy peasy and I might say rather well suited towards its task. Having not experienced lots of themes playing with them, exactly how many features does one care implement?

    My only experience with this is one Envato theme (a top seller I guess?) where I had to fix the Emoji JS for friends. That was simple enough. But the theme, OH MAY GOSH what a mass of goo in as far as code.

    In as far as add_query_arg these functions in general. Its never a great idea to be manipulating URL’s when SESSION data can be used instead for most purposes. If one is modifying URL’s to for example try increasing search engine spidering based on say their plugin its just not a great idea though at least that has purpose.

  6. I have no strong (or frankly, informed) opinions about the customizer or best practices for building themes – they’re not my area.

    However, my analytical brain tells me that there’s data, and there’s the interpretation of data. 24% of themes support the customizer. The interpretation suggested in the article seems to be in the area of “theme authors need to update their practices” – which suggests the response “how can they be encouraged to?”. But another could be “the customizer isn’t attractive enough to theme authors” – which suggests the response – “what might be wrong with the customizer?”. As I say, I have no specific opinions here on the questions themselves – I’m just coming from the statistical interpretation angle.

      • PHP 5.5 and 5.6 aren’t yet widely spread. But why?

        The problem is that those versions deprecated several well known features of very old scripts. I, as a small hosting provider, simply know that if I upgrade to 5.5, customers who cannot afford to upgrade old Moodle’s, old phpBB’s, old whatever, will find their sites broken. And not-that-old-scripts will break too, because PHP 5.5 is abandoning the mysql_query function and related in favor of the modern mysqli_query() or PDO based, so that many custom scripts and plainly a big amount of PHP scripts using MySQL databases will start to fail (thanks Oracle!) (I like to think that if Oracle wouldn’t have bought MySQL this wouldn’t happened).

        So, I’m waiting for the cPanel guys to officially start supporting multiple versions of PHP in the same server, to be able to provide stock cPanel without customizations, supporting PHP 5.3, 5.4, 5.5 and 5.6 in the same box. I wonder if once this feature is implemented, those graphics will start to change…

    • Customizer is simply boring and too hidden for some users, they forget it is there.
      I, as an advanced user, really prefer to have all the configurations together in a complex Theme Options page rather that having to look for the cosmetic thingies in the customizer.
      And probably this same idea is going through several other devs. In example: I never configured widgets from the customizer. Even so, we must recognize this is a very well coded feature of WordPress.

      Maybe it’s a good question for another poll, for Jeff:
      – How many users setup theme options using the Customizer?
      – If you can chooose, do you prefer to use themes with support for Customizer? “Yes” / “No” / Don’t care as long as the theme is the best for the project”.

      • Interesting discussion…

        Working with the information we have available, if half the surveyed themes do not provide options I suggest that such themes should be excluded from the calculation because they are probably obsolete or not serious. That leaves us with half of themes using Customizer and half not. A very different headline.

        To be honest, Customizer is still in a primitive state with much work to do. Simple things are not there: for example, no easy way to define a custom color palette at the bottom of the color picker and no way to set up a short list of fonts. Customizer is badly in need of its own Customizer so non-technical users can control how it works.

        We should not lose sight of the fact that Customizer has great potential to be a “killer feature” that will propel WordPress into an even more dominant share. Customizer can empower non-technical creatives to design websites with no need for coding. This will eliminate the need for many basic themes and shift the emphasis of future theme developers from design to structure and function.

      • I never stated Customizer was exciting. Its not. But it is suited well to its task. IMHO here’s what it needs. The ability to spring a modal from choices within sections and a fairly rich set of JQ controls allowable for use in the modal. Nothing “over the top”.

        In as far as mySQL goes, different discussion. Oracle bought it for several reasons.

        The general public consensus was they didnt want it end up competing against Oracle in enterprise, which… anyone who works in enterprise already knew thats simply ridiculous. mySQL is not up to the tasks and types of features needed in industries where Oracle dominates.

        “The truth:”

        “As part of the negotiations with the European Commission, Oracle committed that MySQL server will continue until at least 2015 to use the dual-licensing strategy long used by MySQL AB, with proprietary and GPL versions available. The antitrust of the EU had been “pressuring it to divest MySQL as a condition for approval of the merger”. But, as revealed by WikiLeaks, the US Department of Justice and Antitrust, at the request of Oracle, pressured the EU to unconditionally approve the merger. The European Commission eventually unconditionally approved Oracle’s acquisition of MySQL on 21 January 2010″

  7. I love the Customizer, and I love the decision to require it. For end users, there are no downsides. When I was new to WordPress, I spend hours learning theme-specific settings panels. When I switched themes, that time had been wasted. I honestly thought those panels were a part of WordPress.

    The people upset by this decision are the ones who make themes filled with spammy options panels. That is it. There are no other losers in this decision.

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.