fidzu : WordPress

It's time to focus on the WordPress Importers.

I'm not talking about tidying them up, or improve performance, or fixing some bugs, though these are certainly things that should happen. Instead, we need to consider their purpose, how they fit as a driver of WordPress' commitment to Open Source, and how they can be a key element in helping to keep the Internet Open and Free.

The History

The WordPress Importers are arguably the key driver to WordPress' early success. Before the importer plugins existed (before WordPress even supported plugins!) there were a handful of import-*.php scripts in the wp-admin directory that could be used to import blogs from other blogging platforms. When other platforms fell out of favour, WordPress already had an importer ready for people to move their site over. One of the most notable instances was in 2004, when Moveable Type changed their license and prices, suddenly requiring personal blog authors to pay for something that had previously been free. WordPress was fortunate enough to be in the right place at the right time: many of WordPress' earliest users came from Moveable Type.

As time went on, WordPress became well known in its own right. Growth relied less on people wanting to switch from another provider, and more on people choosing to start their site with WordPress. For practical reasons, the importers were moved out of WordPress Core, and into their own plugins. Since then, they've largely been in maintenance mode: bugs are fixed when they come up, but since export formats rarely change, they've just continued to work for all these years.

An unfortunate side effect of this, however, is that new importers are rarely written. While a new breed of services have sprung up over the years, the WordPress importers haven't kept up.

The New Services

There are many new CMS services that have cropped up in recent years, and we don't have importers for any of them. WordPress.com has a few extra ones written, but they've been built on the WordPress.com infrastructure out of necessity.

You see, we've always assumed that other CMSes will provide some sort of export file that we can use to import into WordPress. That isn't always the case, however. Some services (notable, Wix and GoDaddy Website Builder) deliberately don't allow you to export your own content. Other services provide incomplete or fragmented exports, needlessly forcing stress upon site owners who want to use their own content outside of that service.

To work around this, WordPress.com has implemented importers that effectively scrape the site: while this has worked to some degree, it does require regular maintenance, and the importer has to do a lot of guessing about how the content should be transformed. This is clearly not a solution that would be maintainable as a plugin.

This strikes at the heart of the WordPress Bill of Rights. WordPress is built with fundamental freedoms in mind: all of those freedoms point to owning your content, and being able to make use of it in any form you like. When a CMS actively works against providing such freedom to their community, I would argue that we have an obligation to help that community out.

A Variety of Content

It's worth discussing how, when starting a modern CMS service, the bar for success is very high. You can't get away with just providing a basic CMS: you need to provide all the options. Blogs, eCommerce, mailing lists, forums, themes, polls, statistics, contact forms, integrations, embeds, the list goes on. The closest comparison to modern CMS services is… the entire WordPress ecosystem: built on WordPress core, but with the myriad of plugins and themes available, along with the variety of services offered by a huge array of companies.

So, when we talk about the importers, we need to consider how they'll be used.

Getting Our Own House In Order

Some of these problems don't just apply to new services, however.

Out of the box, WordPress exports to WXR (WordPress eXtended RSS) files: an XML file that contains the content of the site. Back when WXR was first created, this was all you really needed, but much like the rest of the WordPress importers, it hasn't kept up with the times. A modern WordPress site isn't just the sum of its content: a WordPress site has plugins and themes. It has various options configured, it has huge quantities of media, it has masses of text content, far more than the first WordPress sites ever had.

In my view, WXR is a solid format for handling exports. An XML-based system is quite capable of containing all forms of content, so it's reasonable that we could expand the WXR format to contain the entire site.

Built for the Future

If there's one thing we can learn from the history of the WordPress importers, it's that maintenance will potentially be sporadic. Importers are unlikely to receive the same attention that the broader WordPress Core project does, owners may come and go. An importer will get attention if it breaks, of course, but it otherwise may go months or years without changing.

It's quite possible to build code that will be running in 10+ years: we see examples all across the WordPress ecosystem. Doing it in a reliable fashion needs to be a deliberate choice, however.

What's Next?

Having worked our way down from the larger philosophical reasons for the importers, to some of the more technically-oriented implementation problems; I'd like to work our way back out again, focussing on each problem individually. In the following posts, I'll start laying out how I think we can bring our importers up to speed, prepare them for the future, and make them available for everyone.

18 Jan 2021 12:25am GMT

In December, Mapbox shocked its open source contributor community with the news that Mapbox GL JS version 2.0 would be released under a proprietary license. The JavaScript library powers interactive, customizable vector maps on many high profile websites like CNN, The New York Times, Ancestry, Strava, Shopify, Facebook, and more. Older versions remain open source but Mapbox will only be investing in developing new features for the proprietary version going forward.

Multiple parties started their own forks immediately following Mapbox's announcement. In an effort to avoid fragmentation, the community worked together to merge their ideas under one project. One month later, MapLibre GL is now the official open source successor to Mapbox GL JS. The project's founders represent a diverse group of companies who relied on the open source software, including MapTiler, Elastic, StadiaMaps, Microsoft, Ceres Imaging, WhereGroup, Jawg, Stamen Design, and more.

"In December 2020, Mapbox released the second version of their JavaScript library for publishing maps online," MapTiler founder and CEO Petr Pridal said. "However, this time all the new features were overshadowed by a change in the license: previously free as in freedom, it became closed for external contributors and usage was restricted to people with active Mapbox subscriptions. One has to pay even for loading this JavaScript library."

Pridal said the MapLibre project name is a shortened form of "Map library restarted (or reinvented)," with libre referring to freedom and independence. Its founders agreed that MapLibre should be provider-independent, so developers can load maps from their preferred providers or self-hosted maps.

The community-led fork may also become home to MapLibre GL Native, as contributors are considering a proposal to put MapTiler's open source fork of Mapbox's mobile map SDKs for Android and iOS under the MapLibre umbrella.

