Blog

Introducing Feature Policy & Reporting API for WordPress

The web has been constantly evolving. Over the years we have seen milestones such as the introduction of responsive images, AJAX requests, or location access for some examples. More recently features like Add to Home Screen, which allows you to make websites easily accessible on your phone or desktop, or Web Payments, a standardized way of processing payments on the web, have been made available. Even lazy-loading media is likely to come natively to the web soon.

While all these features are very powerful, they also pose the challenge of using them responsibly, and making sure to not abuse them, which could harm user experience. For example, asking the user to grant location access to a website without making it obvious what this would be used for and without providing a clear user benefit, the resulting pop-up can be more of a distraction than the purpose would justify it. I’m sure you have seen websites where you had to go through way too many pop-ups and consent requests before getting to the content you actually intended to see.

Keeping track of all these web features can be a tedious task, especially in the context of a CMS like WordPress, where much of the codebase (probably even most of it) comes from third parties on many sites. Even if you yourself are a responsible citizen of the web, third-party plugins and themes might have flaws or might be misusing features in ways you aren’t  aware of.

This is where two new proposed web standards, Feature Policy and Reporting API, come into play.

The Feature Policy Specification

Feature Policy is a recently-proposed web standard which gives developers control over how certain browser APIs and web features act on their  site, so that best practices can be enforced consistently. For example, if you use lots of third-party JavaScript on your website, Feature Policy enables you to restrict these scripts from requesting your users’ geolocation.
Feature Policy works by the web server sending Feature-Policy response headers that for each supported feature define how and where said feature should be allowed or disallowed. Below you can see the above basic example in action, globally disallowing Geolocation access.

Sending a header Feature-Policy: geolocation 'none' globally disables that feature, enforcing your site as well as third-party iframes to not request location access.

You can granularly adjust policies per origin, for instance by modifying the above example to allow your site to request geolocation access, but disallow it for third parties. For this purpose, an alternative is to use an allow attribute on iframes, to specifically set policies for that iframe.

Aside from helping developers keep track of third parties, Feature Policy can also be a powerful ally when integrated into the development process to ensure implementations follow best practices. The specification is intended to support different use cases and environments. In development,it would be possible,  for example, to completely disallow oversized images, making it easy for all parties involved in the process to quickly spot violations, as such images would not be rendered.

Using Feature-Policy: oversized-images 'none', you globally prevent oversized images from displaying, making it easy to spot areas for improvement.

The Feature Policy specification supports many more features: other examples include controlling camera or microphone access, disallowing synchronous AJAX requests, or the usage of document.write, and many others. In production some policies still make sense to be enforced, for example the lazyload policy or the autoplay policy. For the above example of oversized images, however, displaying a gray box instead of the oversized image would provide a bad experience to the user, so you would most likely not want to enforce the policy as aggressively. What you can do in that scenario is enable the policy in “Report-Only” mode, which would ensure that you are notified about violations while not breaking the existing site. Yes, you can also be notified of violations. This brings us to the Reporting API, which complements Feature Policy.

The Reporting API Specification

The Reporting API is another proposed standard that allows you to receive reports about client-side errors and policy violations, some of which would have been impossible to catch before. It supports several types of reports, and Feature Policy violations are one of them. This makes the Reporting API a key partner to the Feature Policy specification, particularly for production.
The way it works is a server sends a Report-To response header, informing the browser about one or more REST endpoints which implement the specification and thus are ready to receive reports. The browser will then aggregate error reports and send them to the appropriate endpoint regularly. Below you can see an example for what that header can look like:

Report-To: {
              "group": "default",
              "max_age": 10886400,
              "endpoints": [{
                  "url": "https://example.com/wp-json/reporting-api"
              }]
          }

The above header specifies only a single endpoint group named “default”, so all reports would be sent there. As mentioned, you could also provide multiple groups, for example to route reports of specific error types to specific endpoints.

By default, every report is routed to the group named “default” if one exists – or if a group is specified without a name, the “default” name is assumed implicitly. The degree of customization varies per report type: some types only allow their reports to be sent to the “default” group, while other types, for example Content Security Policy or Network Error Logging (the latter of which is another super-powerful new spec that you should check out), have their own response headers you can send to route reports to different groups.

Using Feature Policy and Reporting API in WordPress

