WordPress.org

I was wondering if you could help me. I want to convert all of my old posts (about 600) to Gutenberg blocks. Do you know an easy way to do that?

Philip

I often get these short questions via private messages. I always try my best to help other WordPress users whenever I can. This was an easy solution in Philip’s case. After a quick chat, he actually learned that he did not need to migrate his posts to the block system. I thought it would be best to open this topic to a wider audience. Maybe it would help someone else along the way.

There is currently an open ticket on the Gutenberg repository for a bulk converter. It has sat dormant until a few days ago. The primary argument for including this feature in the plugin and eventually WordPress itself is that the lack of this option is an obstacle for newcomers to the block editor.

I disagree with the notion that it is any sort of obstacle for block-editor adoption. There does not seem to be a massive call for the feature in the WordPress support forums. Web searches do not pull up too many support queries for it. It seems to be a niche use case. Or, in some cases, there is a simple misunderstanding that end-users need to do any sort of conversion or migration at all.

However, the biggest reason it is a non-obstacle is that posts written in the classic editor are still basic HTML. Regardless of the editor, older content will output just fine on the front end, at least in most cases.

The first question anyone should ask before deciding on bulk converting their old posts to the newer block format is whether they should do it at all. The answer for the majority of users will simply be no. There are few reasons to do so.

Doing a mass conversion like this, especially with hundreds or more posts, is subject to broken sites. I have done enough single-post updates to know that the process does not always go smoothly. Sometimes, I need to touch up something here or do some manual changes there. On a large scale, there really is no way to know what got broken until you test every single post or page on the site. In some cases, everything is OK. In others, it is a nightmare.

If you are thinking of going down the bulk-conversion route, make a backup first. There is a good chance that you will need it. You should also test this on a staging site.

My recommendation for most users is to convert posts on an as-needed basis. I like to make the switch any time I edit an old post. The only reason I convert them is that I prefer working with the block editor over classic.

Posts written in the old editor will be in the Classic block. After selecting the block that houses the content, I hit the “Convert to blocks” button in the block toolbar. I do a quick check of anything that might need to be fixed before hitting the update button.

“Convert to blocks” button for the Classic block.

In most cases, there is no reason to convert old posts to blocks except when you are actually editing those posts.

Despite claims that things will “just work” when switching to the block editor, that is not the day-to-day reality of all WordPress users. Some of the biggest reasons I have seen to bulk convert are around theme design issues. For example, the block system made some fundamental changes to image markup. If your theme handles left and right-aligned images added via the block editor but breaks down on your old posts, bulk converting may be an option. However, the first course of action should be checking in with your theme author about adding support for the classic markup.

There are likely numerous other edge cases. Bulk converting posts is an invasive operation that can only be reverted by restoring a pre-conversion backup. It should be a last resort.

If you are at the point where you know you need to convert all your old posts, there are a few options available.

The Bulk Block Converter plugin is likely the most-used solution at the moment. Organic Themes released it a little over a year ago but has only updated it once. User reviews have been mixed. A few of the problems seemingly stem from WordPress — the plugin extends the core WordPress block converter used in single posts.

For those with clients who want to find a middle ground between bulk conversion and having the client manually convert their old posts, 10up’s Convert to Blocks plugin might be the right solution. It converts posts on the fly, only making changes when a user opens the post-editing screen.

Fränk Klein is also working on a PHP-based bulk converter plugin named Bulk Convert to Blocks. It is currently in the development stage and not ready for use on live sites. It offers a screen in the WordPress admin to perform the conversion and will continue working in the background if the user leaves the page. Because it runs via PHP, developers can extend it with custom actions and filters. It also provides a WP CLI command for those who prefer to work from the command line.

TasteWP is a newcomer among online WordPress sandboxing solutions. The site allows users to spin up a new WordPress instance in a matter of seconds. Web-based sandboxes like these have been popular for a long time, since they are convenient to fire up and destroy when performing a quick test on a plugin or theme. It’s easier than maintaining a local development environment, which many casual WordPress users have not taken the time to set up.

TasteWP’s temporary testing sites are hosted for 48 hours for non-logged-in users and 7 days for those who are logged in. The one-click setup gives you a random site URL and login credentials.

The free sites are limited to 220MB per instance. A successful set-up notice is displayed in the dashboard with information on when the site will be automatically deleted. TasteWP limits non-logged-in users to creating 2 sites and the limit is 6 for logged-in users. They can be removed or added within the site manager.

When creating a new site, the Advanced Options allows users to set up multisite, select a PHP version, WordPress version, and choose from a number of advanced configuration options and pre-installed extensions. The PHP version can also be changed later within the site manager.

TasteWP is reminiscent of the now defunct poopy.life service. In addition to the unsavory and unforgettable name, poopy.life was laden with obtrusive upgrade ads that floated across the screen periodically. TasteWP takes a different route for promotion and includes three of its plugins pre-installed on the default testing sites.

TasteWP is run by Inisev, a 15-person company that has been developing WordPress plugins for four years.

“Our key motivator for starting TasteWP was a) scratching our own itch (we needed a platform ourselves to try out new plugin versions on different WP/PHP version combinations) and b) promoting our products,” Inisev co-founder Nicolas Ahmann said.

“Having said that, if there is enough demand (and there seems to be), we’ll also offer very affordable premium plans for non-expiring instances with bumped space soon.”

Ahmann said the team is currently funding their projects from their own pockets as well as a few private investors.

“We had some VCs knock at our door recently, and while we don’t rule out taking them on board at some point in the future, we feel quite comfortable with our current approach where we grow organically (i.e. without too much ad spending),” Ahmann said. “I’m sure, if we had taken on a lot of capital a few years ago, we would have spent a lot of marketing budget on products which weren’t ready at the time. Instead, we were forced to make the products better. Limited budgets sharpen your mind immensely.”

Ahmann said the company has several enhancements planned for TasteWP, but they don’t want to make the product more complicated to use.

“We developed a Linux application which copies exactly the same moves as user would do to create a website, except that we’re omitting the front-end and graphics rendering parts which makes it much easier to process by the computer,” he said. “Also we inject anything that is needed into the database directly. That allows us to create those sites so fast without preparing them before (but still fully customized for each user).”

The company is planning to enable users to call specific URLs, such as https://tastewp.com?themeslug=slug-of-theme, which would spin up an instance with that theme or plugin already installed. This would allow theme and plugin creators to share the link with their potential users/customers so that they can play around themselves.

Localization is also a high priority for future TasteWP enhancements, since the company is based in Europe where many languages are spoken.

“We always felt that it doesn’t get the attention as it needs, considering that approximately 40% of websites are not in English,” Ahmann said. “It’s often just DIY people (not devs) who are trying to create their websites. We always encourage them to learn English (as it’s the world’s language). But imagine you grew up in Turkey, for example. Nobody around you speaks English – the teachers in schools only speak it in a broken way. In those cases it’s key that people can take their first WordPress steps in their language, and what’s easier to do so than spinning up an instance with one click on TasteWP which is in your language? Long story short: we’ll keep translating it into (many) more languages.”

