Should WordPress Themes Add a Top-Level Admin Menu Item?

WordPress has almost always provided a top-level admin menu item for themes. It is clearly labeled “Appearance.” It is the single location that all WordPress users know to visit to modify any appearance-related things for their WordPress site. However, there is a movement within the Themes Team to allow themes to place an additional top-level menu link in the admin. The big question: should this idea move forward?

When the Themes Team (originally called the Theme Review Team) was formed, its members created a set of guidelines that would be shaped and reshaped over the years. They were a set of living guidelines that could always be changed with the times.

One of the oldest guidelines required that themes must place any custom admin pages under the Appearance menu item. It made sense. WordPress provided a standard location for any theme-related pages. The custom header and background features lived under Appearance. Widgets, also defined by the current theme, were housed as a sub-page. Eventually, WordPress’s custom nav menu system came along and was — you guessed it — situated under Appearance. The core developers even put the customizer link in the same place.

For over a decade, there was a well-defined standard. Sure, commercial themes outside of the official directory would sometimes break the mold. However, themes from the directory followed the pattern.

Now, the Themes Team is proposing that themes should be able to break from tradition.

The discussion arose after a question of whether themes should be able to add a custom panel to the block editor sidebar, which is not allowed.

“To keep the editor free from clutter, advertising and upsell, with the customizer being used less, and no dashboard widgets being allowed, can we give theme authors a better place to include their information, and limit upsell to that area?” wrote Carolina Nymark in last week’s team meeting notes.

The proposal seems to settle on the idea that themes will lose visibility as WordPress moves toward full-site editing and the customizer becomes less important. The customizer is not an ideal place for anything but theme options, but that notion seems to have been overlooked in the discussion. Nevertheless, the original guideline that disallowed themes from creating top-level menu items preceded the advent of the customizer by several years. Advertising, documentation, plugin recommendations, and similar pages were always allowed under the existing Appearance menu. The usefulness of the customizer was never a necessary part of that conversation.

Ultimately, the question should be about what is best for users. There is no data to support making the change or sticking with the status quo. However, we do have a standard that has existed for years.

The Proposed Guidelines

The proposal would create several new guidelines for theme authors to follow and reviewers to check, assuming the theme created a top-level admin menu item:

  • No admin menu priority may be used.
  • No UI or color changes are allowed for the menu item.
  • The title must be kept short and not include spam.
  • No more than three sub-pages.
  • Child themes are limited to one sub-page or can remove the parent’s pages and add its own.

Some of these make sense and follow along with existing guidelines, such as not spamming or changing the admin UI. However, others could be problematic.

If moving forward with the proposal, setting a menu item priority should be required rather than not allowed. If anything, it would make sense to require a specific priority to place the custom menu item immediately after the existing Appearance item. This would at least group them together by default. If changing the place where users are accustomed to seeing theme-related pages, it is probably best not to break too far from the standard location.

No more than three sub-pages? Surely there will be a theme with a top-level admin menu item that needs four sub-pages at some point. If giving theme authors the freedom to take up valuable real estate in the admin, a limit of three sub-pages seems like a rule to fix the mistake of allowing the top-level item in the first place. It is an arbitrary number at best. There would be no reason to cap it once making the guideline change. It also adds one more item that the team will need to police.

The limitation of sub-pages for child themes seems just as arbitrary. No such limitation exists when placing sub-pages under the standard Appearance screen.

The entire proposal is little more than extra work on a team that is already strained for resources.

Instead of the simple rule that has existed for years, the proposal adds a new rule with several sub-rules. If the team desires the extra work, I suppose this point doesn’t matter.

The Elephant in the Room

There is one aspect of this discussion that everyone knows about but few are willing to broach. Underneath all the guidelines from the Themes Team and whether most theme authors support a particular decision is how this affects the financial bottom line. When we talk about visibility of a theme’s admin pages, we are primarily talking about providing another avenue for commercial upsells.

Some of this discussion on visibility is shrouded in concepts such as surfacing end-user documentation or adding a visible readme for the user’s benefit. These are legitimate concerns, especially when theme developers have watched tickets to address such downfalls seemingly dwindle into obscurity over the years. Whether a top-level admin menu item makes sense for exposing theme documentation might be worth discussing, but there is no world in which this would be the primary use case.

The topic of visibility rests on the idea of upselling the pro version of the theme, add-ons, or other services.

Far too many plugins already go overboard, creating a billboard of the WordPress admin. One of the things users could almost be assured of is that themes from the official directory were constrained enough that they were not the hot mess that plugins have become as of late. However, that could all change.

Do we really want an extra top-level admin menu item that will be, for all intents and purposes, to advertise?

Maybe it doesn’t matter in the end. Users are so accustomed to the clutter produced by the dozens of plugins on their sites. One more may not matter at this point.

Or, should we be having a different conversation altogether? If this ultimately boils down to advertising, are there ways we can open this up for theme authors while still creating a user experience that keeps the WordPress admin free of clutter?

Gutenberg Times to Hold Live Q&A on Block-Based Themes and Full-Site Editing

On Friday, June 26, Gutenberg Times will be holding a live Q&A on block-based themes and full-site editing. The Zoom webinar will begin at 18:00 UTC and last for around one hour, depending on how many questions are asked by viewers.

The target audience of the event will be theme developers or anyone interested in designing using the upcoming system that relies on blocks to build the entire front end. To attend, viewers should register via Zoom. By registering, Zoom will send viewers reminders about the event and allow them to ask questions to the panel. The session will also be streamed live via the Gutenberg Times YouTube Channel.

Birgit Pauli-Haack, the owner of Gutenberg Times, is hosting the event. The following developers from the WordPress theming community will join her on the panel:

  • Eileen Violini – Design Engineer at Sidetrack Studio and Customer Success Engineer at CastosHQ.
  • Carolina Nymark – WordPress Themes Team representative and creator of the Full Site Editing Course.
  • Kjell Reigstad – Designer at Automattic who works on the Gutenberg project.

“I find the four-people-Brady-Bunch-on-screen format the most appealing and gives people the opportunity to get their questions answered,” said Pauli-Haack.

Friday’s event will begin with a five-minute demo from Reigstad. The goal is to show how theme authors can create a page header and footer by taking those concepts and applying them to a block-based theme. It is an introduction point that theme authors can use in their existing themes without starting from scratch.

The second part of the event will center on answering questions that Nymark often gets from other developers, such as how to put block code within template files. Reigstad will be showcasing demos based on those questions.

“After that, it’s all about the audience questions that I will read and the panel answers,” said Pauli-Haack. “The discussion and demo are all conversation starters. In other Q&As, after introductions, I had my own questions, and then made it all about the audience questions.”

Potential viewers can watch past Q&A events from the Gutenberg Times archive to get a feel for the format.

There is no set direction for the event beyond showing the initial demos. Pauli-Haack wants to put the audience in the driver’s seat and allow the discussion to go wherever it needs to go. The panel is open to exploring all aspects of building themes with blocks, and it is a good opportunity for theme authors to communicate with developers who are at the forefront of the transition into full-site editing.

“I have the feeling it will be more about how to transition from the old way to the new way and how all the pieces fit together,” she said. “Beyond the demos, there probably won’t be many code examples. We will discuss the resources out there and how to approach them.”

Gutenberg Times is in its third year of sharing information about the Gutenberg project. Pauli-Haack describes it as her passion project. “The goal has been to collect all the fragmented information while Gutenberg was in beta before the release in Dec 2018,” she said. However, the site has continued going beyond its initial phase. Pauli-Haack has been holding live Q&As since 2018 on the site.