The Feature Policy and Reporting API specifications are very promising utilities which can significantly improve user experience on the web, by keeping track of violations during development and enforcing best practices in production. While they are both still in draft, they are already usable today, with Feature Policy being supported in Chrome, Safari and Opera, and Reporting API being supported in Chrome only. However, even with the latter, given the browser distribution this still means that more than 60% of browsers in use are already able to benefit from both technologies. And it’s never too early to familiarize yourself with the power of such and how to use them!

As part of our efforts of making it easier to create compelling content experiences on the web, our team at Google has been working on two plugins to bring support for these two powerful new APIs to the WordPress platform. With those plugins and the current state of browser support, you can start using both Feature Policy and Reporting API today – and you don’t even need to write code for it as you can control them from your WordPress admin dashboard.

Feature Policy for WordPress

The Feature Policy plugin lets you control feature policies from your admin backend, taking care of sending the necessary headers in the frontend. It covers all the features supported by the specification, and the list will be kept up-to-date as the spec evolves. At the moment, for every feature you can decide whether you want to globally allow it (“any”), allow it only for your site’s own origin (“self”), or globally disallow it (“none”). In a future version, this will be enhanced so that you can control access even more granularly, i.e. controlling access for specific origins. Feature Policy version 0.1 can now be downloaded from wordpress.org.

Reporting API for WordPress

The Reporting API plugin provides an endpoint accepting browser reports according to the specification, implemented with the REST API. It sends the necessary headers in the frontend so that all reports are routed to that endpoint. Incoming reports are conveniently listed in the WordPress admin. As with the Feature Policy plugin, the Reporting API plugin implements the specification, covering all report types that can integrate with the proposed standard today. Future plans for the plugin focus on adding customization capabilities, so that you can define reporting endpoint groups and where reports are sent to yourself – for example you could also use third-party services instead of only the built-in endpoint. The Reporting API plugin version 0.1 is now available on wordpress.org.

Enforcing Best Practices on the Web

Feature Policy and Reporting API are promising specifications that can help developers spot user experience flaws easily and verify the same quality also in the long run – you can almost see it as another way of continuous integration, with different benefits. I recommend checking out the introductions on Feature Policy and Reporting API on the Google Developers blog for a deeper dive into these proposed standards.

Using Feature Policy to enforce UX best practices is also in line with the benefits that the AMP framework gives you. If you plan migrating your WordPress site to native AMP for example with the help of the AMP plugin, Feature Policy is a solid step in preparing your site for the move. As a matter of fact, enforcing solid policies on a site is precisely what AMP does; the difference is that AMP was created before Feature Policy so it uses different mechanisms for policy enforcement (e.g. the AMP Validator) although it is also starting to adopt Feature Policy itself (e.g. sync-xhr). For more details on how AMP is related to Feature Policy going forward, check out Standardizing lessons learned from AMP.

Getting the two new specifications to users early has been a high priority for us, and the WordPress ecosystem and its fragmentation with all the different plugins and themes are a perfect case for real-world usage of these specifications. We are working closely with the W3C teams that have been drafting these specifications, and by using the plugins and giving feedback you can influence the specifications themselves before they become actual standards. Let’s join forces in making it easier to create compelling content experiences on the web!

Types, Subtypes, Meta, Options – An Abstract View On Data Structures in WordPress

This weekend, I gave a talk at WordCamp Portland, looking into data structures in WordPress. While the session will soon be available on wordpress.tv, in this post I will provide a written version of it. I recommend you to read this alongside the original slides.

When referring to data structures here, it’s not data structures as in computer science. You won’t hear about arrays, doubly linked lists, binary trees. Instead we will look at object types, metadata and options, in other words, how data is organized in WordPress. We will do so from both the database and the code points of view. Knowing the ins and outs of this is crucial for both core contributors and plugin developers.

Continue reading “Types, Subtypes, Meta, Options – An Abstract View On Data Structures in WordPress”

I’m Joining Google

I am very excited to announce that I will be joining Google as a Developer Programs Engineer in the Web Content Ecosystems team, starting in November. As you may have heard, Google is building a team particularly focusing on the WordPress platform, and that very team I am going to be part of – so I am not leaving the WordPress space. Quite the contrary: Google is heavily invested in improving the open web, and the popularity of the WordPress platform allows for wide adaption of such improvements. I will continue to contribute to WordPress, even more so, my new position will be entirely dedicated to the open web. In this post I would like to share some background on this step and what it means to me personally.

Continue reading “I’m Joining Google”

Using amp-timeago to display relative dates on your Native-AMP site