Gutenberg 9.8 launched yesterday with a few minor UI improvements. The development team added an initial implementation for border-radius support for the Group block that theme authors can opt into. They also moved the site editor into an iframe element to remove CSS conflicts from the global admin styles.

Those who have been testing Full Site Editing should be pleased that they will no longer need to deal with the seemingly never-ending creation of auto-drafts for templates and template parts. Good riddance. They would have inevitably caused user confusion in the long run. The change took around a month of discussion and work, but it reduced a complex and fragile process into a more stable system for the long term.

While the previous plugin release saw barely more than a handful of bug fixes, version 9.8 jumped back to over two dozen. A Gutenberg update without at least that many just does not feel right.

Minor UI Improvements

The latest version of the plugin improves the UI when working with the Spacer block. When a user selected the block in the past, it appeared as a light gray rectangle. Now, it is semi-transparent. This allows whatever is in the background, such as the Cover block with a background image, to show. This change should help users more easily make size adjustments in cases where viewing the background is necessary.

Semi-transparent Spacer block when selected.

While I hope the Spacer block will eventually die a slow and agonizing death as it is replaced by more appropriate margin and padding block options, this change does help in the interim.

In a follow-up to the UI improvements in Gutenberg 9.7, work on block variations continues. Variations are when one block is used as the foundation to create multiple variations of the same block. The most common example is the Embed block, which has YouTube, Vimeo, and other variations. Before 9.7, these variations shared the same generic icon, name, and description in the block inspector and navigation instead of the variation-specific information.

Gutenberg 9.8 builds on the trend of using the variation’s data where it makes sense. The block switcher (transform) button in the editor toolbar now displays the variation’s icon.

Variation icon in use in the block switcher.

It is a small change, but it shows the development team’s continued devotion to polishing the editor interface.

Loading the Site Editor Canvas in an iframe

Gutenberg 9.8 separates the canvas area of the site editor into an iframe. This separation means that global admin styles do not bleed into or override styles within the editor itself. The good news is this is a first step toward doing the same in the post editor too.

This has been a change that I have been waiting for since the inception of the block editor. From a theme development and design standpoint, styling the editor to match the front end is ripe with issues. It has meant nesting CSS selectors when it should have been unnecessary. It has meant adding a few !important rules to overwrite what seems like oddities in the core CSS. While styling the block editor has improved by leaps and bounds in the past couple of years, it can still often be a pain.

WordPress core committer Ella van Durpe listed the benefits of moving the canvas into an iframe:

• There would be no admin CSS bleed at all. This is something we’ve been struggling with since the beginning.
• There would be no need to simulate media queries, which is arguably technically more difficult than using an iframe.
• Relative units like (r)em and vw/vh just work.
• For a full site, a theme stylesheet can be just dropped in the editor without any adjustment. I think this is important as it makes the life of theme authors much easier.
• It’s possible to have one selection per window, so one in the admin and one in the content. This is useful for e.g. the link UI where the selection in the content can be kept while the selection is also in an input element (for the URL). Maybe be useful in other cases.

While I find it tough to believe that theme stylesheets would just work without a hitch — does such a world exist? –, they should work far better than in the past. There are likely items theme authors will need to contend with, but they should be minimal. Developers should keep a close eye on the future development of this.

Border Radius Support for the Group Block

As part of Gutenberg’s experimental feature set, the Group block now supports a border radius option. However, end-users will not automatically see it in the block inspector. This is an opt-in feature for themes at the moment. Presumably, it will be a part of the default set of options for several blocks in the future.

Setting the border-radius value for the Group block.

For theme authors who want to add support, they will need to drop the following code snippet into their experimental-theme.json file and edit the radius value:

"core/group" : {
        "styles" : {
                "border" : {
                        "radius" : "50px"
                }
        }
}

This will allow theme authors to set the default border-radius for the group block. However, it will not hand over control to users. For that, themes will need to add the following snippet under the settings section of their experimental-theme.json file:

"border" : {
        "customRadius" : true
}

I tested this with a modified version of the TT1 Blocks theme without issue. Mostly, I am looking forward to more styling options like this in future iterations of the plugin.

WordPress is open source software, maintained by a global network of contributors. There are many examples of how WordPress has changed people’s lives for the better. In this monthly series, we share some of those lesser-known, amazing stories.

From a young age Thelma was encouraged by her father to ‘work hard, and dream big’. In High School, she pursued a career in Computer Science. She said: “I did not know what I would be doing or how I would get there but I just knew that I was going to pursue a career in information technology.”

She wrote her first line of code at the age of 16 living in Zimbabwe, Africa. This was to mark the beginning of her enthusiasm for computer programming.

When she joined the school’s computer class, Thelma thought she would learn Excel and Word. Instead, the assignment was to write her first program in C. She said: “It was not easy, but it was very exciting. l remember writing up simple code for a Video Club – a check-in/out for VHS tapes and CDs. Thus began my fascination with computers.”

Seven years later, she went on to university to study for a Bachelors in Business Management and Information Technology. Her third year internship was at a local web design and hosting company. Though she had hoped her placement would be at a local bank or telecommunications company, the chance to discover website design turned out to be the best thing that could have happened. 

In 2017, Thelma went on to work for a company designing websites using HTML, CSS, PHP, JavaScript and Joomla. She had heard about WordPress but had not used it. She recalls: “People have this misconception that WordPress is not for real developers and it is not secure and at that time I was one of those people.”

Finding a local community

From a discussion with a member of the local WordPress community, Thabo Tswana, about a striking swag gift from a WordCamp, Thelma’s interest was sparked. 

She started to find out more about WordPress and WooCommerce, and visited her local WordCamp Harare website. She was delighted to find that she could learn more about WordPress without needing any pre-existing knowledge, and wanted to be involved. So instead of just attending the camp, she volunteered too! 

Her response to her first WordPress event mirrors the experience of many others in the community. She said: “I only started using WordPress because of the awesome people that l had met at that WordCamp. Everyone was so welcoming.”

A week later, with help from Thabo, she designed her first website using WordPress.

She soon became more involved with the community and Meetups. Thelma participated in the first-ever ‘Women Who WordPress’ Meetup in 2018, with lots of women getting involved from bloggers to developers. 

She said: “We were free to talk and discuss a lot of things. We had more time to discuss the difference between WordPress.com and WordPress.org, we shared views on how to handle discrimination at work, how to promote your website and a whole lot of other things.”

Establishing roots in WordPress

In 2018, WordCamp Harare had its first-ever female Lead Organizer Tapiwanashe Manhobo. Thelma was part of the organising team that year and was assigned to handle Harare’s first Kids Camp to take place eight months later. You can read more about her experiences of organizing a Kids Camp on her blog.

