Creating SVG sprites in combination with wordpress/scripts

In one of my advent calendar blog posts in 2016 I wrote (in German) about how to create a SVG sprite with SVG symbols using a Gulp script. With Gutenberg becoming a major part of WordPress I have used the wordpress/scripts package a lot lately. I a recent project I wanted to create such a SVG symbols sprite again, but I didn’t liked to use Gulp additionally with wordpress/scripts, so I searched for an alternative.

SVG Spritemap Webpack Plugin

After some search I’ve found the svg-spritemap-webpack-plugin which looked quite promising. It’s using webpack (which is also included in wordpress/scripts) and can be used like this:

Read more →

Hide the download button for audio and video blocks

Last week I was asked for help on a website project. In this project, the website embeds some audio files into the page. This is a great feature of WordPress making it so easy to embed media files. But some people dislike, that on some browsers it’s do easy to download those files.

The “download” button in Chrome

In the Chrome browsers, it’s simpler than in any other browsers. By default, any audio and video tag would add a “download” button to the options (the three dots, next to the controls). In this particular project, the button should be removed, to make it at least a little harder to download a file and not “encouraging” anyone to do so.

Hiding the button using the “controlList” attribute

Chrome is the only browser with such a button (I know of) and forunately it also has an easy way to disable it: the controlList attribute. This attribute can have different/multiple values and one of them is the nodownload value.

You may now this, that you can simply add this attribute manually to the block using the “Edit as HTML” view. But as soon as you switch back to the “Edit visually” view, the block will be defect and you can only choose to either recover it (which removes the attribute) or convert it to HTML.

Adding for a feature request in Gutenberg

As this issue was probably not new, I searched for existing tickets and found two. The first one was asking to add a toggle to show the download button. This one referred to a second ticket about the general idea of disabling the download button, also by introducing a toggle.

In this second ticket some good arguments were made against such a toggle. As only Chrome has this button, such a toggle would only “work” in Chrome. And it would not even really work. Because even the attribute will not prevent downloads.

If a audio or video file is embedded with an audio or video HTML tag using a file from the media library, it can be downloaded. It will actually be “downloaded” automatically, once the media is played.

Silently removing the button with a plugin

So even though you cannot prevent the download, you might still want to hide the button in this case you can filter the block rendering and add the attribute there. In the simplest form, it will look like this:

function hide_download_buttons_on_embeds_render_block( $block_content, $block ) {
	if ( 'core/audio' === $block['blockName'] ) {
		$block_content = str_replace(
			'<audio ',
			'<audio controlsList="nodownload" ',
	if ( 'core/video' === $block['blockName'] ) {
		$block_content = str_replace(
			'<video ',
			'<video controlsList="nodownload" ',

	return $block_content;
add_filter( 'render_block', 'hide_download_buttons_on_embeds_render_block', 10, 2 );

You might have to write a bit more code, if the HTML tags in your WordPress installation already uses some other attribute values.


While it’s not possible to prevent downloads of audio and video files from the media library in such a way, it might still be something you want to add to your page.

If you do want to allow downloads – let’s say for episodes of a podcast – it’s much better to actively add a download button using the “File” block. This will not only present a consistent button in browser, it will also make it a lot easier, obvious and accessible to download the media file.

As always, the solution from this blog post can be found as a GIST where you can download the solution as a ZIP file and install it as a plugin.

Accessibility is not a feature

The yearly Global Accessibility Awareness Day is still some weeks away – this year it be celebrated on 20 May 2021 – but some recent discussions made be pick this topic for my next blog post.

It’s not just a number, it’s people!

In a recent discussion on twitter regarding a corona contact tracing app, the importance of an accessible app was discussed once more. I can’t tell you how many time I’ve read statements like these:

Read more →

Repairing the WordPress database

Earlier this week one website was not responding and showing an error that the connection to the database was not possible. Such an error is usually a sign, that the credentials are invalid. But no changes have been made to either the credentials or the configuration file. After activating the WP_DEBUG mode I found out that the database was corrupt.

Repairing the database with the WP-CLI

My first approach was using the WP-CLI. There you have an option to optimize the tables, which can also sometimes repair errors:

wp db optimize

This command is usually been used when large amounts of rows where deleted but the table size was not reduced. But it will not always also fix issues with the tables. Fortunately there is another command for this task:

Read more →

Show comments of private posts in the comments widget

In September 2017 I wrote a blog post on how to show tags from private posts in the tags widget. Three weeks ago I got a comment (on the German blog post) if something similar would be possible for comments from private posts. In this posts I would like to present you a simple solution to that comment.

Filter the comments query arguments

By default the comments widget will only show five latest approved comments from public posts. This is how the query arguments look like:

Read more →

Get detailed download stats for plugins

Recently I was checking the downloads of a plugin in the plugin directory. In the “Advanced View” of a plugin you will find a “Downloads Per Day” graph with the numbers from the past 267 days. Let’s take a look at the stats for the poplar Antispam Bee plugin:

Downloads per day for Antispam Bee

When you hover over the graph, you will find the date an number of downloads of that day. But I wanted to know the summary of the downloads in the first few weeks after the latest release (the spike in the graph) and writing down all numbers manually to add them up would have been a bit too much work. So how could I get those numbers more easily?

Read more →

Better security for WordPress with secure server headers

There are many options to make a WordPress website more secure. For some of those options you might use additional plugins. But there is an easy way to increase the security by setting only some server settings. But before I go into details, let’s find out how to get a current security status of your site.

Mozilla Observatory

An excellent tool to test your website for security is the Mozilla Observatory tool. This tool scans not only the headers you server is sending, it will also scan TLS and SSH settings and will use some third-party tools to give you a brief overview. A result might look like this, before you adjust any settings:

Read more →

Debugging memory usage

Last week, an issue was reported for a site. It only occurred sometimes and the result was an Error 500. Activating the WP_DEBUG mode I was quickly able to find out that the memory limit was hit. The only fix was an increase of this limit, as the functionality on the pages used quite a lot memory and an optimization was not easy to find.

In those cases it would be nice to be able to find out how much you have to increase the limit. So how much would a page load usually take. There are several ways to find this out.

The danegerous way

One simple solution would be to decrease the memory limit until you always get a memory limit error. Then you slightly increase the limit until you only get the error some times. This is the value the actual usage would likely be. Then you add some more to that limit, so you don’t run into it again.

Read more →

Set the debug level using error_reporting

Everyone knows that. You work on a website and you run into issues. Sometime you even get a critical error like this:

But in some cases, you don’t get the error on every single request. Then you have to activate the debug mode and log all errors.

Activating the debug mode

To activate the debug mode for WordPress you simply have to set some constants in your wp-config.php file. These are the defaults:

Read more →

Prevent deletion of post type items that are still used

This is probably an issue may of you have tun into. You embed a post type items into a page or post and then you delete this item without knowing it was embedded somewhere. For this example I will use the popular contact form plugin “Contact Form 7”, but it works with any other post type.


We install the Contact Form 7 plugin, create a form and place it into a page using the Gutenberg block. The page’s content will look like this:

<!-- wp:contact-form-7/contact-form-selector {"id":39,"title":"Contact form 1"} -->
<div class="wp-block-contact-form-7-contact-form-selector">[contact-form-7 id="39" title="Contact form 1"]</div>
<!-- /wp:contact-form-7/contact-form-selector -->

We can see the ID for the custom post type wpcf7_contact_form used in the block attributes and the inner shortcode the plugin is still using.

Deleting a post type items

If we now navigate to the “Contact -> Contact Forms” overview we can use the “Bluk actions” to delete the contact form. When we then open the page in the frontend, where the contact form was previously embedded, we get this, quite funny, result:

[contact-form-7 404 "Not Found"]

Instead of rendering the contact form, we will get a “broken shortcode”. For other post types the “error handling” might look differently or even break your site.

Protect post type items from being deleted

So how can we easily prevent deleting such an item if it’s still used somewhere? We would have to search all other post types for this item. If we do that with the “post content” looking for the markup, this will be a very costly operation and for some embeddes it might not easily work. So we will get use some help to make it faster and more reliable.

Using a “helper taxonomy”

We will introduce a taxonomy for this deletion prevention. This taxonomy needs no UI and does not have to be public. These few lines are enough to register it:

function deletion_prevention_register_taxonomy() {
		array( 'post' ),
			'hierarchical' => false,
			'public'       => false,
add_action( 'init', 'deletion_prevention_register_taxonomy' );

We don’t have to register it for every post type we want to use it with, registering it for posts is enough. Now we can add this taxonomy.

Add the helper taxonomy to posts or pages

For our example we parse for all blocks, when a post type is saved. If we find a contact form block, we use the ID of that contact form as the term name:

function deletion_prevention_save_post( $post_ID, $post, $update ) {
	if ( ! in_array( $post->post_type, array( 'post', 'page', true ) ) ) {

	$blocks = parse_blocks( $post->post_content );

	$forms = array();
	foreach ( $blocks as $block ) {
		if ( 'contact-form-7/contact-form-selector' === $block['blockName'] ) {
			$forms[] = (string) $block['attrs']['id'];

	wp_set_object_terms( $post_ID, $forms, 'deletion_prevention_tax' );
add_action( 'save_post', 'deletion_prevention_save_post', 10, 3 );

This callback limits the check for posts and pages only and it only searches for the contact-form-7/contact-form-selector. If you want to prevent the deletion of multiple embedded post types, you might want to use additional taxonomies, other term names or some term meta.

Now that we save this taxonomy, we know exactly where our contact forms are embedded. If we want to delete a contact form, we have to find those posts or pages.

Prevent the deletion

Every time a post type is deleted, some actions are called. One is called just before the deletion is being executed. This is where we hook in:

function deletion_prevention_delete_check( $delete, $post, $force_delete ) {
	deletion_prevention_check( $post );
add_action( 'pre_delete_post', 'deletion_prevention_delete_check', 10, 3 );

Some post types can also be send to trash (Contact Form 7 does not support that), so we might also want to prevent trashing of these items:

function deletion_prevention_trash_check( $trash, $post ) {
	deletion_prevention_check( $post );
add_action( 'pre_trash_post', 'deletion_prevention_trash_check', 10, 2 );

Now you can see why we are using another new function for the check.

Check for current embeds of the item

Now we are at the final stage. We will search for any embeds of the post type item we are trying to delete or trash by using a taxonomy query on posts and pages using the ID as the term slug:

function deletion_prevention_check( $post ) {
	$args = array(
		'post_type'      => array( 'post', 'page' ),
		'post_status'    => array(
		'tax_query'      => array(
				'taxonomy' => 'deletion_prevention_tax',
				'field'    => 'slug',
				'terms'    => (string) $post->ID,
		'posts_per_page' => 1,
		'fields'         => 'ids',

	$posts = get_posts( $args );

	if ( ! empty( $posts ) ) {
						/* translators: %1$s: link to a filtered posts list, %2$s: link to a filtered pages list */
						'This item as it is still used in <a href="%1$s">posts</a> or <a href="%2$s">pages</a>.',
					admin_url( 'edit.php?post_type=post&taxonomy=deletion_prevention_tax&term=' . $post->ID ),
					admin_url( 'edit.php?taxonomy=deletion_prevention_tax&term=' . $post->ID )

If your query returns a single post or page, we know that the item is still used. In this case we wp_die to stop the current request which will prevent the deletion of the item. In the message we will also place two links to the posts and pages list, filtered by the embedded item, so we can quickly find out where they are still used, so we can remove them and then safely delete them.


Accidentally deleting a post type item that is still used in other places can happen quite easily and there is currently nothing in core to prevent something like this. Using this approach with a helper taxonomy introduces a simply way to prevent such accidents. The same approach could also be used to prevent setting an embedded item to an non-public status. Something similar would also work preventing the deletion of attachments (although they are also a post type, the same hooks will not work). I hope that this final blog post of 2020 will also help you in some projects. The code from this blog post is available as a plugin in a GIST, so you can try it out yourself or modify it for your needs.