In my post about how I renewed my website with Gutenberg and native AMP support I mentioned that I’d be sharing some implementation details. A couple days ago I posted about how I built a reusable section block with Gutenberg. Today we’re going to look at an AMP-specific feature and how I made use of it for my site. While the AMP plugin for WordPress does a great job in ensuring your WordPress site becomes AMP-compatible, there are still tons of additional AMP features to explore, some of which are too specific to generally add support in the plugin. An example of this is the amp-timeago component, which allows displaying relative time periods, pretty much in realtime. In other words, instead of showing a concrete date and time, it will show a string such as “x seconds/minutes/hours/days/weeks/months/… ago” – you get the gist. You can see a live-example of this when looking at when this post was published, just above, below the headline. And this is precisely what we’re going to focus on in this post, how I implemented this feature and how you can implement it for your Native-AMP WordPress site.

Continue reading “Using amp-timeago to display relative dates on your Native-AMP site”

Building a Reusable Gutenberg Section Block

As I announced in my last post in which I explained how I updated my website using Gutenberg and AMP, I would like to share some more details on specific implementations for some of the block types and AMP support integrations. Let’s start today with looking into building a reusable Gutenberg section block type. What do I mean by this? It is common for websites to have their main content width limited to a maximum, to keep line lengths readable on larger screens. However, sometimes you still want certain components to break out of those limitations, or you might even want to break an entire page into different full-width sections which are differentiated by their visual appearance and allow to host content that itself is then again limited in its maximum width. The homepage of my website makes heavy use of this, if you prefer to see an example, or you can also look at the following example blocks embedded in this post. (Note that you will need a screen with a resolution of at least around 1200px width in order to see the width limits to take effect.)

Continue reading “Building a Reusable Gutenberg Section Block”

This Site is now AMPenberg

It’s been a while since I last updated my website. I haven’t blogged regularly at all, but also the content generally has gotten out of date and no longer reflected where I am at this point. Most of you probably know the problem, you work on open-source, client projects, and products so much that you forget to update your own hub that should probably, better than anything else, represent your skillset, focuses and achievements. As of now, this website finally is back there for me. Given the increasing amount of new major WordPress features and web technologies, I finally made myself make some time for implementing some of those as part of a refresh of my site. In this post I’d like to tell a bit more about what I focused on.

Continue reading “This Site is now AMPenberg”

Using the WordPress Test Suite

Writing automated tests for your WordPress project is a must in order to verify that your code works as expected. Of course you should always do severe manual testing for your plugin or theme, but as always, humans aren’t as precise and thorough as computers can be with that. Furthermore having sufficient automated tests (i.e. solid test coverage for your code) also indicates whether a subsequent change, as in a later release, unexpectedly breaks something you wouldn’t have detected otherwise. This post gives you an introduction on the test suite that WordPress core includes, which you can also use to test your plugin for example, but of course too if you’re contributing to WordPress core. Continue reading “Using the WordPress Test Suite”

Inklusivität, Komfortzone und die deutsche Blase

As you may recognize from the title, this post is written in German. That is because its target audience is the German community in particular. It will probably be the only German post on my blog, so please forgive me for doing that. I’m sorry, and I hope you don’t feel left out.

Wenn eine nicht-deutschsprachige Person die Einführung oben gelesen hat, werden meine Entschuldigungen wohl nicht darüber hinweg helfen, dass sie sich möglicherweise von diesem Beitrag ausgeschlossen fühlen. Ich halte dies also für eine gute Einleitung für diesen Beitrag, den ich explizit an die deutsche Community richten möchte: Viele von uns tendieren nämlich dazu, in unserer Komfortzone zu bleiben (#GermanBubble) – was an sich natürlich jedem selbst überlassen ist, aber teilweise ein recht exklusives Gefühl an WordPress Community-Mitglieder aus anderen Ländern vermittelt. In diesem Beitrag möchte ich näher darauf eingehen. Der Beitrag mag an einigen Stellen überaus kritisch erscheinen, doch ich möchte nicht, dass sich jemand vor den Kopf gestoßen fühlt. Ich mag euch sehr und viele von euch sind mir gute Freunde geworden, trotzdem ist es für mich an der Zeit, ein unbehagliches Phänomen, das ich seit längerem sehe, mal öffentlich auszusprechen. Mein Ziel ist es vor allem, ein Nachdenken über die Thematik zu fördern und das eigene Verhalten zu reflektieren. Continue reading “Inklusivität, Komfortzone und die deutsche Blase”