She said: “After the first Kids Camp, we had several people in the local Zimbabwean WordPress community who were enthusiastic about encouraging young people to embrace ICT. In 2019, we had not planned to have a Kids Camp because of financial constraints but to our surprise, we had some anonymous donations and we managed to have a WordPress Community outreach to a youth centre, Centre for Total Transformation, a week after our WordCamp. It is a non-formal school that caters for underprivileged and vulnerable children. The group were able to share practical skills about using WordPress, computer hardware and software.

Thelma shares that she became hooked on WordPress because of its community. “I enjoy attending WordCamps, meeting new people and just learning new stuff. I have a huge list of WordCamps I would like to attend. Last year I managed to cross WordCamp Johannesburg off my list. When everything is back to normal my plan to travel to WordCamps will proceed (fingers crossed).”

Reaping the fruits of ongoing learning

Thelma is committed to ongoing development training. She said: “Even though I can still cook up code in C and Java, for now, I have also included WordPress PHP functions to the mix. It was not easy to get to this point, daring myself got me to this slightly better stage. I try to do my best where I can and I am happy to say it has paid off so far.”

Thelma has continued her journey working in design and digital marketing last year with Trust Nhokovenzo who works in digital marketing and is active in  the WordPress Community. He came across her name as a developer from talking with others involved in WordPress. She went to work with his team at a marketing agency.

Her interest in the development of WordPress continued and she joined the 5.6 Release Squad in the mid 2020. At the end of 2020, she moved to become a Happiness Engineer working with WordPress.com. Thelma’s fascination with the platform and the community continues to grow and her contributor story is ongoing.

Find out more about the Harare WordPress community in Zimbabwe.

Contributors

Thanks to Nalini Thakor (@nalininonstopnewsuk) and Surendra Thakor (@sthakor), Yvette Sonneveld (@yvettesonneveld), Abha Thakor (@webcommsat), Larissa Murillo (@lmurillom), Meher Bala (@meher), Josepha Haden (@chanthaboune), and Chloé Bringmann (@cbringmann). Thank you to Thelma Mutete (@thelmachido) for sharing her #ContributorStory.

This post is based on an article originally published on HeroPress.com, a community initiative created by Topher DeRosia. HeroPress highlights people in the WordPress community.

#ContributorStory #HeroPress

Gutenberg project contributors are considering implementing a stale bot to tame the repository’s overgrown issues queue, which currently has 2,733 open issues. Stale bots are usually employed to automatically close “stale” issues and PRs based on a predefined set of parameters for inactivity.

“The current recommendation is to set our policy to a 180-day of no activity, so if no comments or commits are on an issue or PR in 180 days, then the bot will post a comment to the issue alerting the user it will be closed in 7-days due to inactivity,” Marcus Kazmierczak proposed.

One important concern is getting the tone right for the automatically-generated message. When you’re employing bots on a widely used open source project, they had better be friendly. A chilly, indifferent bot can unwittingly turn away potential contributors with the wrong kind of messaging. Kazmierczak proposed the following message:

This is an auto-generated message to let you know that this issue has gone 180 days without any activity and meets the project’s definition of stale. This will be auto-closed if there is no new activity over the next 7 days. If the issue is still relevant and active, you can simply comment with a “bump” to keep it open, or add the “[Status] Not Stale” label. Thanks for keeping our repository healthy!

Participants in the discussion on the proposal are divided on the best approach. Daniel Llewellyn, one of the most vocal opponents to using a stale bot, contends that an automatically closing issues sends the wrong message.

“If we care about users and that they trust that we will fix their problem then automatically closing their issue gives them the signal that we don’t,” Llewellyn said.

“If you don’t want to fix a problem then it is better for a human to explain why the problem won’t be fixed and personally close the issue. Automating this on the assumption that because nobody has commented in a while means it isn’t important is bad!”

Joy Reynolds agreed with this assessment, noting that closing issues through any means can be discouraging.

“I’ve had issues closed by humans for being stale, also, and it isn’t any better,” Reynolds said. “I’ve had issues closed because someone created a new issue on the same thing. This loses all the history and the watchers.

“I’ve also had an issue closed at Launchpad for being stale (and their system used only two weeks as a time frame). That served no purpose at all. It only makes people go away, frustrated.”

Kazmierczak reiterated in the comments that the bot can be configured to skip issues labeled as bugs and that issues and PRs can be bumped to reset the 6-month clock.

“The overall goal of the proposal is to improve feedback and responses to issues by ensuring what’s there is relevant,” Kazmierczak said.

Auto-closing issues is the most controversial part of the plan. The general consensus in the comments leans towards using the bot for labeling and triaging in order to manually close the issue later.

“My preference would be for a bot to alert humans in a slack channel when a ticket is declared stale and become progressively more insistent until a human responds,” Peter Wilson said.

Milana Cap suggested using a bot to nudge the ticket author as a compromise between “being friendly and thoughtful to contributors while keeping maintainers sane.”

Whatever approach contributors land on, excluding tickets marked as bugs is going to be critical for making the stale bot productive. Otherwise, it becomes just a fancy way of kicking the can down the road, delaying the inevitable.

In a recent post titled “Github Stale Bots: A False Economy,” software developer Ben Winding wrote about why stale bots don’t deliver what maintainers are aiming to achieve. Based on his experience with the Angular repository’s bot, Winding summarized the stale bot’s effect on the issues queue:

1. Reduce the metric of Open Issues in github
2. Made duplicate issues far more likely
3. Increased friction of users reporting that the issue still exists
4. Ultimately decreased the quality of the software, as the issues don’t accurately reflect reality

If the Gutenberg repository’s stale bot can be configured not to close bugs and used to maximize human involvement, it will be less likely to deter people from reporting issues. Feedback on the proposal is open until January 29, 2021. Kazmierczak is seeking input on the bot’s implementation, specifically its time threshold and messaging.

After you’ve watched the amazing poem from Amanda Gorman, check out the new WhiteHouse.gov that re-launched today using WordPress & Gutenberg with a number of cool features including dark mode, text zoom, a totally responsive layout, and a Spanish version of the site. The site is clean, fast, and accessible. It’s exciting and an honor that the online home for the Executive branch is on Open Source software, and I’m proud WordPress can carry the torch that Drupal lit in 2009.

Besides Gutenberg, poking around I noticed a HTTP header and HTML comment encouraging people to join USDS, and this great #46 easter egg in the theme file:

Anyone notice any other plugins? I haven’t spoken to him directly but I’d be shocked if Nacin wasn’t involved with this one. I’m also curious if any of the WP agencies were involved, it has touches of 10up but I don’t see any mention of it on their site or Twitter. Hoefler&Co credits Wide Eye Creative with the design.

I noticed a few people happy that some previous pages and files on the old site were returning 404 errors, like the controversial 1776 report, but on this I think the webmasters of the United States of America should demand better, since Cool URIs Don’t Change. Previous websites are all saved by the National Archives, but there doesn’t appear to be any sort of norm for automatically redirecting links that went to any subdirectories or addresses under WhiteHouse.gov.