Mapbox is used by WordPress.com as well as in Jetpack for the Map block. The library is also used in many plugins on WordPress.org, some with tens of thousands of users. Plugin developers who have integrated Mapbox GL JS version 1.13 or older will want to check out the MapLibre project as an open source alternative to Mapbox's proprietary 2.0 update.

15 Jan 2021 11:51pm GMT

Around 2010, child theming had finally caught its stride. Bigger theme shops were starting to take note, and some were implementing advanced parent themes that were meant to serve as a "framework" for creating child themes. The theme development community hit a bit of a brick wall amid this explosion of child theming. Grandchild themes became a topic of debate.

One of the use cases for child themes was to protect customizations made by end-users. When the parent theme was updated, those changes remained intact within the child theme. Users could get bug fixes and enhancements without worry. It was an ingenious system.

However, another use case for child themes was to create vast customizations of the parent theme. Many of these child themes were marketed and sold to end-users. The problem? There was no way for users to protect their customizations if and when the developer updated the child theme. WordPress had no grandchild theme concept or any other sort of cascading theme system beyond the parent-child relationship.

So, the problem remained. Unsolved.

Some businesses such as StudioPress and its Genesis parent theme thrived over the years with this system. Others moved along. In reality, child theming became a niche feature that WordPress never expanded upon in any meaningful way. Theme authors were left to their own devices. With the arrival of the customizer and the expansion of page builders, code customizations almost disappeared. Most modifications were handled via an interface launched from the WordPress admin. The average user had little need to DIY their way through custom templates. Thus began child theming's drizzle into near obscurity.

Gutenberg's site editor, which will likely land in WordPress this year, had seemed to be the upcoming final blow to the child theming paradigm. Everyone from developers to end-users will be able to roll out custom templates directly from the WordPress admin.

However, should we be rethinking the role of a hierarchical theming system?

Full Site Editing is already introducing an extra level to the hierarchy. Traditionally, WordPress theming had a two-tier template hierarchy. In the future, it will add a tier for user-created templates. If that is possible, why not go ahead and throw in grandchild themes? Or, simply do away with such arbitrary limitations altogether?

A new pull request to the Gutenberg repository essentially creates a multi-theme system. Or, rather, it creates a multi-theme templating system. Aside from the style.css, functions.php, and theme.json files, block-based themes are essentially a collection of templates.

The patch is proposing that users should be able to opt into this multi-template system. They would have the option to keep templates from an old theme around when they switch to a new one. While not currently implemented in the pull request, he also proposes allowing users to clone templates from their old theme.

"In recent months, there have been whispers around the future possibility of multiple themes being active, templates being 'themeless,' etc.," wrote the patch creator. "This branch is an implementation of that. The idea behind this implementation is there can only be one active theme at a time, but the wp_theme taxonomy can be used to link up individual templates / template parts with one or more themes at a time."

It does not fulfill the dreams of a decade-old grandchild theme system. However, it could provide some precedent for exploring a full hierarchical theme system.

With the simplification and further standardization of how themes work, we should be dusting off old ideas and shoving them into a new light.

Full Site Editing will eventually solve the grandchild theme problem regardless of whether it had intended to. With the new tier of custom user templates, the upgradability problem created years ago will simply disappear. Users will be able to readily update their parent and child themes without fear of losing customizations. WordPress will safely store their custom templates in the database. It will even keep their design changes via the Global Styles system. Maybe, just maybe, child themes will begin to reach their initial height of popularity.

With the proposed system, users could mix and match templates from unrelated themes. If this happens, it begs the question of whether theme templates are even necessary.

Last year, Rich Tabor opened a discussion on the possibility of a single master theme for WordPress. In that system, WordPress would create a set of base templates. Theme authors could simply override the pieces that they wanted. They could even pare themes down to simple style.css and theme.json files.

That almost seems to be a recipe for bland and boring themes. However, if you couple it with a template directory on WordPress.org similar to what GutenbergHub has already introduced, users could pick and choose the templates they want. It could be both wondrous and disastrous, but I would not mind exploring the idea.

WordPress and its Gutenberg project have a lot of options on the table. Theme building could become interesting in the next year or two.

Update: some names have been removed from this post at the request of the people in question. While this is not standard procedure, they were removed because they were not integral to the story in this instance.

15 Jan 2021 9:04pm GMT

If you haven't yet tested the Gutenberg team's progress on the full site editing (FSE) project, WordPress developer Carrie Dils has created a blueprint for Local that makes it easy to jump right in. Full site editing is phase 2 on the Gutenberg roadmap and is one of the main focuses for WordPress core development in 2021. (Check out What Is Full Site Editing and What Does It Mean for the Future of WordPress for a more in-depth look at why it is critical for end users to provide feedback during its development.)

Local is one of the most popular free development tools for WordPress that allows users to set up new testing sites with one click, along with a host of more advanced features. Blueprints make it possible for users to save any site as a Blueprint so that it can be used as a quick start setup option later. The blueprint includes all files, databases, config files, and Local settings. Dils' full site editing blueprint includes the following:

• Gutenberg plugin (with "Full Site Editing" experiment enabled)
• WordPress theme experiments (these are themes with support for full site editing) with the Twenty Twenty-One Blocks theme enabled
• Gutenberg test data (demo blog posts that use the most common Gutenberg blocks)

Follow Dils' instructions for downloading and installing the FSE blueprint on MacOS or Windows. Local does not yet have an easy way for installing and sharing blueprints to other Local users, so you will need to add it to the right place within the application's files. If you find that you don't have a Blueprints folder, it may be because it is hidden or because you have never created a blueprint before. Once the zip file is in the right location, you will see the full site editing blueprint among the advanced options when you set up a new site:

Once your site is set up, you can start exploring the brave new world of full site editing. (Be prepared - it is far from production ready but FSE is at a critical time in its development where it needs testing from real users to be a success.) The Gutenberg plugin may need to be updated to the latest. Your new site editing playground can be launched from the Site Editor menu item.

On the frontend you will find the Twenty Twenty Blocks theme activated. You can also test using the Twenty Twenty-One (TT1) Blocks theme, which was added to the WordPress.org Themes directory today, or any of the other experimental block based themes included in the blueprint. Click around, explore the template browser, try editing the template parts, change the global styles, and see how it's coming along.

The current state of full site editing is rough. It's hard to tell a feature from a bug at times, but once you get familiar with navigating it you might consider joining the FSE Outreach Experiment. This is an effort to test different aspects of site editing in order to ground the interface in real world feedback as it is developed. For the past few weeks, contributors have been testing the interaction between editing a post versus editing templates.

Anne McCarthy posted the first call for testing to the Make Test blog with instructions for participants.

This call for testing is designed to explore the interaction between the two editing experiences (post vs. template editing) to make sure it's clear when you're editing each, granular saving works properly, etc. Ultimately, being able to edit templates like index, single, or archive directly is a huge leap forward compared to what's been possible in the past! Unlocking this level of customization gives you far more control to build the site you want and this call for testing is to help ensure it's as intuitive as possible.

The second testing challenge should be published soon. Anyone can contribute by following along with the test script and leaving comments on the post or logging them as issues on GitHub. Participants are also invited to join the #fse-outreach-experiment channel on WordPress Slack for updates or questions regarding testing.

15 Jan 2021 8:21am GMT

Nick Diego's Block Visibility is not the only plugin to take on the challenge of controlling when blocks are visible on the front end. Other plugins like EditorsKit do a fine job of it. However, Block Visibility is a solution users should not overlook, even if they have already begun testing other options.

Diego first released the plugin in August 2020. Since then, he has added routine updates that have added value without shifting its focus.

One of the biggest reasons to use this plugin is that it is a standalone project. It is purely about doing one thing and doing it well. Its settings are all about giving users complete control over how they want to manage block visibility. From my experience with it, the plugin does its job better than alternatives.

It may not have a large number of installs, but if its five-star rating on WordPress.org is any indication, it at least has a happy user base.

Diego does have plans for a pro add-on. The tentative release date is set for Spring 2021. He seems to be moving forward with that launch after adding some foundational code in the recent version 1.4 release.

"As Block Visibility grows, there will be advanced and/or niche functionality that will be useful for certain users," wrote Diego in the 1.4 release announcement. "Think integrations with other third-party plugins. There will always be a free version of the plugin but some of these additional features will ultimately be provided by a premium (paid) add-on called Block Visibility Pro."

In my previous job, one of my primary products focused on membership solutions. There is a seemingly endless number of possibilities that users dream up to control content visibility. I have little doubt that a pro add-on is necessary for catching all of the edge cases.

How the Plugin Works

Block Visibility is easy to use. End-users click a toggle switch, select from a date-picker, or tick a radio box. Their blocks are shown or hidden on the front end based on their selections. It does not get much simpler than that.

The plugin adds a new "Visibility" tab for each block, which displays the visibility controls. The exception to this is for inner blocks. For example, the Columns block has controls, but the inner Column blocks do not. However, this can be enabled for inner blocks via the "Full Control Mode" on the plugin's settings screen.

There are three primary types of options:

• Hide the block from everyone.
• Time-based start and stop dates for displaying.
• Visibility by user role.

Block Visibility's controls in the inspector.

Hiding the block from everyone might be useful for users who are testing on a page or for blocks that are a work in progress. Start and stop dates create the potential for drip or trial content on membership-based sites, especially when combined with the role-based visibility options.

These basic options will cover the majority of scenarios that the average user will need them for.

One of the nicer features of the plugin is that it adds a transparent gray overlay, dashed border, and icon to each block that has visibility options set. This is shown when the block is not selected in the editor. It is one of those small touches that make the plugin useful.

Overlay for blocks with visibility options.

There is one confusing piece of the UI. There are two instances where there is a "public" option. That label immediately makes me think that the block should be visible to everyone. However, reading the description is necessary. These options are for showing content to logged-out users only. I would rather see these two options renamed to "logged out" for clarity.

A Promising Future

While Block Visibility is a solid plugin right now, we are barely scratching the surface of what will be possible in the long run. In version 1.4, released two weeks ago, Diego added preliminary compatibility with Full Site Editing. This means visibility options will no longer be confined to the post or page content.

"Once every piece of content on a website is a 'block,' you will be able to easily control the visibility of practically anything on a WordPress website," wrote Diego in the version 1.4 announcement post. "From dynamic navigation menus to user specific headers and footers, the possibilities are endless!"

Gutenberg's site editor is a beta feature right now, but the plugin's integration seems to already work well. I ran a quick test to show a custom nav menu to shop customers only. I had no problems on my end.

Setting visibility options for a menu in Gutenberg's site editor.

Users will not be limited to such basic needs in the future. Imagine showing ads in a sidebar to logged-out users. Imagine adding a time-sensitive holiday sale banner in the header. Imagine designing a homepage template that displays different content to subscribers vs. visitors.

There are ways to do all of this today by piecing various plugins together, using custom shortcodes, or writing code. However, when an entire site is made of blocks, you only need one method to control anything's visibility. Literally.

14 Jan 2021 10:23pm GMT

Yesterday, Francesca Marano opened a proposal for changing the phases of the core WordPress release cycle. It was a recap of a discussion the began in October 2020. The goal is to align the platform's phases with the larger development industry standard.

Aside from naming, WordPress has mostly followed the software industry in how it tackles its release cycle. Following a well-known convention can make it easier for developers outside of the WordPress ecosystem to transition into it. It would also allow developers to follow cycles of other projects, many of which are WordPress dependencies. This sort of standardization is generally viewed as a good thing throughout the software development world.

