Blog - Page 2 of 7 - felix-arntz.me

My WordPress Core Contribution Workflow

September 22, 2024

During an informal meetup between the WordPress Core committers attending WordCamp US 2024, one of the topics we discussed was how each of us was handling commits. Given that WordPress Core uses svn and Trac for its source of truth but git and GitHub are encouraged for contributing, it can be a bit of a hassle to synchronize changes when it comes to committing code to WordPress Core.

Fortunately, this is only relevant for the folks that commit code, i.e. nothing that a new contributor needs to worry about. Yet, there’s a good number of committers, and new ones are added regularly, so we thought it would be good to document our workflows. There’s no “official” documentation about this, simply because there’s no universally recommended approach. Many committers have come up with their own solutions throughout the years, so we decided it would be a great idea if each committer documented their approach, so that we would have a number of solutions to compare and for newer committers to review and choose from.

This brief article outlines my personal workflow for committing to WordPress Core.

An issue with block editor e2e test cross-version compatibility

July 29, 2024

While I was making minor updates to my Attachment Taxonomies plugin (GitHub repository) the other day, I noticed that the e2e tests were failing when run against WordPress version 6.1. Since the plugin’s minimum requirement is that version, I still run tests against it, to make sure it keeps working as expected.

After some investigation, I noticed the issue was happening due to the way the block editor used to work prior to WordPress 6.3, when it started to be iframed by default. So the failure most likely wasn’t happening due to an actual bug in the plugin, but due to an issue with the e2e tests.

Measuring website performance using WebPageTest (with WordPress 6.2)

April 6, 2023

In my post from last month, I am sharing my experience from rebuilding my WordPress website using a block theme, including a performance comparison. As part of that post, I included a spreadsheet with a detailed performance breakdown from before and after the changes. I only provided a bit of context for how I conducted the performance comparison in that post, however as promised, in this post I am sharing the concrete methodology that I used and how you can use it to measure performance of websites yourself.

In order to better explain the methodology, I thought I might just do another similar kind of analysis that I would go over in this post. Last week, WordPress 6.2 was released, so no better opportunity than to measure how updating my website from WordPress 6.1 to 6.2 affects its performance!

I created a spreadsheet with the full data for this new analysis, and in this post we’ll go over the process for how I got that data in detail.

Rebuilding my website using a block theme

March 6, 2023

It’s been a while since I have posted on my blog. In fact almost 2 years now. But it’s been even longer since I have significantly touched the foundation of my website; other than the regular updates, adding a small plugin here or there, my website had been using the same infrastructure and theme since 2019. A lot of it even already existed the same way in 2018. My website had gotten really out of date, in terms of both content and technology. Some of the blocks I had implemented years ago were no longer working, so part of me was even afraid to open the block editor.

A few weeks ago, I finally decided to change that and modernize my website. But it didn’t just came out of nowhere. Specifically, I wanted to update my website to use a block theme. I had been excited about them since they were in the exploration stage already in 2019, pretty much as far back as when I was rebuilding my website, “the old way”. The opportunities for enhancing performance due to the new block theme paradigm seemed extremely promising to me.

Now that we’ve already had 3 major WordPress releases to establish and refine the new infrastructure, I decided to really give it a try. In this post I’ll share my experiences with you as well as the outcome and how it is impacting performance.

Sharing content from your device directly into a new WordPress post

April 5, 2021

It is tempting to rely on closed platforms and their native apps: They integrate well with your device’s capabilities and offer easy-to-use features for improved social engagement with your audience – however at the cost of locking you into their proprietary infrastructure and owning your content.

But the open web has been catching up: A myriad of capabilities has been made available in the past few years through new standardized browser APIs which enable you and your audience to leverage the modern features they expect while remaining decentralized and under your control. To name a few:

Add to Home screen: You and your audience can add your website to their device’s home screen so that it shows up there with an icon, the same way they can install a native app, but without all the extra implications of that installation. Enable Add to Home screen in WordPress
Offline browsing: No longer will you see your browser’s ugly “Offline” page when losing the network connection, but you remain within the website’s / web app’s UI and can keep browsing content that was previously downloaded. Get offline browsing in WordPress
Engaging and replying to content from other websites: What closed social networks have been offering for seemingly ages has now finally come to the open web as well – with the difference that the data remains under your authority. Use webmentions in WordPress
Sharing content from your website: You can share content from your website to any other application, relying on your device’s integrated sharing UI – with the extra benefit of not requiring privacy-invasive sharing scripts from other platforms for it. Share content in WordPress