There are WP plugins that could help, like Redirection, but also perhaps the root domain itself could always redirect to a subdomain, like 46.whitehouse.gov, so we’d have a consistent domain and permalinks for everything, and then each new administration would get a new subdomain.

More coverage on WP Tavern.

President Joe Biden took office today and unveiled a new whitehouse.gov that has been relaunched on WordPress. The previous administration switched from Drupal to WordPress in 2017, and technologists working with the Biden administration decided to stick with the same CMS.

In keeping with the multilingual and accessibility features implemented on the Biden-Harris transition team website, whitehouse.gov launched with toggles for contrast and font size, along with a Spanish language switcher. The relaunched site also includes an accessibility statement with a commitment from the administration to work towards conforming to the Web Content Accessibility Guidelines (WCAG) version 2.1, level AA criteria.

Much of the content and design from the transition website has been preserved. The transition site now forwards to whitehouse.gov, while links to the previous administration’s pages land on a 404 page with a link to archived presidential websites.

Savvy observers might notice that the typography has been updated from the transition site, flipping the Mercury and Decimal typefaces. Hoefler&Co, the typeface design firm that created these typefaces for Biden’s 2020 campaign, tweeted about how “the serif Mercury felt more like the voice of the institution.” The sans-serif Decimal functions more in a supporting role on the site.

Web professionals kicked the tires a bit and noticed the site is putting up fairly decent Lighthouse scores.

Under the hood, code snoopers noticed an advertisement for the U.S. Digital Service (USDS), the group of technologists who maintain many of the federal government’s public-facing digital services.

In addition to the message from USDS, the site’s source code includes a link to the US government’s analytics program at analytics.usa.gov. Tim Lowden, who manages the federal government’s aggregated web analytics initiative, said this data has been made available for the first time since late 2017.

The analytics service records more than 2.5 billion pageviews across federal government websites each month. The data is available to the public, but it does not track individuals, and anonymizes the IP addresses of visitors. It shows information for visitors’ devices, browsers, operating systems, and location broken down into cities and countries. Many of those visiting the site today are from countries other than the U.S.

Back at the start of this series, I listed four problems within the scope of the WordPress Importers that we needed to address. Three of them are largely technical problems, which I covered in previous posts. In wrapping up this series, I want to focus exclusively on the fourth problem, which has a philosophical side as well as a technical one — but that does not mean we cannot tackle it!

Some services are merely inconvenient: they provide exports, but it often involves downloading a bunch of different files. Your CMS content is in one export, your store products are in another, your orders are in another, and your mailing list is in yet another. It’s not ideal, but they at least let you get a copy of your data.

However, there’s another class of services that actively work against their customers. It’s these services I want to focus on: the services that don’t provide any ability to export your content — effectively locking people in to using their platform. We could offer these folks an escape! The aim isn’t to necessarily make them use WordPress, it’s to give them a way out, if they want it. Whether they choose to use WordPress or not after that is immaterial (though I certainly hope they would, of course). The important part is freedom of choice.

It’s worth acknowledging that this is a different approach to how WordPress has historically operated in relation to other CMSes. We provide importers for many CMSes, but we previously haven’t written exporters. However, I don’t think this is a particularly large step: for CMSes that already provide exports, we’d continue to use those export files. This is focussed on the few services that try to lock their customers in.

Why Should WordPress Take This On?

There are several aspects to why we should focus on this.

First of all, it’s the the WordPress mission. Underpinning every part of WordPress is the simplest of statements:

Democratise Publishing

The freedom to build. The freedom to change. The freedom to share.

These freedoms are the pillars of a Free and Open Web, but they’re not invulnerable: at times, they need to be defended, and that needs people with the time and resources to offer a defence.

Which brings me to my second point: WordPress has the people who can offer that defence! The WordPress project has so many individuals working on it, from such a wide variety of backgrounds, we’re able to take on a vast array of projects that a smaller CMS just wouldn’t have the bandwidth for. That’s not to say that we can do everything, but when there’s a need to defend the entire ecosystem, we’re able to devote people to the cause.

Finally, it’s important to remember that WordPress doesn’t exist in a vacuum, we’re part of a broad ecosystem which can only exist through the web remaining open and free. By encouraging all CMSes to provide proper exports, and implementing them for those that don’t, we help keep our ecosystem healthy.

We have the ability to take on these challenges, but we have a responsibility that goes alongside. We can’t do it solely to benefit WordPress, we need to make that benefit available to the entire ecosystem. This is why it’s important to define a WordPress export schema, so that any CMS can make use of the export we produce, not just WordPress. If you’ll excuse the imagery for a moment, we can be the knight in shining armour that frees people — then gives them the choice of what they do with that freedom, without obligation.

How Can We Do It?

Moving on to the technical side of this problem, I can give you some good news: the answer is definitely not screen scraping. Scraping a site is fragile, impossible to transform into the full content, and provides an incomplete export of the site: anything that’s only available in the site dashboard can’t be obtained through scraping.

I’ve recently been experimenting with an alternative approach to solving this problem. Rather than trying to create something resembling a traditional exporter, it turns out that modern CMSes provide the tools we need, in the form of REST APIs. All we need to do is call the appropriate APIs, and collate the results. The fun part is that we can authenticate with these APIs as the site owner, by calling them from a browser extension! So, that’s what I’ve been experimenting with, and it’s showing a lot of promise.

If you’re interested in playing around with it, the experimental code is living in this repository. It’s a simple proof of concept, capable of exporting the text content of a blog on a Wix site, showing that we can make a smooth, comprehensive, easy-to-use exporter for any Wix site owner.

Clicking the export button starts a background script, which calls Wix’s REST APIs as the site owner, to get the original copy of the content. It then packages it up, and presents it as a WXR file to download.

I’m really excited about how promising this experiment is. It can ultimately provide a full export of any Wix site, and we can add support for other CMS services that choose to artificially lock their customers in.

Where Can I Help?

If you’re a designer or developer who’s excited about working on something new, head on over to the repository and check out the open issues: if there’s something that isn’t already covered, feel free to open a new issue.

Since this is new ground for a WordPress project, both technically and philosophically, I’d love to hear more points of view. It’s being discussed in the WordPress Core Dev Chat this week, and you can also let me know what you think in the comments!

The Full Site Editing (FSE) Outreach Program has now concluded its first round of testing. Its first focus area was centered on the template-editing mode introduced in Gutenberg 9.6. The volunteers involved with the project identified several pain points.

Gutenberg 9.6 added a new button that allows end-users, provided they are using a block-based theme, to switch between editing their post and the template that displays the post. As Josepha Haden said last year, the ultimate goal is to “consolidate down to just one beautiful, intuitive interface.” Essentially, this new feature merges content and design in a way we have not seen in core WordPress before. It is a step toward that lofty goal.

Traditionally, WordPress has always separated content from design. However, these two aspects of websites are continually merging together. There is a desire for this. The adoption of page builders over the last half-decade or so has made it abundantly clear.