Based on the ongoing discussions since October, there is a consensus on renaming the phases to align with the standard. The following table shows what each phase would be renamed to:

However, this is a two-part proposal. Simply renaming the phases does not change how the release cycle works. To follow the standard strictly, WordPress would need to change when code is committed too.

How To Handle the Beta Phase

There is one point of contention with how to handle the Beta stage. The standard calls for no additional code changes other than new bug fixes introduced earlier in the cycle. For the WordPress project, this creates a problem.

WordPress will be 18 years old this year. Over the years, it has racked up a ton of older bugs. These are often fixed later in the cycle, sometimes during the Beta stage. These older bugs may not have been a part of the Preliminary Planning phase, but does that mean they should wait until the next release to go in? Strictly following the proposal, they should be put on hold.

It would also introduce a hard freeze on any enhancements set for the release but incomplete.

"I worry that we aren't allowing space for older bugs that aren't specific to the planned features in the release," wrote Josepha Haden in a comment on the initial discussion. "I also worry that by calling hard freeze earlier in the process we narrow the window for feature inclusion too much. I don't like limiting ourselves to feature specific bugs right now, since that excludes so many of our volunteer contributors. It's harder to work on features since they are complex and fast-moving, and older bugs present more opportunities for casual contributors."

On the flip side, there is potential that a bug fix could introduce new, unforeseen bugs. The later it is added during Beta, the less likely such bugs are noticed before the General Release phase. Waiting for the next cycle provides more time for testing.

One of the benefits of this system is that almost no new bugs would be created during Beta. This would allow volunteers to shift more efforts to testing and fixing issues that emerged in Alpha.

WordPress has always marched to the beat of its own drum. It can more closely follow standards while breaking free from strict confines when it makes sense to do so for the project. Beta-stage bug fixes not intended for a particular release could be handled on a case-by-case basis. We have people in leadership positions who are capable of making these calls when they arise. With automatic updates for minor releases, I am less concerned about late-stage bugs.

Tonya Mork proposed two solutions for defect work to continue in and around the release cycle. Both would require that WordPress branch off at Beta, providing contributors an avenue to push forward fixing bugs.

The first proposal calls for an earlier feature freeze, providing two or three weeks before Beta 1. This period at the end of the Alpha phase would be solely dedicated to defect work.

The second solution moves this defect work to overlap the previous release's Beta and Release Candidate. This allows work to continue during the time between major releases. It could also shorten the overall major release cycle.

This second solution is also consistent with Joost de Valk's thoughts on handling defect work. "I think we should just branch off earlier, and keep trunk open for normal business," he said on the proposal. "That way, everything can be worked on all the time, but it won't be included in the next release depending on when you commit it. That's fine, every piece of open source software I know in the world works like that, except for WordPress."

Many plugin and theme developers already find it tough to keep up when changes drop in the Beta or Release Candidate phases. Having a clear and defined point where changes land will benefit the extension ecosystem, also helping end-users in the long run. This second solution would do that.

There is nothing wrong with combining both solutions either. Since the plan would be to branch off at the Beta phase, the second solution is already in place by the act of branching. The real discussion is over whether the project should dedicate a block of time during its Alpha stage that focuses purely on bug fixes.

Comments on the proposal are open through January 20 before moving toward a final decision.

The next proposal: semantic versioning, anyone? Anyone? Is this thing on?

13 Jan 2021 9:52pm GMT

WPScan, a security company that maintains a database of WordPress vulnerabilities, has been officially designated as a CVE (Common Vulnerability and Exposures) Numbering Authority (CNA). The company joins 151 organizations from 25 countries that participate in the CVE Program as CNAs. These organizations are authorized to assign CVE Identifiers (CVE IDs) to vulnerabilities within their own distinct scopes of work, contributing to CVE's list of records for publicly known security vulnerabilities.

WPScan's scope includes WordPress core, plugin, and theme vulnerabilities. The company has catalogued more than 21,905 vulnerabilities since 2014 in its database, which it makes available to the community through an API. That API is also used by the WPScan Security Scanner plugin, which is installed on 5,000+ websites.

Being designated as a CNA helps WPScan better manage WordPress vulnerabilities by assigning them unique IDs that are recognized across the industry.

"Asking MITRE to assign CVEs for each of our vulnerabilities would have been too time consuming in the past," WPScan founder and CEO Ryan Dewhurst said. "Although some security researchers will go through this process directly with MITRE, we didn't due to the volume of vulnerabilities we have to manage. And security researchers only requested them themselves very rarely. The new process means that we ourselves can assign CVE numbers directly to vulnerabilities. This will result in many more WordPress related vulnerabilities being assigned CVE numbers."

WPScan is a team of three security researchers who come from penetration testing backgrounds and have worked within security consulting for the past 10 to 15 years. The company started with a simple Ruby script in 2011, which identified vulnerabilities in self-hosted WordPress sites. For the past two years, Automattic has sponsored the company's efforts in maintaining the database, as WPScan has transitioned to become a sustainable business by selling access to its API.

Dewhurst said the company's customers include "some of the biggest security plugins and hosting companies in the world," but many of them don't advertise the fact that use a third-party to source the vulnerabilities. Most of WPScan's enterprise customers are security plugins, companies, and hosts that integrate data from the vulnerability database into their own products and services.

"Our business is doing well," he said. "Right now we are trying to find the right balance between being a business and making money, while also benefiting the community as much as possible."

13 Jan 2021 8:52pm GMT

Google has launched a new Search Console performance report for sites that appear in Google News. Publishers can now track clicks, impressions, and CTR for traffic coming from news.google.com and the Google News apps for Android and iOS.

The report helps publishers see how often their articles appear to users in Google News and which ones performed the best. It also includes breakdowns for countries, devices, and dates to give publishers a better overall understanding of how visitors are interacting with their content through Google News. Although the date period defaults to the last three months, the data only goes as far back as December 15, 2020.

