Meeting notes – Themes team representative and theme authors

On 22 Sept 2021, @kafleg from the themes team organized a call with Nepali theme authors. The main purpose of the meeting was to discuss the new requirements.

At first, the themes team would like to thank all theme authors for their attendance and valuable suggestions.

In this post, I am going to share what we discussed during the meeting. We went through the requirements one by one and discussed them.

AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). ( requirements

Theme authors want to remove the accessibility requirements. Currently, we have Skip Links, Underline Links, and Keyboard Navigation as accessibility requirements. One theme author says, “there is already an accessibility-ready tag for themes. These requirements should only apply to the accessibility-ready themes. Or, we can add a new tag for this case”.

Allow design based blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. in themes

Theme authors want to add design-related blocks in themes. Currently, custom blocks are not allowed in themes. They suggested “If we are allowed to have design-related widgets, why not custom blocks? If we are allowed to add custom blocks, we can make even better themes using blocks. The available blocks are not well enough to make the design better”. “Making a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the Plugin Directory or can be cost-based plugin from a third-party for custom blocks and recommending is a solution but it’s not better”, they added.

Give priority to the block-based theme

Theme authors said, “The themes team needs to find a proper way to encourage theme authors who want to make block themes. Either by making a new tab in the themes repository or using other methods. With that, we can see more block themes”.

Affiliate Links

Allowing affiliate links is a good move. However, they are concerned about the number of links they are allowed to add.

Bundled demo file in the theme

The theme authors want to include bundling demo files in the theme. “It will make the usage of theme simple. Users can import the demo data directly from the theme instead of installing recommended plugins”, they said.

Suggestions from theme authors

They suggested switching the popular and latest themes tab in the theme repository to give more exposure to the new themes. They said, “The themes team is giving more priority to the popular themes instead of new ones. If a new theme is not getting exposure, theme authors will be discouraged from making more themes and the number of submissions will be reduced”.

“Reducing the requirements is not the ultimate solution for increasing the theme installation. If themes are more functional, easy to use, and perfect in design, the number will increase”, they added.


The rest of the requirements are fine to them. Theme authors want to get more exposure and more flexibility in the requirements.

Note: The session was held in the Nepali language and it wasn’t recorded.

Block-based Themes Meeting Agenda: October 6, 2021

Below is the agenda for this week’s Block-based Themes meeting.

Time: Wednesday, October 6, 2021, 10:00 AM EST

Channel: #themereview


  • BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.-based theme updates in GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc.
  • Open Floor / Q&A

Please comment if you have any specific topics you’d like to see discussed! #agenda #meeting #block-based-meeting

The performance impact of using jQuery in WordPress themes

While it has been widely known that you might not need jQuery for most of your interactive theme features, jQuery is still a common JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. dependency found in WordPress themes – for example, 7 out of the 11 default themes since Twenty Ten are using jQuery in the frontend. jQuery has been bundled in WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. for more than a decade, and it has been the most used JavaScript library across the web for a long time. However, it became popular when browsers were still very inconsistent in their JavaScript implementations and feature sets, and jQuery made it easy to navigate that. But the browser landscape has significantly improved over the past decade, and as of today there is little benefit of using jQuery, especially when using just jQuery core. If you are using jQuery UIUI UI is an acronym for User Interface - the layout of the page the user interacts with. Think ‘how are they doing that’ and less about what they are doing. or other extensions that provide user-facing features, migrating away is likely to be more complicated – but it is still worth looking into lighter non-jQuery alternatives for those libraries.

Using jQuery in WordPress themes may not seem like a problem from that perspective – after all, it still offers some useful utility functions, and some developers may be more familiar with using jQuery than with vanilla JavaScript. However, there is a real negative performance impact from using jQuery, which is especially relevant when using it for the frontend of a website where it can harm end user experience. Since the frontend of a WordPress site is primarily driven by themes, they play a substantial role in eliminating this performance offender.

You may be familiar with the recommendation to not use jQuery for performance reasons, but maybe you haven’t seen any evidence yet. To dive deeper into the topic, I recently conducted an at-scale analysis looking at popular WordPress themes, to see whether jQuery is in fact a notable performance offender or whether it is all just some myth – TL;DR it has a significant negative impact on performance. In this article I will share the results of the analysis and outline ways to reduce usage of jQuery in WordPress themes, so that we can enhance performance across the web.

jQuery is the most common JavaScript-based performance problem in themes

I ran an analysis using the PageSpeed Insights API, gathering performance reports for the most popular 100 WordPress themes according to the The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. Themes APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.. The first interesting aspect to look at was finding out how many themes of those even use jQuery and whether it is in fact as widely used as believed. And yes, the reports flagged jQuery as by far the most notable JavaScript file that leads to performance issues, in 76 of the 100 themes. The table below shows the most flagged WordPress core JavaScript files commonly loaded by themes.

#WordPress core JS fileNumber of themes flagged out of 100 themes tested

Looking at these results, there are barely any common JavaScript offenders in themes except for jQuery. Of course this doesn’t mean that jQuery is the worst performance offender of them all, but it shows that it is a significant common problem, which can be fixed.

jQuery usage in themes correlates with worse LCP performance

After establishing that jQuery is a common performance problem, the next step was to quantify how bad its negative impact actually is. For this purpose I inspected the Core Web Vitals (CWV) metrics results for each theme, most importantly the Largest Contentful Paint (LCP) metric, which focuses on loading performance. Across all the 100 themes, the average LCP value of themes using jQuery is 65.6% worse than for themes without jQuery (4,585.14ms for jQuery themes vs 2,769.74ms for non-jQuery themes, a lower value meaning faster loading performance). Of course jQuery is by far not the only aspect that factors into LCP, and the performance between different themes varies greatly. Yet, the at-scale analysis shows a clear correlation indicating that removing jQuery from a theme will bring a performance boost.

It may be argued that themes using jQuery may only be slower because their interactive features are more complex or extensive than those in themes without jQuery. While this is partly true, looking at the byte weight cost of JavaScript flagged by the performance reports shows that for many themes the problem really is jQuery itself: In 48 out of the 76 themes using jQuery, the cost of jQuery is even higher than the cost of all other JavaScript combined. This is summarized in the figure below: On the left it has the themes with the highest amount of non-jQuery JavaScript code, where the relative cost of jQuery is less extreme, but this applies only to a few themes – for most themes, the cost of jQuery is higher than the cost of all other JavaScript code combined.

For a few themes with large amounts of JavaScript, jQuery only plays a minor role in audit byte weight, but 48 out of the 76 themes using jQuery have jQuery account for more byte weight problems than all other JavaScript combined.

Removing jQuery may lead to 80% less JavaScript load

The at-scale analysis already shows how substantially jQuery usage can affect performance, specifically in themes where it is loaded only for a couple of rather basic interactive features. In order to get a better idea of what this means in practice, I took a deeper look at two of those simpler themes in regards to interactivity, choosing the default WordPress themes Twenty Twelve and Twenty Fifteen. I modified all their frontend JavaScript files that depend on jQuery (1 for Twenty Twelve, 2 for Twenty Fifteen) to use vanilla JavaScript and then eliminated jQuery as a dependency so that it is not loaded. Those code changes can be found in two new WordPress core pull-requests, for Twenty Twelve and for Twenty Fifteen.

After modifying the theme, I ran comparison reports for both of them, with 6 test runs for each in order to get more accurate median results for the metrics. The results showed that the JavaScript byte weight of both themes gets reduced by more than 80% when not using jQuery (for Twenty Twelve it dropped from 47,797 to 7,457 byte, for Twenty Fifteen it dropped from 49,290 to 9,120 byte). The median LCP impact for the two themes is not as huge as when looking at the average difference between all themes (1.2% better for Twenty Twelve, 8.4% better for Twenty Fifteen), but it still showed as a consistent improvement across all test runs when not using jQuery.

The amount of JavaScript in Twenty Fifteen and Twenty Twelve gets reduced by more than 80% when eliminating jQuery.

Using vanilla JavaScript instead of jQuery

As mentioned before, especially using jQuery without any of its extensions as of today does not justify the negative performance impact its usage comes with. In fact this applies quite widely as 52 out of the 76 themes tested that use jQuery don’t use any of its extensions. jQuery extensions often offer complex features that may require a lot of code to manually recreate, but for themes that only use jQuery itself, migrating to use vanilla JavaScript instead should be a rather straightforward effort. This can be seen when looking at the WordPress default themes for example: The older themes (up to Twenty Seventeen) have been relying on jQuery for their frontend features, while the newer ones (starting with Twenty Nineteen) do not load jQuery in the frontend – a positive development, which also shows how little benefit jQuery provides for those scenarios, as the newer default themes in no way lag behind the older ones in its interactive features.

If you are developing a new theme or maintaining an existing theme that currently relies on jQuery, consider using vanilla JavaScript instead, especially if you do not intend to use any jQuery extensions. Websites like or posts like “Cheat sheet for moving from jQuery to vanilla JavaScript” are an excellent starting point for developers that would like to migrate code away from jQuery or that are more familiar with jQuery than vanilla JavaScript.

To provide a concrete example, a common JavaScript-based WordPress theme feature is using a button to toggle the navigation menuNavigation Menu A theme feature introduced with Version 3.0. WordPress includes an easy to use mechanism for giving various control options to get users to click from one place to another on a site. in mobile viewports. The example code below is inspired by how a lot of themes implement that behavior with jQuery, and below you find the same functionality using vanilla JavaScript.

Example: responsive menu using jQuery

( function( $ ) {
	$( '.menu-toggle' ).on( 'click', function() {
		var $menu = $( '.primary-menu nav ul' );
		if ( ! $ ':visible' ) ) {
			$( this ).addClass( 'open' ).attr( 'aria-expanded', 'true' );
		} else {
			$( this ).removeClass( 'open' ).attr( 'aria-expanded', 'false' );
	} );
} )( jQuery );

Example: responsive menu using vanilla JavaScript

( function() {	
	document.querySelector( '.menu-toggle' ).addEventListener( 'click', function() {
		var menu = document.querySelector( '.primary-menu nav ul' );
		if ( window.getComputedStyle( menu ).display !== 'block' ) { = 'block';
			this.classList.add( 'open' );
			this.setAttribute( 'aria-expanded', 'true' );
		} else { = 'none';
			this.classList.remove( 'open' );
			this.setAttribute( 'aria-expanded', 'false' );
	} );
} )();

For more concrete and real-world examples, feel free to inspect the aforementioned pull-requests to remove jQuery from Twenty Twelve and from Twenty Fifteen.

Migrating away from jQuery extensions

If you are using jQuery extensions, for example anything based on jQuery UI, migrating away may be less trivial, depending on the complexity of the feature that the extension provides. You may want to research alternatives not based on jQuery that offer similar functionality – if there is one that satisfies your needs, it may be worth migrating your codebase to it, as jQuery still adds some overhead compared to using vanilla JS. For example, Twenty Thirteen relies on jQuery-based Masonry, but it could easily use vanilla JS-based Masonry instead. It should be evaluated on a case-by-case basis though – for some complex use-cases replacing jQuery may not be feasible. Or it may not be worth the effort, for example if the vanilla JS extension that would replace the jQuery extension and jQuery core is not notably smaller or more performant. Yet, not using jQuery can always be considered the general recommendation.

Potential next steps in reducing jQuery usage

If you are a theme developer relying on jQuery, starting to look into migrating away from jQuery in your themes will be a great step to make your themes more performant and thus enhancing the user experience for all the sites that use your themes.
From a WordPress core perspective, there are a number of work streams that could reduce the usage of jQuery over time, one of them being to migrate all the older WordPress default themes away from using jQuery in the frontend, which has already started as part of the analysis, with a Trac ticket for Twenty Twelve and another ticket for Twenty Fifteen. Potentially WordPress Coding Standards PHPCS rules or the WordPress theme checker could be enhanced to warn about usage of jQuery, making clear that it is discouraged. Maybe further down the road jQuery could even be marked as deprecated in WordPress core? 🙂 Let’s not get carried away, but if not before, now is a great time to start replacing jQuery with vanilla JavaScript in your WordPress themes (and plugins too, if you use it there). If you have alternative ideas, questions, or concerns, please share them in the comments.

Props @tweetythierry, @clorith, @jonoaldersonwp, @desrosj for review and proofreading.

#jquery, #performance

Theme upload survey results & next steps

As most of you should know by now, for the last six weeks we’ve had a survey running on the themes upload page to get feedback on how theme authors would like to upload updates to their themes in the future.

The primary purpose of the survey was to determine what the preferred method of uploading themes would be, as the ZIP upload is often touted as a pain point in the entire process.

Thank you to the 256 people who submitted feedback. I’m going to summarise the results here for transparency and the next steps the MetaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. team are going to take.

As can be seen below, the preferred method is to continue with ZIP Uploads, followed by GitGit Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Git is easy to learn and has a tiny footprint with lightning fast performance. Most modern plugin and theme development is being done with this version control system. GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. integration, Direct SVNSVN Apache Subversion (often abbreviated SVN, after its command name svn) is a software versioning and revision control system. Software developers use Subversion to maintain current and historical versions of files such as source code, web pages, and documentation. Its goal is to be a mostly compatible successor to the widely used Concurrent Versions System (CVS). WordPress core and the released code are all centrally managed through SVN. access, and finally “anything other than ZIP, SVN, and GIT”.

Reading the free-form feedback, there’s a two main things that caught my attention:

  1. Not everyone uses GitHub (or even a VCS), and didn’t want to see that be the only option.
  2. Some who preferred GitHub, suggested that SVN was the second best option.

It’s clear that for some authors ZIP uploads are preferable, There are no plans to remove this. But it’s also clear that many others wish to use a version-control system of some form to automate releasing updates – to remove the need to create a ZIP and upload it manually.

Next Steps

Here’s the suggested immediate plans forward:

  1. Enable theme updates to be submitted via SVN. #5899-meta
  2. Remove TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub. tickets for theme updates.
  3. Create/Encourage the creation of a GitHub action, to automate releasing from GitHub to The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization.

I’ll create Trac tickets to track these once everyone has had a chance to review this post, and given me a chance to clarify any points.

Enabling access to SVN

Enabling access is straight forward, but processing updates from SVN is not as easy. We’ve determined that the simplest way to make this happen is to require some very specific rules be followed:

  1. Updates must be stored in a `/THEME/VERSION/` structure similar to the existing use.
  2. Once an update is committed, it cannot be changed or altered in any way – even just to fix a typo.
  3. Versions must be in a standardised format, and must be higher than an existing version.

Themes.svn would be used as a “deployment destination” rather than as the primary location of development for a theme. One commit per version. No Trunk folder. etc.

Remove Trac tickets for updates

By disabling the trac ticket creation for updates to existing live themes, we can reduce the noise in Trac and focus it on being Theme Reviews, while at the same time simplifying the process for importing from SVN.

Git/GitHub integration

The PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the Plugin Directory or can be cost-based plugin from a third-party directory doesn’t have any Git/GitHub integration, but there is a 3rd-party supported action which allows for Plugin authors to have GitHub tags/releases be pushed to the plugins SVN repository automatically. Git-svn is also used by some here to keep everything within their own Git repository.

By enabling SVN access for themes, we’re opening the possibility of a similar action to be created, and leaving the door open for a future iteration where GitHub is built directly into the Plugin & Theme directories.

Thoughts? Concerns?


Themes Team Meeting Agenda for September 14, 2021

Channel: #themereview | Time: Tuesday, September 14 2021, 15:00 UTC

The themes team conducts a meeting on the second and fourth Tuesday of the month.
The meeting takes place in the #themereview channel on WordPress SlackSlack Slack is a Collaborative Group Chat Platform The WordPress community has its own Slack Channel at and you need an account to participate.

Along with the fixed agendas, we have an open floor at the end where you can ask or share anything related to themes.

We encourage all members and anyone interested to attend.

Meeting agenda

  1. Weekly updates
  2. Open floor

Weekly Updates

Current statistics can be found on: 

Themes TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub. ticket graph:

Check regular weekly updates here.

Also check,

Open floor

We will discuss everything related to themes. Attendees can ask or share themes-related things.

Please comment in the comment box below if you have anything to bring up during the open floor.

#agenda, #themes-team