The biggest issue with this new template mode is that users need a working knowledge of the WordPress template system to understand the ramifications of their edits. One of the primary questions of the focus area was whether it was clear that the user was making large-scale changes to all posts when switching to the template-editing mode.

“I believe it was not clear enough how those changes could impact the site,” wrote Héctor Prieto in response. “If you don’t already know how templates, template parts, and global blocks like Site Title work, you might not understand how your editing will affect the rest of the site.”

Switching modes does create a quick popup at the bottom left of the screen that reads:

Editing template. Changes made here affect all posts and pages that use the template.

It is easy to miss before it fades away. There is a ticket to stick this message on the screen and allow the user to dismiss it. There is also another ticket for clarifying when a user is editing a template vs. content.

Entering template-editing mode from the post editor.

Gutenberg’s current method is different than what you might see in a typical page builder. When switching to template-editing mode, the user is no longer editing that single post’s front-end output. Instead, they are making global edits. A page builder would generally save any customizations to that page alone. If this remains the same, it could be a hurdle for the average user to clear.

A template creation feature needs to be a part of this new mode. Users should be able to fork or clone their existing single post template and save it as a new template specific to that post. Or, maybe hand them a way to save it as a reusable template (i.e., “page” template). Paal Joachim Romdahl shared a similar thought, likening it to the “Save As…” feature commonly found in computer programs.

I do question whether users should be able to edit global templates while editing a single post. The two are only related insofar as the template displays the post content on the front end. WordPress should explore any type of design work from the post-editing screen as, first and foremost, specific to that post.

The volunteers also identified other issues. Applying changes to the template and saving drops the user back into the post editor. The “cancel” button is tough to find — it is in a different location than where the user clicked to go into template-editing mode.

Switching between post and template editing feels like an FSE 2.0 type of thing. The development team has enough issues on its plate with the normal site editor. It is a far cry from being a viable, production-ready product. The team’s focus should be on working the kinks out of that system before merging it with the post editor. Crawl before you walk. Walk before you run.

However, I am willing to be pleasantly surprised. In the long run, it will probably be a good thing that we are getting an early look at what these two different pieces of WordPress will look like working in conjunction.

This is also why participation in the FSE Outreach Program is vital. The community needs this more formal type of process to identify areas that need improvement.

If you’re looking to change careers into technology, WordPress is a great way to do it.

In 2013, I was in a career counselor’s office. Just realizing that I needed to change careers out of music, almost the only thing I had known for the last 20 years:

At NAMM in Anaheim, California

Aside from feeling like a huge failure, I knew I’d need a lot of luck to get a job.

Someone would have to take a big chance on me.

But there were a few problems.

I was terrified of talking to strangers, much less asking them big favors. And I had almost no traditionally useful skills.

Enter WordPress.

Lots Of Options

When you’re changing careers, you’ll want skills that will help no matter what you end up doing.

You don’t want to deep-dive into calculus and find out that it won’t help.

Learning WordPress is perfect.

If you get really interested in the technical side, you can be a JS or PHP developer.

If you really like content creation, that’s also great. You can start a blog or work in marketing.

If none of it interests you, at least you can help people set up a website as you look for another career.

So soon after meeting with the career counselor, I took Zac Gordon’s course on WordPress Theme Development.

I wrote a theme based on his course, and really liked how WordPress worked.

He taught me to build sites, and later write plugins.

Zac Gordon with XWP

Invite Yourself To The Party

The great thing about WordPress is that you can contribute right away.

With some careers, you need somebody to take a chance on you before you can do much.

To get experience as an investment banker or business consultant, you probably need to actually have the job.

But with WordPress, you can invite yourself.

You can open pull requests to Core or Gutenberg without anyone asking.

You can deploy plugins to wp.org that real people use, without having a college degree.

With this growing experience, I applied online to XWP.

Weston Ruter responded right away, and was really helpful.

I started opening simple PRs to “help” with the Customizer work.

In reality, my work might have slowed things down, and was really simple.

But I didn’t have to wait to be invited. I invited myself to the party, and one of the PRs was merged into Core.

Later, when I interviewed with XWP and got the job, I could show that I had a little experience working with other developers.

XWP At WordCamp US Contributor Day, 2017

It’s still embarrassing looking back at the work I did. But WordPress allows you to contribute, regardless of your experience level.

Years later, when I lived in Mexico City, one of my friends got interested in technology.

He was like me. He had a degree in an unrelated field, and wanted a great career.

So I showed him how much opportunity WordPress has.

He did something similar to what I did.

He opened PRs to an agency’s repos, and the agency asked him if he wanted to talk about a job, without him needing to apply. Years later, he’s still doing really well at his job.

I did very little, other than point him to a huge opportunity: WordPress.

Concrete Skills

Changing careers is really awkward.

You read about networking, which seems like you’re asking strangers for favors and sending spam DMs.

You also learn to reframe things as transferable skills.

So if you’ve done hard things, you can say you’re “comfortable with ambiguity.”

But with WordPress skills, you have more concrete skills to offer.

It’s less awkward explaining to someone why they should take a chance on you.

You’ve shown you’re committed to your career path by your portfolio of plugins.

And you don’t have to send spam DMs on LinkedIn.

In 2014, I went to my first WordPress meetup, WordPress Los Angeles. I was nervous, but I wasn’t trying to take any value.

I could even answer a few questions.

Renee Johnson and I met there. We even reunited in WordCamp Europe and Mexico City several years later when I lived there:

Yani Jimenez and Renee Johnson, Mexico City

With WordPress skills, you can flip from taking to giving value. Everything is much less awkward.

As you probably know, there are many self-taught developers in WordPress.

College degrees rarely come up in hiring conversations, at least in my experience.

And I’ve found WordPress very accepting of different career backgrounds. Matt Mullenweg was a musician, famously naming every release after a jazz musician.

People in WordPress are very understanding about changing careers.

Now, I don’t hide it, and it’s rarely more than a footnote in conversations.

Mentorship

Don’t go it alone.

It’s easy to think that you can just take online courses and eventually be ready for a job.

But code reviews are one of the main ways you’ll learn. And people in WP want to help.

If you contribute a few PRs to someone’s GitHub repo, they’ll probably do a quick code review of your own plugin or theme.

Weston was really helpful in doing a detailed review of my theme.

You also can learn a lot contributing to Gutenberg or other plugins.

They’ll give you detailed reviews. And you’ll basically get the same experience as if you were getting paid.

But if I were to do this again, I’d also look for more formal mentorship.

Hiring someone to review your plugins and themes would probably help.

Nothing To Fix

There’s a saying in marketing “what you can’t fix, you feature.”

In WordPress, you don’t have to fix your non-traditional career background.

The post Changing Careers Into WordPress appeared first on HeroPress.

While schemata are usually implemented using language-specific tools (eg, XML uses XML Schema, JSON uses JSON Schema), they largely use the same concepts when talking about data. This is rather helpful, we don’t need to make a decision on data formats before we can start thinking about how the data should be arranged.