In the past, publishers had to submit their sites to be eligible for inclusion in Google News but the policy changed in 2019. Sites are now automatically considered for Top stories or the News tab of Search as long as they "produce high-quality content and comply with Google News content policies."

This new report does not include stats from the News tab on Google Search. That information was added in July 2020, when Google updated the Performance report section of its Search Console to allow publishers to filter by News. This screen also lets users compare different traffic sources, i.e. Web vs News to see the impact of articles showing up under the News tab.

The new report can be grouped by dimensions to get more specific information with different combinations of date ranges, reader locations, devices, and pages. For example, you can get a detailed look at clicks, impressions, and average CTR on a per country basis. This can also be filtered for one certain article to explore more narrow branches of the content's reach.

Publishers who are using AMP will want to note that this new report includes data from the canonical URL. If you have multiple versions for different devices, the report contains data for both:

Data will only be shown in the property that contains the canonical URL. Therefore, if you have both AMP and desktop versions of a page, the desktop property (which is usually the canonical property) will contain all the data for both AMP and desktop clicks, impressions, and CTR.

Google has published a help document with more information on configuring the report, data discrepancies, and how to filter and compare data across groups.

13 Jan 2021 3:54am GMT

I would like to ask, what is the best way to learn to create WordPress themes from scratch? I would like to learn, but there seems to be no comprehensive resource for this.

Thanks for any help.

Mark

I have been around the WordPress community long enough to remember the days when there were sparse resources available. Those who were just starting out with theme development 15 or more years ago usually resorted to hacking away at an existing WordPress theme. Budding theme authors were building upon the shoulders of those few giants who had already taken the first steps. It was the magic of open-source at work - development learned through the act of forking.

Maybe it is the way I learned. Perhaps it is part nostalgia for those early days of going down an unknown path and arriving at the other side with a creation of all my own. But, I still believe the best way to learn any type of development cannot be found in documentation or books (says the co-author of a development book).

It is learned through trial and error.

It is learned through hours of mangling a project and not stopping until you fix it.

It is learned through sheer force of will, fueled by some innate passion within you that wants to see a project through. It is frustrating, but you keep going because you are having fun.

The best developers I have had the privilege to work with were not always the most knowledgeable. They were seemingly natural problem solvers. However, they did not awake one day with this ability. They earned it through years of tackling real problems.

First and foremost, the best resource for learning to build themes is an existing WordPress theme. Any of the default Twenty* themes are great starting points. Choose one, start making changes via your code editor, refresh your browser, and see what happens. Read the code. Look for patterns across various files.

You will not learn theme development overnight. It will probably take a few months before you are building basic themes from scratch. It will probably be a year before you are actually good at it. However, everyone is different. The amount of time you put into it is a factor. Your preexisting development knowledge and skills can change that. Sometimes, your innate gifts and ability to learn play into it. But, you will get there with a bit of effort.

I will be honest. The old-timers here in the community, those of us who started out early in WordPress's history, had some help. Tung Do, known as Small Potato at the time, wrote one of the most comprehensive tutorial series on theme development the community has ever had on his now-defunct web design blog. It was an invaluable resource for several years. It was the answer to the missing documentation that everyone was asking for.

Theme development was also far simpler during that time. With a handful of files and templates, you could build something special.

Today, the landscape is much different. If you want to be competitive as a theme shop owner or build custom solutions for clients, you need a broader skillset. Even as a hobbyist, you need to pick up a few more things than you would have a decade and a half ago.

There is good news: the community is teeming with useful resources.

Traditional vs. Block-Based Themes

The theme development market is nearing an inflection point. WordPress will be introducing more and more tools for Full Site Editing in 2021, and this trend will continue in the years beyond. Traditional theme development will be around for a while - likely a few more years. However, block-based themes are the long-term bet. While there is some crossover between the two, they are entirely different systems.

Realistically, you will need to learn both methods, especially if you have financial motives for going down this journey.

However, you should learn traditional theme development first. This will make it easier to transition down the road. There are far more resources available too.

Another issue with learning block-based theme development as a starting point is that you may not know whether you are at fault if something is broken. The features that make up Full Site Editing are in a rough beta stage. The experience is still a partially broken one. Beginner theme authors should not pile onto what can sometimes be a frustrating experience.

It is time to start reading about Full Site Editing and testing block-based themes like Q and Block-Based Bosco. Then, wait for others as they become available in the theme directory.

Resources to Begin Theme Development

Many people will point you to starter themes, command-line scripts, and other automated tools for kick-starting your theme development journey. However, there is no substitute for building a solid foundation.

I will assume you have some basic or intermediate HTML and CSS knowledge under your belt. If not, you should learn to build simple web pages first. Again, there is no substitute for building that foundation. It will carry you through as you get into more advanced topics. Knowing some basic PHP helps too. However, you can hack your way through your first WordPress theme with just WordPress "template tags," which are technically PHP functions that sound less scary.

Your go-to resource should be the official theme developer handbook.

The breadth of knowledge available there was unavailable for those starting in the early days. You can build a WordPress theme from scratch by simply following along each page in the handbook.

While it was written in 2012, ThemeShaper has a 17-part tutorial series on developing themes from start to finish. With a few exceptions, most of the information in the tutorials is accurate. The underpinning of traditional theme development has not changed much over the years. This includes basic concepts like templates, The Loop, and similar elements.

ThemeShaper's Theme Development category is a resource any theme author should be subscribed to. The team continues to post up-to-date tutorials on building themes. Recently, they have focused on block-based theme development. I am sure more tutorials are forthcoming as new features related to Full Site Editing unfold.

Of course, search engines are your friends. Run into a problem? I guarantee you are not the first with that specific problem. The solution is documented somewhere across the web.