Another capability which you are probably used to from native apps is sharing content from one app to another. While the last bullet point above covers sharing content from your website (via the Web Share API), it is now also possible to share content to your website (via the Web Share Target API) in the same integrated way, which is what we’re gonna focus on in this post.

Walking the San Francisco Crosstown Trail

December 10, 2020

This past weekend, my girlfriend and I walked the 17 mile-long San Francisco Crosstown Trail, which spans from the southeast end to the northwest end of the city. It was an amazing experience and I can totally recommend it to anybody living in or visiting San Francisco. It presented completely new areas of the city to us, and I’m sure that it will even allow long-term San Franciscans that haven’t yet walked it to rediscover their city.

With all our impressions and photos taken, this made the perfect case for a web story – the open web version of those visual stories we’ve all come to know through platforms like Snapchat or Instagram. If you are interested in creating this kind of immersive content as integrated part of your website as well, try the Web Stories editor plugin for WordPress.

Moving Continents

February 9, 2020

I just passed my first night as a resident of the United States. More precisely, yesterday I took my overseas flight to San Francisco, California, which is where I’ll be living now, at least for the near future. It is certainly still surreal that I am here now and not going to leave in foreseeable time, and it will probably be a while until I have fully grasped it, let alone fully settled in.

If you’re wondering now, I am still a Developer Programs Engineer for Google, and I am still working in the CMS ecosystem, mostly WordPress. And my primary focus is still going to be engineering the Site Kit plugin. Only from now on, I’m going to work from the offices in San Francisco, in person with the team that is located here.

So how did this happen?

Storing Confidential Data in WordPress

January 23, 2020

When using a content management system like WordPress, it is obvious that the content site owners and collaborators create and manage needs to be persistently stored somewhere. In WordPress, this storage space is typically a MySQL database. For most WordPress sites, every single request to the site results in several queries to the database so that the content stored can be displayed.

When extending the capabilities of WordPress through plugins, such plugins usually leverage that same database to store their own data. As a plugin developer you are probably already familiar with the many APIs that WordPress provides to integrate with database storage; for example the Options API to store and retrieve options, or the Meta API to store and retrieve metadata. However, do you ask yourself what the consequences of storing data in a WordPress database are?

Not all data is equal. Certain types of data that plugins (or WordPress core itself) need to store are more sensitive than others. Think about personal data from all the customers of your WooCommerce shop, the figures of revenue you are making from affiliate links, or API credentials to access personal information from your Google account. For any data you deal with in WordPress, you should ask yourself:

How sensitive or potentially confidential is the information I would like to store?
What can I do to store the information safely?

In this post, we will look more closely at how we can deal with more sensitive information in WordPress from a security perspective.

Using CSS Custom Properties for better UX in Frontend and Gutenberg

September 30, 2019

If you are a WordPress theme developer, chances are high that you’re working with the Customizer to provide certain design options to your themes’ users – whether it is for colors, fonts, spacing or else. Providing customization opportunities is crucial for a theme’s adoption as you will never be able to please every user with your theme’s out-of-the-box design. As widely known, most WordPress users look for feature-rich solutions when assembling their site. They may find your theme’s base design very appealing, but if they cannot modify it to e.g. use their brand colors, they’ll quickly move on to something else. Long story short: Allowing users to customize your theme is crucial for adoption.

Now there’s an issue with that though: Most of these design options affect the site’s CSS, and CSS is a largely static resource. Therefore the typical approach to integrate these Customizer controls with the theme’s actual appearance is to copy the pieces of CSS that would be affected by the respective options from the stylesheet into a PHP file, and from there generate that stylesheet on the fly. This results in three major problems:

You are most likely sending a whole bunch of duplicate CSS down the line, negatively affecting performance of the site.
Because you are duplicating CSS, the approach is quite error-prone. For example when modifying CSS later, you need to remember to also make the exact same change in the Customizer CSS, if it applies there too.
This also affects the WYSIWYG experience in the editor, as you also need to manually maintain the CSS for the editor (Gutenberg / classic) in the same way.

There is a solution to all of these problems though, and its name is “CSS Custom Properties”. In this post we will look at how to use this CSS feature to improve UX for both website visitors and content creators, all at once.

Native Lazy-Loading for WordPress

September 5, 2019

A few weeks ago, it was announced that Google Chrome started supporting the new loading attribute, which allows websites to have their images and iframes lazy-loaded without any custom JavaScript. Support for the feature will most likely be extended to further browsers soon, but you can already use it today without any negative impact for browsers where it isn’t supported yet.

If you have a WordPress site, our team at Google has just released a new plugin “Native Lazyload” which you can install, activate, and your site will support native lazy-loading instantly.