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.
Continue reading “Sharing content from your device directly into a new WordPress post”
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.
Watch the story
Continue reading “Walking the San Francisco Crosstown Trail”
Thanks for opening this article because or despite of the click-bait heading. I’m sorry about the title if it offends you, but I hope over the course of the article I can clarify how I mean it. Regarding the curse word itself, I’m German, and in my language this is not a big deal – I still put the asterisk in there, hoping that’s more acceptable. 🙂
This post is a very emotional, contradictory, and honest attempt to capture my personal impressions, thoughts, and feelings during this pandemic. If you are worried about this being a conspiracy article, rest assured it isn’t. If you were looking for a conspiracy article, I’m sorry. This is really just a personal dump of thoughts – maybe some of this will sound controversial, maybe you’ll disagree on some points, but hopefully you’ll find things you agree with too.
Continue reading “F*ck COVID”
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?
Continue reading “Moving Continents”
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.
Continue reading “Storing Confidential Data in WordPress”
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.
Continue reading “Using CSS Custom Properties for better UX in Frontend and Gutenberg”
A few weeks ago, it was announced that Google Chrome started supporting the new
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.
Continue reading “Native Lazy-Loading for WordPress”
The Site Kit plugin by Google makes it trivial to integrate your WordPress site with various publisher-facing Google services such as Google Analytics. In addition to exposing key insights from these services directly in your WordPress dashboard, it also automatically places the necessary code snippets on your page to ensure these metrics can be gathered properly.
In this post we will look at Google Analytics specifically and how you can customize its behavior in the Site Kit plugin. While the default configuration already gives you access to many valuable metrics, Google Analytics becomes really powerful when you have tailored it to your specific use-cases. With Site Kit currently still in Beta, the user-facing configuration options for Google Analytics are minimal. While we are exploring how we can expose more customization opportunities through the plugin’s settings UI, it may be a while until these improvements are included in a new plugin’s release. Since its beta 1.0.4 release though, the plugin includes filters to modify the Google Analytics configuration, so as a developer you can tweak it in almost any way you like already today.
Continue reading “Customizing Google Analytics Configuration in the Site Kit Plugin”
Phase 2 of Gutenberg is all about taking the compelling capabilities of the block editor to the site level. WordPress 5.0 introduced it as the new editor for post content, but that was only the beginning. Blocks are a powerful tool and inspired by the learnings of various other formats of editing that WordPress and other platforms have been using over the years, so it makes sense for them to provide a unified approach to reusable content. The difference between shortcodes and widgets for example has pretty much been non-existent, and it felt weird to create a certain UI component only for one of the two, or having to write some duplicate code to address both layers. With Gutenberg being expanded to become the editor for your entire WordPress site, beyond the post content bubble, this problem will be solved. Furthermore, it will bring the new editor much closer to being able to fully compete with existing layout builders.
Each of the steps to get there (e.g. migrating widgets, menus, and possibly even other elements fully controlled by the theme today) poses several challenges, so it might still be some time until we get to experience all this functionality in its proper implementation. Therefore, inspired by a conversation with Morten at WordCamp Europe a few weeks ago, I wrote a tiny experimental plugin that allows you to use blocks on a sitewide level and explore what the theming of tomorrow could look like already today.
Continue reading “Exploring Sitewide Gutenberg Usage Today”
This is essentially a written version of the talk of the same name that I gave at WordCamp Europe 2019 (see the related slide deck).
As I’m sure we can all confirm, WordPress provides a strong toolset for creating awesome content. Particularly with the availability of the Gutenberg editor, publishers can now implement more interesting layouts and take their content quality to the next level. However, while the content itself is certainly the most important part of a website, there are a few other supporting pillars to ensure delightful content experiences for users consuming that content. Websites should be:
For more details on these four pillars, see the “Progressive WordPress Themes” talk by my colleagues Alberto Medina and Thierry Muller.
Unfortunately, satisfying each of these four requirements is anything but trivial. You might already know that just installing a performance or a security plugin is not actually going to magically solve these respective points.
Technologies and best practices on the web are constantly evolving: Regularly new APIs are introduced, new standards being established, former best practices being overruled. Add in all the popular frameworks that have come and gone over the years, and it becomes even more evident: Even the most senior rockstar full-stack developer cannot keep up with this technology complexity on their own.
Fortunately, there are ways to reduce and work around both of these complexities. In this post we will look at a component-based approach and a relatively new technology called “Custom Elements” and how they address the aforementioned problems.
Continue reading “Leveraging the Power of Custom Elements in Gutenberg”