If you want to begin block-based theme development, you will need to install the Gutenberg plugin for testing. Your resources will be limited. You will need to be a pioneer, mowing a path for others to follow. It will be a rough trek, but it also offers adventures that others have not taken.

WordPress's block editor handbook has a guide on creating block-based themes. It makes some assumptions about your knowledge level in terms of theme development. Carolina Nymark, one of the Themes Team representatives, has a site called Full Site Editing. It includes an extensive course that is worth taking. There is also the Theme Experiments repository for testing what some people are currently building.

My strongest recommendation is to learn through trial and error while using documentation as a backup when you get stuck. Start playing around with Twenty Twenty or Twenty Twenty-One, the two most recent default WordPress themes. Make changes. Get yourself in trouble and break things. Learn by getting yourself out of whatever hole you have dug. Every failure is part of your path toward success. Most of all, enjoy it.

Now, I will throw this question out to our readers, many of whom are theme authors themselves. Will you share you tips, tricks, and resources for someone who is just starting to build themes?

12 Jan 2021 9:58pm GMT

I wanted to share with you all a short film I made with the help of Stephen Bollinger, with videos I made a few years ago on a photography trip to Iceland with Om and Mark. I hope it provides five minutes of serenity in your day.

12 Jan 2021 9:46pm GMT

WordPress' block editor, colloquially still widely known as Gutenberg, is making inroads into the segment of users who have heavily relied on page builders for years. For the most part, page builder plugins have either declined in growth or stagnated in 2020, with the exception of Elementor. In contrast, block collections with page builder features are gaining more users. Performance is becoming an important factor in this migration.

In a post titled "Damn. Gutenberg Smokes Elementor," Kyle Van Deusen published benchmarks from his experience building a simple landing page using Elementor and then Gutenberg.

"Like any Elementor user, I've become increasingly anxious about the future of Elementor and just how bloated it is," Van Deusen said. "I think Google PageSpeed Insights agrees."

After recreating the same design with Gutenberg and GenerateBlocks, Van Deusen saw a small difference in GTMetrix scores.

GTMetrix scores: Elementor vs Gutenberg

He found the most profound difference when testing with Google's PageSpeed Insights, where Elementor scored 46% on mobile, and 83% on desktop.

"Because I've had such poor luck getting any kind of decent scores with Elementor sites (especially on mobile), I've given up using this tool," Van Deusen said. "Not because it's not a valuable metric (in fact, it may be the most valuable since this is how Google sees things), but because there wasn't much I could do about it."

In contrast, the page built with Gutenberg gave him a 94% score on mobile and a 99% on desktop.

"In terms of performance, straight out of the box; Gutenberg absolutely smokes Elementor," Van Deusen said. "However, each time I've taken Gutenberg for a spin, I've left frustrated. As soon as I feel like I'm getting the hang of it, eventually the wheels come off and I'm back to installing Elementor.

"But when your PageSpeed Insights scores go from 46% to 94%, it's time to perk up and pay attention."

Van Deusen said it took him more time to recreate the design in Gutenberg and he had trouble with mobile views. At the moment, he doesn't see switching as an advantageous move for his business.

"While I think we can conclusively say, at least for performance, Gutenberg is the clear winner - it's just not at a point where a guy like me can jump ship," Van Deusen said.

"Gutenberg is fun to play with, and I enjoy dreaming of the day when it's viable for me- but I like to put food on my table. Elementor still helps me do that more efficiently."

In another experiment, WordPress developer Munir Kamal rebuilt Elementor's homepage in Gutenberg to compare the HTML markup both page builders generate. The page built with Elementor includes 356 div's in the markup vs 77 for Gutenberg. Kamal found that Elementor generated 796 lines of code vs Gutenberg's 206 lines, resulting in a difference of 99kb vs 28kb respectively.

In August 2020, DearHive, the makers of the DearFlip WordPress plugin, left CodeCanyon to sell plugins from their own site. DearHive's company site was built with Elementor, but suddenly Google ranking mattered for their product site now that they were selling independently from CodeCanyon. Deepak Ghimire, a software developer at the company, cited performance as the chief issue that impacted their ranking and drove them to switch to Gutenberg.

"Our page speed went from 83 with Elementor to 98 with Gutenberg," Ghimire said.

Page builder plugins may still have more features at this point in time, but performance is becoming a critical consideration for those who are doing business online. In May 2021, Google plans to introduce a new ranking signal for Search, based on page experience as measured by Core Web Vitals metrics. Performance is an important part of delivering the kind of scores necessary to pass the Core Web Vitals assessment. This ranking signal update from Google may compel even more site owners to migrate away from slow page builders.

For the past two years, WordPress users have been asking if Gutenberg will replace page builders. It looks more and more likely if the most popular ones remain bloated alternatives and the smaller ones keep on the same trajectory of attrition. It won't happen overnight, but it is bound to accelerate when full-site editing makes its debut in WordPress core.

For those who build websites for clients, the best way to future-proof your skills is to learn how to build pages within the framework of the block editor and, if you can, learn how to build custom blocks. It's also a good time to be experimenting with different block collections to streamline your setup so that you don't have to sacrifice high performance in order to build sites efficiently.

12 Jan 2021 4:15am GMT

I turn 37 today. I look around and I feel incredibly lucky to be writing this after a topsy-turvy year. I have health. I have friends whom I love. These are all good reasons to feel optimistic about the future. A few unconnected thoughts today:

My father had me when he was exactly 13,300 days old, and this year I passed that number of rotations of the Earth.

It's hard to plan when so much is changing, so resolutions this year haven't felt the same. But in times like these it's even more important to plan for the long-term. A look back, once a year, is enough to remind of what remains.

I'm so thankful for the internet. It's where I learned and practiced my trade. It's where I connect every day with the most interesting and eclectic group of people I could imagine, a modern day Florence during the Renaissance. I hope to make a lot more internet and enable others to do the same.