Note: Since these concepts apply equally to all data formats, I’m using “WXR” in this post as shorthand for “the structured data section of whichever file format we ultimately use”, rather than specifically referring to the existing WXR format.

Why is a Schema Important?

It’s fair to ask why, if the WordPress Importers have survived this entire time without a formal schema, why would we need one now?

There are two major reasons why we haven’t needed one in the past:

• WXR has remained largely unchanged in the last 10 years: there have been small additions or tweaks, but nothing significant. There’s been no need to keep track of changes.
• WXR is currently very simple, with just a handful of basic elements. In a recent experiment, I was able to implement a JavaScript-based WXR generator in just a few days, entirely by referencing the Core implementation.

These reasons are also why it would help to implement a schema for the future:

• As work on WXR proceeds, there will likely need to be substantial changes to what data is included: adding new fields, modifying existing fields, and removing redundant fields. Tracking these changes helps ensure any WXR implementations can stay in sync.
• These changes will result in a more complex schema: relying on the source to re-implement it will become increasingly difficult and error-prone. Following Gutenberg’s lead, it’s likely that we’d want to provide official libraries in both PHP and JavaScript: keeping them in sync is best done from a source schema, rather than having one implementation copy the other.

Taking the time to plan out a schema now gives us a solid base to work from, and it allows for future changes to happen in a reliable fashion.

WXR for all of WordPress

With a well defined schema, we can start to expand what data will be included in a WXR file.

Media

Interestingly, many of the challenges around media files are less to do with WXR, and more to do with importer capabilities. The biggest headache is retrieving the actual files, which the importer currently handles by trying to retrieve the file from the remote server, as defined in the wp:attachment_url node. In context, this behaviour is understandable: 10+ years ago, personal internet connections were too slow to be moving media around, it was better to have the servers talk to each other. It’s a useful mechanism that we should keep as a fallback, but the more reliable solution is to include the media file with the export.

Plugins and Themes

There are two parts to plugins and themes: the code, and the content. Modern WordPress sites require plugins to function, and most are customised to suit their particular theme.

For exporting the code, I wonder if a tiered solution could be applied:

• Anything from WordPress.org would just need their slug, since they can be re-downloaded during import. Particularly as WordPress continues to move towards an auto-updated future, modified versions of plugins and themes are explicitly not supported.
• Third party plugins and themes would be given a filter to use, where they can provide a download URL that can be included in the export file.
• Third party plugins/themes that don’t provide a download URL would either need to be skipped, or zipped up and included in the export file.

For exporting the content, WXR already includes custom post types, but doesn’t include custom settings, or custom tables. The former should be included automatically, and the latter would likely be handled by an appropriate action for the plugin to hook into.

Settings

There are a currently handful of special settings that are exported, but (as I just noted, particularly with plugins and themes being exported) this would likely need to be expanded to included most items in wp_options.

Users

Currently, the bare minimum information about users who’ve authored a post is included in the export. This would need to be expanded to include more user information, as well as users who aren’t post authors.

WXR for parts of WordPress

The modern use case for importers isn’t just to handle a full site, but to handle keeping sites in sync. For example, most news organisations will have a staging site (or even several layers of staging!) which is synchronised to production.

While it’s well outside the scope of this project to directly handle every one of these use cases, we should be able to provide the framework for organisations to build reliable platforms on. Exports should be repeatable, objects in the export should have unique identifiers, and the importer should be able to handle any subset of WXR.

WXR Beyond WordPress

Up until this point, we’ve really been talking about WordPress→WordPress migrations, but I think WXR is a useful format beyond that. Instead of just containing direct exports of the data from particular plugins, we could also allow it to contain “types” of data. This turns WXR into an intermediary language, exports can be created from any source, and imported into WordPress.

Let’s consider an example. Say we create a tool that can export a Shopify, Wix, or GoDaddy site to WXR, how would we represent an online store in the WXR file? We don’t want to export in the format that any particular plugin would use, since a WordPress Core tool shouldn’t be advantaging one plugin over others.

Instead, it would be better if we could format the data in a platform-agnostic way, which plugins could then implement support for. As luck would have it, Schema.org provides exactly the kind of data structure we could use here. It’s been actively maintained for nearly nine years, it supports a wide variety of data types, and is intentionally platform-agnostic.

Gazing into my crystal ball for a moment, I can certainly imagine a future where plugins could implement and declare support for importing certain data types. When handling such an import (assuming one of those plugins wasn’t already installed), the WordPress Importer could offer them as options during the import process. This kind of seamless integration allows WordPress to show that it offers the same kind of fully-featured site building experience that modern CMS services do.

Of course, reality is never quite as simple as crystal balls and magic wands make them out to be. We have to contend with services that provide incomplete or fragmented exports, and there are even services that deliberately don’t provide exports at all. In the next post, I’ll be writing about why we should address this problem, and how we might be able to go about it.

Ross Morsali, via his brand Code Amp, released the Custom Layouts plugin last week. The plugin’s goal is to provide a visual post layout builder for users of both the block and classic editors.

For end-users, this is yet another choice between the multitude of plugins for displaying posts. After years of new plugins launching in this space, it would seem that there would be a clear front-runner, but developers are still trying to tame this wild and complex feature. The Custom Layouts plugin has its own approach, and it is worth giving it a quick spin to see if it suits you.

I have written extensively about the upcoming Query block and its role in the future of WordPress. However, it is necessary to look at alternative solutions for displaying posts via the block editor. The Gutenberg development team should take note of the things that work and those that do not.

For developers, the plugin is a noteworthy experiment that uses the block editor component system outside of the actual editor. Custom Layouts uses these various components on its custom Layout and Template Editor screens.

The plugin is a product of Morsali learning React and the block system in the last year and a half. “Working with Gutenberg and the Block Editor as a developer is a far superior experience to the old paradigm (the classic editor) — the learning curve is definitely greater, but once you get over the hump it seems the future is bright,” he wrote in the plugin’s announcement post. “I also love the fact that we don’t actually need to be using the Block Editor to use Gutenberg components — that means we can still build what we want and how we want it (providing we’re using React), whilst keeping the UI in tune with the rest of WordPress.”

How the Plugin Works

Template editor screen.

Custom Layouts takes a different route than similar plugins, splitting its components into different screens. The terminology can be confusing to the uninitiated. The plugin introduces two parts that serve as the foundation of its system:

• Templates: Handles the design of individual posts.
• Layouts: Controls queried posts and their layout.

I have had a beta version of the plugin since late December. This has given me three weeks to decide whether I like the approach. On the one hand, the plugin caters to two different user bases. One set can implement their layouts via the Custom Layouts block. Those on the classic editor can use the Layout Editor screen. Both share the Template Editor.

Creating a three-column grid layout.

The plugin’s system is a good option for users of the classic editor. It comes with a visual interface they would otherwise not have. It also provides a shortcode for easy copying/pasting into the post editor.

