Feature Packages Update

A couple of weeks ago, we set forth a theme feature packages proposal. The team got loads of good feedback. As the current lead for the proposal, I was trying to best think how to kick-start such a project. So, I decided to just tackle some low-hanging fruit that would provide a better idea of what this project is about.

The idea is to create “drop-in” packages that theme authors can use to handle some common features. This would help standardize some of the code we’re seeing.

I created two new packages, both of which I had some existing code to pull from. This provided us with a starting point.

Neither of these projects are at their official 1.0.0 stage. I’d like to get there this week or next at the latest. They need a code review and testing. So, this is an open call to check those projects out and leave any feedback.

Autoload Package

For feature packages, theme authors need a way to autoload any PHPPHP PHP (recursive acronym for PHP: Hypertext Preprocessor) is a widely-used open source general-purpose scripting language that is especially suited for web development and can be embedded into HTML. http://php.net/manual/en/intro-whatis.php. classes that we provide. I’d strongly recommend Composer instead of this package.

However, not all theme authors are ready to make that leap yet. If you fall into this camp, we put together a small PSR-4-compliant autoloader. This is a foundational package that will allow you to use any other packages that we create. You could even use it for autoloading your own theme classes if you choose to do so (assuming they follow the PSR-4 autoloading standard for class and folder names).

See the Autoloader repository →

Customize Section Button Package

This is a customizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. section that allows theme authors to create a link/button to any URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org. The idea behind this was primarily for pro/upsell links from the customizer. However, we kept it generic enough to handle any link and not limit it to only upsells.

See the Customizer Section Button repository →

Proposed Packages

There were a number of proposed ideas in the previous post’s comments and on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.. I’m going to list most of them with feedback for further discussion.

Standard Template HooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same.

This is a proposal to fork the original Theme Hook Alliance project or create something similar. The idea is to create a set of standard theme hooks that plugins and child themes can utilize.

Customizer Framework

This is probably thinking too big. We should break this down and look at tackling individual problems. What I mean by this is that we should build custom sections, controls, and/or settings classes that theme authors need as individual projects. One such example is the above “Customize Section Button,” which solves the issue of adding a custom “pro” link to the customizer.

If we have enough smaller packages at some point in the future, it’d be super simple to create a “WPTRT Customize Framework” that simply tells Composer to include all of our individual packages if that was desirable. However, I tend to lean toward themes only including code that they’re using.

Appearance > Theme Page

The idea here is to create a standardized Appearance > ThemeName page in the WordPress admin. My worry here is that this is far too theme-specific to do anything more than an abstract class that calls add_theme_page() and outputs a “template”.

I’d love to hear more about what we could standardize with this.


Not a bad idea. Not a bad idea at all.

Breadcrumbs are extremely tough to build and build right. I cringe almost anytime I see a custom breadcrumbs implementation because I see all the inherent flaws. I’ve built my own breadcrumbs system, and it’s quite a beast because it handles 100s of different scenarios.

This is an extremely complex problem to solve and would take a dedicated group of developers to tackle it.

Sliders and Sections

The proposal here, if I’m not mistaken, is for a standard customizer package that allows users to select exists posts, pages, etc. that could then be used in something like a slider or group of sections on the front end.

I think this could work as a package. Probably something along the lines of a repeatable post drop-down.

Mobile Navigation

A couple of different mobile navigation ideas were proposed. I’m not the best person to lead this charge. If there’s someone with the right CSSCSS CSS is an acronym for cascading style sheets. This is what controls the design or look and feel of a site./JS skills to make a solution that could work as a drop-in for themes, this would be worth exploring.

Color Control with Transparency

A color control for the customizer with an alpha transparency slider. Sounds like a cool idea. I’d actually love to see an implementation of this.

CSS Custom Properties

I didn’t quite grasp what the actual proposal for this package was.

Nav Menu Walker

With this, I’m also not sure what the proposal is other than making sure theme authors test their themes.

#open-source, #projects, #trt