Many years ago I said "Technology is best when it brings people together." This quote has taken on a life of its own on motivational posters and images. When I first said it I think I had in mind WordCamps and meetups and other physical gatherings; this year it transformed for me seeing how technology brought together separated by the pandemic. This year has appeared divisive, so it's easy to overlook how many times people came together. It's like the old saying, it's not how many times you fall, it's how many times you get up. Fall thirty-six times, get up thirty-seven.

All birthday posts: 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37.

12 Jan 2021 3:07am GMT

Yesterday, Jack Kitterhing launched EatsWP, his new restaurant-related WordPress plugin. It is a menu creation system that works in the block editor. It also has a built-in QR code feature to work with customers' phones.

Kitterhing is the Product Manager at LearnDash. He is also the founder of Immerseus, a shop that builds plugins for the learning management system. He is now extending his reach with the founding of EatsWP. He contracted out the development work to a private freelancer with who he regularly works.

"Apart from that, it's just me on this project," said Kitterhing. "My other business, I have five full-time employees, and so if required, one of those could be brought over for support. We, myself and my friend, took this idea to launch in under a month, which I'm very pleased with considering that Christmas was in the middle as well."

Kitterhing decided to build this plugin based on what he was seeing with small restaurant owners he knew. Some of the issues facing these single-location restaurants are with their physical menus.

"It's expensive to update them or make any changes as it requires a whole new print run," he said. "By having a digital menu, they can update in minutes and generate a new QR code print. Then combine that with the current world situation, it also isn't very healthy to have everyone touching physical menus, so digital menus made more sense than ever."

Pricing for the plugin begins at $37 per year and increases based on the number of sites the user wants updates and support on. Kitterhing also offers a custom menu design and setup tier.

How the Plugin Works

Editing an EatsWP menu item in the block editor.

At the moment, EatsWP is a simple affair. The plugin does not offer hundreds of options or every feature imaginable for a menu-type of plugin. It is a 1.0. However, for the features it does provide, it does them reasonably well. Kitterhing is off to a good start. He has set a foundation, and the only way to go from here is up.

Where the plugin tends to shine is with its primary features, which are its array of blocks. Users begin by adding the Eats Menu block. From there, they have a selection of inner blocks they can place within the menu:

• Item With Picture
• Item With Picture and Addons
• Item Without Picture
• Item Without Picture and Addons
• Eats Section Heading

In reality, most of the blocks are just prearranged sets of existing core WordPress blocks. They provide structure and loads of color options. Plus, end-users can click a button to add a "New" or "Popular" tag to their menu items. It is a nice touch.

The color options offer some customizability. In the long term, users will likely want more design options. However, it may be prudent for the plugin author to follow core's lead here and implement such options as they become available in the block editor API.

The one missing feature that should be available now is support for wide and full alignments. Kitterhing assured me this would land in the first quarter of this year.

On top of the plugin's blocks, EatsWP allows end-users to generate a QR code for the page their restaurant's menu is on. When a customer scans the QR code with their phone, the page then opens.

"The QR code generation is more straightforward than most people expect," said Kitterhing. "We're using a well-known QR code generation library. You then simply select the page your menu is on, generate the QR code, print it off, or show it on your website and you're ready to go."

The Future of EatsWP

On the EatsWP website, Kitterhing lightheartedly writes that "delicious desserts" are coming soon. This includes WooCommerce integration, recipes, and other secret features. Integrating with WooCommerce could open a new avenue for restaurant owners to explore as part of their checkout process.

"I'm hoping that WooCommerce support will be coming Q1 this year," said Kitterhing. "As I'm sure you can imagine, it's reasonably technically challenging to incorporate this in a user-friendly way. The goal is to have all the connections and product creation actually done within the block editor interface. So someone wouldn't have to go off to WooCommerce to set a product and come back as that's rather long-winded. I'm excited to show everyone!"

It will be interesting to watch how this integration unfolds in the coming months. Menus are a solid starting point, but having a payment option is necessary in a world with more people are ordering online. This is especially true in the Covid-era where contactless forms of payment are becoming the norm for takeout. Restaurants need simple solutions that they are not hacking together from multiple, non-integrated sources.

"The goal within the next 12 months is to turn EatsWP into everything that a restaurant needs to offer a minimal-contact experience for customers," said Kitterhing. "Many restaurants don't have websites either, so I'm looking into a SaaS option where I'd host the menu/site for the restaurant."

11 Jan 2021 9:46pm GMT

photo credit: Glenn Carstens-Peters

WordPress' Community Team has been discussing the return to in-person events since early December 2020, and has landed on an idea that would allow local meetup organizers to determine readiness using a COVID-19 risk-assessment checklist. This would enable organizers to restart meetups when it is safe for their communities, instead of applying a blanket global policy.

Countries like Australia, New Zealand, The Bahamas, Iceland, and Vietnam, are a few examples of locations that are doing a decent job containing the virus. In contrast, the United States logged more than 4,000 coronavirus deaths in a single day this week, pushing the daily average to over 2,700. While the situation remains bleak for many areas of the world, vaccines are rolling out to vulnerable populations, albeit slowly and with a few snags.

In the previous discussion that happened in early December, WordPress lead developer Dion Hulse shared some feedback from Australian organizers who have been eager to restart their meetups.

"One of the problems faced in Australia (and probably NZ & Taiwan too) has been the blanket worldwide restrictions companies have put in place," Hulse said. "Australia/NZ have been lucky, the pandemic has been successfully contained - Australia has seen less than 30k cases this year, and NZ 2k cases. To put that in context, the USA has recorded more (detected) cases in 3 hours today than Australia did all year, and more in 30 minutes than NZ."

Hulse said a few Australian meetup groups were denied the go-ahead for restarting because of the global restrictions, which has "led to the abandonment of meetups once again (as online meetups have simply not worked here, as most people can still go out in person, so there's been no major push from most Australians to the online platforms like elsewhere)."