For users of the block editor, having a separate screen for the template builder will likely feel unnatural. Because the block editor is a visual interface itself, the multiple screens create a disjointed atmosphere that never feels right.

However, there is a solution for that in the plugin. I recommend users skip the Template Editor and Layout Editor screens altogether. The Custom Layouts block serves as an alternative layout builder in the block editor. Plus, users can edit existing templates via a popup overlay or even create new ones without ever leaving the post-editing screen.

Overlay for editing a template.

Building everything from the post editor feels like it should feel. Users get more of that instant feedback that they are accustomed to through the block editor.

There are benefits to the multi-component system. Separating the template builder means that users can build and reuse a specific design from a single source. They can also update individual templates, which will subsequently apply to all uses of those templates across the site.

The other benefit is that end-users are not overloaded with choices. Building a query-related block, widget, shortcode, or similar component is fraught with complexity. This is because there are three pieces of laying out a list of posts: the query to load them, the overall layout, and the design of the individual posts. Putting options for each of these pieces into the block inspector, for example, means creating a balance between sacrificing some choices and providing every possible setting to the user. This balancing act is what drove Morsali toward separating the components of the plugin.

On the whole, Custom Layouts is a solid plugin. The downside is that there is a little bit of a learning curve because it serves two audiences. Users will need to figure out which workflow best suits them first. Once they figure that out, the plugin is pretty nice to work with.

WordPress users on Android may have noticed a new prompt in the mobile app for publishing Story posts. This feature is now in public beta in the Android app, ahead of an upcoming launch on the WordPress iOS app. Stories will also coming to the Block editor on WordPress.com in early 2021.

Early access to Story posts is available in version 16.3+ of the app, released in mid-December. The prompt appears at the bottom of the site management screen. Selecting a Story post immediately takes you to your phone’s media where you can add photos or a video.

The mobile app’s implementation of the Stories feature is different from other platforms, like Instagram and Facebook, in several key ways. Most importantly, WordPress stories are not ephemeral. They live permanently on your site and anyone can view them after they are published. WordPress.com’s documentation for the block highlights a few differences:

• Posts with Stories won’t disappear after 24 hours. 
• The Story content can be added to and edited after publishing. 
• Anyone visiting your site can view the Story. 
• You can share your Story on any platform using the post permalink.

After testing the feature, I can confirm a few more differences. While the WordPress app’s implementation transcends other platforms’ limitations on the duration of the story’s visibility, it lacks basic features that users have come to expect from other apps. It doesn’t support animated gifs, effects, location, stickers, music, and other embellishments that make stories such a creative social medium. At the moment, the only thing you can do is add colored text with a background.

Videos work as Stories, too, but they don’t seem to have the same preview with a thumbnail image. It’s just a generic placeholder for now. That may be something the team is still working on, but I logged an issue on GitHub for it, in case it’s a bug.

In the interest of owning your own content, I can see it being useful to create stories on your own website and share them to other networks. The current implementation is basically a fullscreen slideshow. It is not yet more compelling than what social networks offer, but it looks like WordPress for iOS plans to expand on these features using the open source Kanvas library from Tumblr.

Kanvas makes it possible to add effects, drawings, text, stickers, and make GIFs from existing media or the camera. If you have ever used the Tumblr iOS app then you have seen Kanvas in action in the camera, media editor, GIF maker, and media posting tool. It should make for a more exciting Stories implementation on iOS, with features on par with what users have come to expect from other platforms. Something similar for Android may be in the works and this post will be updated as soon as we receive comments from the mobile team.

The previous post talked about the broad problems we need to tackle to bring our importers up to speed, making them available for everyone to use.

In this post, I’m going to focus on what we could do with the existing technology, in order to give us the best possible framework going forward.

A Reliable Base

Importers are an interesting technical problem. Much like you’d expect from any backup/restore code, importers need to be extremely reliable. They need to comfortable handle all sorts of unusual data, and they need to keep it all safe. Particularly considering their age, the WordPress Importers do a remarkably good job of handling most content you can throw at it.

However, modern development practices have evolved and improved since the importers were first written, and we should certainly be making use of such practices, when they fit with our requirements.

For building reliable software that we expect to largely run by itself, a variety of comprehensive automated testing is critical. This ensures we can confidently take on the broader issues, safe in the knowledge that we have a reliable base to work from.

Testing must be the first item on this list. A variety of automated testing gives us confidence that changes are safe, and that the code can continue to be maintained in the future.

Data formats must be well defined. While this is useful for ensuring data can be handled in a predictable fashion, it’s also a very clear demonstration of our commitment to data freedom.

APIs for creating or extending importers should be straightforward for hooking into.

Performance Isn’t an Optional Extra

With sites constantly growing in size (and with the export files potentially gaining a heap of extra data), we need to care about the performance of the importers.

Luckily, there’s already been some substantial work done on this front:

There are other groups in the WordPress world who’ve made performance improvements in their own tools: gathering all of that experience is a relatively quick way to bring in production-tested improvements.

The WXR Format

It’s worth talking about the WXR format itself, and determining whether it’s the best option for handling exports into the future. XML-based formats are largely viewed as a relic of days gone past, so (if we were to completely ignore backwards compatibility for a moment) is there a modern data format that would work better?

The short answer… kind of.

XML is actually well suited to this use case, and (particularly when looking at performance improvements) is the only data format for which PHP comes with a built-in streaming parser.

That said, WXR is basically an extension of the RSS format: as we add more data to the file that clearly doesn’t belong in RSS, there is likely an argument for defining an entirely WordPress-focused schema.

Alternative Formats

It’s important to consider what the priorities are for our export format, which will help guide any decision we make. So, I’d like to suggest the following priorities (in approximate priority order):

• PHP Support: The format should be natively supported in PHP, thought it is still workable if we need to ship an additional library.
• Performant: Particularly when looking at very large exports, it should be processed as quickly as possible, using minimal RAM.
• Supports Binary Files: The first comments on my previous post asked about media support, we clearly should be treating it as a first-class citizen.
• Standards Based: Is the format based on a documented standard? (Another way to ask this: are there multiple different implementations of the format? Do those implementations all function the same?
• Backward Compatible: Can the format be used by existing tools with no changes, or minimal changes?
• Self Descriptive: Does the format include information about what data you’re currently looking at, or do you need to refer to a schema?
• Human Readable: Can the file be opened and read in a text editor?

Given these priorities, what are some options?

WXR (XML-based)

Either the RSS-based schema that we already use, or a custom-defined XML schema, the arguments for this format are pretty well known.

One argument that hasn’t been well covered is how there’s a definite trade-off when it comes to supporting binary files. Currently, the importer tries to scrape the media file from the original source, which is not particularly reliable. So, if we were to look at including media files in the WXR file, the best option for storing them is to base64 encode them. Unfortunately, that would have a serious effect on performance, as well as readability: adding huge base64 strings would make even the smallest exports impossible to read.

Either way, this option would be mostly backwards compatible, though some tools may require a bit of reworking if we were to substantial change the schema.

WXR (ZIP-based)

To address the issues with media files, an alternative option might be to follow the path that Microsoft Word and OpenOffice use: put the text content in an XML file, put the binary content into folders, and compress the whole thing.

This addresses the performance and binary support problems, but is initially worse for readability: if you don’t know that it’s a ZIP file, you can’t read it in a text editor. Once you unzip it, however, it does become quite readable, and has the same level of backwards compatibility as the XML-based format.

JSON

JSON could work as a replacement for XML in both of the above formats, with one additional caveat: there is no streaming JSON parser built in to PHP. There are 3rd party libraries available, but given the documented differences between JSON parsers, I would be wary about using one library to produce the JSON, and another to parse it.

This format largely wouldn’t be backwards compatible, though tools which rely on the export file being plain text (eg, command line tools to do broad search-and-replaces on the file) can be modified relatively easily.

There are additional subjective arguments (both for and against) the readability of JSON vs XML, but I’m not sure there’s anything to them beyond personal preference.

SQLite

The SQLite team wrote an interesting (indirect) argument on this topic: OpenOffice uses a ZIP-based format for storing documents, the SQLite team argued that there would be benefits (particularly around performance and reliability) for OpenOffice to switch to SQLite.

They key issues that I see are:

• SQLite is included in PHP, but not enabled by default on Windows.
• While the SQLite team have a strong commitment to providing long-term support, SQLite is not a standard, and the only implementation is the one provided by the SQLite team.
• This option is not backwards compatible at all.

FlatBuffers

FlatBuffers is an interesting comparison, since it’s a data format focussed entirely on speed. The down side of this focus is that it requires a defined schema to read the data. Much like SQLite, the only standard for FlatBuffers is the implementation. Unlike SQLite, FlatBuffers has made no commitments to providing long-term support.

	WXR (XML-based)	WXR (ZIP-based)	JSON	SQLite	FlatBuffers
Works in PHP?
Performant?
Supports Binary Files?
Standards Based?				/
Backwards Compatible?
Self Descriptive?
Readable?		/

As with any decision, this is a matter of trade-offs. I’m certainly interested in hearing additional perspectives on these options, or thoughts on options that I haven’t considered.

Regardless of which particular format we choose for storing WordPress exports, every format should have (or in the case of FlatBuffers, requires) a schema. We can talk about schemata without going into implementation details, so I’ll be writing about that in the next post.

Kinsta, a managed WordPress hosting company, announced its local development tool named DevKinsta earlier today. The tool allows developers to spin up new WordPress sites, including multisite support, in moments. Each site is automatically configured with Nginx, PHP, and MySQL.

DevKinsta packages Adminer, an open-source database manager. The system also includes an SMTP server and email inbox for testing outgoing emails locally.

“This is the first version of the tool, let’s say the MVP, but we have a dedicated development team supporting and adding a lot of new features to it,” said Tom Zsomborgi, Kinsta’s Chief Business Officer.

Developers can run and test HTTPS support and enable WP_DEBUG at the flip of a switch. Kinsta web hosting customers can also deploy their sites directly from the interface.

It took me around an hour to get the system set up and running. To be more exact, I spent 53 minutes. Close enough. Between having to sign out, restart my laptop, and waiting for various pieces to install, I at least managed to get a little laundry done in those dull, in-between moments.

Installing DevKinsta on Windows.

The setup process was not a completely pain-free affair. However, the price of admission to use this tool — a little bit of my time — was well worth it.

Let me be clear. I have tested far worse systems. Even with over 15 years of development experience under my belt, I have utterly failed at setting up other local dev environments. For DevKinsta to simply get me to the finish line is a success.

However, I like simple things, and I prefer them to move along relatively quickly. I am accustomed to a 20-minute XAMPP setup. While it may not be as fancy or have the bells and whistles of more sophisticated development tools, it gets the job done and rarely doles out headaches.

The holdup was setting up Windows Subsystem for Linux (WSL 2) and Docker, which are both requirements. Jump-starting DevKinsta itself was a breeze. And, as an old-school XAMPP user, DevKinsta’s ease of use has pulled me in enough to do more than just give it a passing glance. I could actually see myself using this on a day-to-day basis.

In short, I am sold. DevKinsta is a tool all WordPress developers should at least spin up once.

Thus far, the feedback on Twitter has been generally positive. However, Linux users may have to wait a bit because the tool is only available for macOS and Windows at the moment.

“I love seeing companies releasing local development tools but I wish more would offer their services to Linux users,” tweeted WordPress developer Chad McCullough. “There are a lot of us developers out there running Linux.” The Kinsta team responded that the tool will eventually support Linux and that news is forthcoming.

Spinning up a new WordPress site.

The simple and straightforward UI is what makes this tool useful. Most developers do not need overly complicated configurations and options. They simply need to launch an environment that lets them work on their own projects. Anything beyond the basics far too often gets in the way.

DevKinsta makes it easy to launch and manage multiple development installs. Developers can also switch PHP versions via a simple dropdown — versions 7.2 – 8.0 are currently supported.

Site management screen.

The obvious comparison for DevKinsta will be against Local by Flywheel, which has increasingly become a primary tool for many WordPress developers.

Zsomborgi explained why the company thinks DevKinsta is a better option. “In our case, Docker is an important part here. Local doesn’t use virtualization in the background. Local has to install every piece of the environment to the host machine (NGINX, apache, different PHP versions, etc.). DevKinsta encapsulates these technologies into containers. Containers do make things easier for maintaining different applications without interrupting the host OS or installing many of the dependencies that are not required. We pretty much don’t touch the host OS, but have Docker as our main dependency to run the applications on their own environments.”

He said this speeds up the upgrade process and makes it easier to maintain bug fixes and send out security patches. He also said that because each application runs on its own Kernel namespace, any security issues should not affect the host OS.

“If the user is comfortable enough with Docker, he can extend DevKinsta features,” said Zsomborgi. “For example, he can monitor the usage of the container, or the PHP usage specifically as an example with docker monitoring tools that comes out of the box with Docker installation. The user can install any utility inside DevKinsta containers without touching the host OS and use applications that are not supported on Windows, for example.”

One of the use cases he mentioned was installing a benchmark tool to get statistics about site performance. This can be installed inside the Nginx container as a sidecar or separate container.

“In the past, Local didn’t use exactly Docker,” said Zsomborgi. “They used VirtualBox + DockerMachine. We tried it, and it was a bit painful. But without VirtualBox, DevKinsta can be more stable and scalable. So we use Docker without VirtualBox. It also needs virtualization, but nowadays, there are fewer Windows computers that have disabled virtualization by default.”

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.

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.

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.

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.

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.

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:

Phase	Current Name	Proposed Name
1	Planning and securing team leads	Preliminary Planning
2	Development work begins	Alpha
3	Beta	Beta
4	Release candidate	Release Candidate
5	Launch	General release

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?

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.”

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.

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?

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.

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.

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.

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 those 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.

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.”

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.

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?