The Community Team's proposal for a checklist takes these more unique situations into consideration and allows organizers to move forward in areas where public health measures have adequately curbed the spread of the virus. A few example checklist items include the following:

1. Is your country's (or state's) average positivity rate over the past 28 days under 4%?
2. In the past 28 days, has your country or area's basic reproduction number stayed under 1?
3. In the past 14 days, have there been under 50 new cases per 100,000 people reported?
4. Does your local government allow for in-person events?
5. If there is a cap on the number of people who can meet at a time, will you as an organizer follow this guideline?

Contributor feedback so far includes recommendations for dealing with violations of the guidelines and assessing the need for contact tracing in case meetup attendees are exposed during an event. Cami Kaos recommended that the team share a list of locations that have already been vetted using the checklist and have not met requirements.

"My hope is that this would reduce a lot of duplicated time and effort for areas that we already know aren't yet, by the standards we're setting, safe," Kaos said. "It would save time and disappointment for organizers hoping to meet in person and also contributor time and energy for those deputies who will vet the applications to hold in-person events."

Since the virus is mutating and countries are adapting in different ways, the situation can change rapidly, so organizers would need to be prepared to roll back to online events if conditions for safe meetups deteriorate. WordCamps are still out of the question for the time being, but the Community Team is seeking feedback on the proposal by January 15, 2021, including additions to the checklist and recommendations for public health resources that could aid in guiding the process.

09 Jan 2021 4:50pm GMT

Of all the smart home upgrades I've made, replacing all my regular smoke detectors with Nest Protects (Google's smoke detector) has been the one that I regret the most.

I don't really need a smart smoke detector. It doesn't need to talk, connect to wifi, and cost hundreds of dollars. I don't need it integrated with my Google account which is impossible to share, so I need to be personally involved to replace one.

But other smoke detectors are just so unsightly, and the Nest is light years ahead of the competition from a design standpoint.

There's such an opportunity for something that looks as good as the Nest, but doesn't require two-factor authentication to replace. I didn't want to call it dumb but beautiful, so let's say "autonomous and beautiful" appliances and home devices. I still want it to be smart, but if you're going to have the risk profile of a device that connects to the internet, it needs to be worth it, like Brilliant, Sonos, smart TVs, or connected cameras.

I'm becoming more wary of any hardware that requires an app, just because of the natural decay of non-SaaS and non-open source software. Van Moof bikes are beautiful, but will they still connect well when iOS 24 is out and Bluetooth has been removed from iPhones for security reasons?

08 Jan 2021 11:45pm GMT

Twenty Twenty-One Blocks, now renamed to TT1 Blocks, is inching its way toward the WordPress theme directory. Kjell Reigstad mentioned the prospect in this week's block-based themes meeting. Contributors to the theme, which is part of the Theme Experiments project, have pushed some much-needed code updates to the repository.

TT1 Blocks is the block-based version of the Twenty Twenty-One theme. Its goal is to provide a version of the original theme that works with Full Site Editing (FSE), currently only available through the Gutenberg plugin.

FSE needs more testers. And, testers need themes that will enable the site editor in Gutenberg. Currently, there are only two WordPress themes, Q and Block-Based Bosco, in the directory that support the site editor. Armando should join them shortly. If a user attempts to find one via the FSE filter, they will get no results, as pointed out by Gary Taylor in a recent comment. This seems to be an oversight by the theme authors and should be corrected.

With most block-based themes relegated to a few GitHub repositories, it does not bode well if no one can find themes to test the most important set of features coming to WordPress in 2021. Users should be able to easily install an FSE-ready theme today.

"It has been brought up that it may be easier for people to test and contribute to full site editing if Twenty Twenty-One blocks was available in the WordPress theme directory," wrote Themes Team representative Carolina Nymark in a ticket about renaming TT1 Blocks.

TT1 Blocks is something that feels more official. While third-party block-based themes are needed, the officialness of something from core contributors gives more users a sense of trust. Plus, it would be easy for someone with .ORG administrator privileges to stick it to the top of the theme directory's featured page to get more eyes on it. Doing this with a third-party theme would unleash a hoard of developers who want the same treatment for their themes.

The prospect of the theme coming to the directory is something the WordPress project needs.

The volunteers who have been chipping away at this TT1 Blocks have turned a bare-bones theme into something closer to the original Twenty Twenty-One. There are still some leaps remaining to get it to where it needs to be. Much is this rests in the Gutenberg development team's hands. There are currently over a dozen blockers identified by the Theme Experiments project that need to be resolved in the Gutenberg plugin first.

Single post in the site editor with TT1 Blocks

There are multiple open tickets on the project board for theme developers who are looking for a way to contribute. This is an opportunity to learn more about block-based themes and pay it forward.

At the moment, I am not-so-patiently awaiting the release of TT1 Blocks to the theme directory.

There are days when I wonder if there is a final destination, some light at the end of this never-ending tunnel that leads to block-based themes being the norm. I get overexcited about each new project. I quickly test pull requests and updates on the handful of repositories I am watching, hoping for a glimpse of something spectacular.

Part of this excitement is because I designed and developed WordPress themes for around 15 years in some form or fashion. Today, I am no longer in the design and development game. I must live vicariously through the people who are putting untold hours into this grand experiment. I get to tell their stories, which has its own rewards.

I also know that this sort of development is a slog. Everyone has big ideas, but the real world calls for slow, steady, and dedicated work. Often it is thankless.

When I saw the mere mention of TT1 Blocks potentially coming to the theme directory, it added a bit of spark to an otherwise rough few days. I wanted to end this particular week with something hopeful. And, testing out the latest work those volunteers have put into TT1 Blocks has done just that.

08 Jan 2021 11:12pm GMT