Adding fonts to our block theme

After we’ve created the raw theme in the last blog post, it’s time to add some basic things to our theme. To quickly get some similar appearance, let’s start with fonts.

My blog is using the default fonts from Waipoua, but I have changed the main colors in a child theme. This is how the theme looks like with no customizations:

Screenshot of the original design of the Waipoua theme, showing the blog listings front page with social icons in the top right and the gray sidebar on the right.

As you can see here, I’ve changed the red tone of the header, the background color of the sidebar, and I’ve also colored the social icons in the top right widget area. The rest looks pretty much like in the parent theme.

Adding the fonts

Now, this is an interesting chapter. As of today, you would usually do the following:

  1. Download the fonts – for Google Fonts, I usually use the google-webfonts-helper and download all variants
  2. Save fonts in a folder in your theme
  3. Define the fonts in the theme.json file

If you want to follow this manual path, there is an excellent guide from Carolina on the “Full Site Editing With WordPress” site.

But since there is a new way of adding fonts to a block theme coming up, let’s try this way. With the current WordPress version 6.4, you have to install the Gutenberg plugin in order to use this option, since it is not yet “final” and therefore hasn’t been merged into Core with WordPress 6.4, so we have to wait a little longer.

With Gutenberg installed and activated, navigate to “Appearance > Manage Theme Fonts”. Here you will find the following view:

Screenshot of the "Manage Theme Fonts" admin page, showing the current fonts in a list on the right, a preview area in the middle and buttons to add Google and local fonts.

Here you find an overview of all theme fonts on the right as well as preview area for these fonts. In the top right, you can use the buttons “Add Google Font” or “Add Local Font” to add a new font family to your theme.

Let’s add the font family for headlines first, which is the Google Font “Oswald”. We click the button “Add Google Font” and then search in the “Select Font” dropdown for the font. We are then presented with all available variants. I’ve just clicked the checkbox in the table header to select all of them:

Screenshot of the "Add Google font to your theme" admin page, showing the available variants.

The Waipoua theme only included the 400 weight variant, but as with a block theme you have more control on which font you use where, I think it’s best to have all the variants available, so which ever weight (and style, if available) is used, the text looks best.

After clicking the “Add Google fonts to your theme” button, you should see a success message like “Oswald font added to Kauri theme”. Now we do the same for the “PT Sans” font, again selecting all the variants.

If we navigate back to the “Manage Theme Fonts” admin page, we should see those new fonts in the right sidebar and a preview of them. In total, we have added 2 fonts with a total of 10 variants and a total size of 1.5 MB:

Screenshot of the "Manage Theme Fonts" admin page, showing the fonts imported in the previous step.

Result of the fonts import

Now what did we get after this step? Let’s take a look at the themes folder structure first:

$ tree .
.
├── assets
│   └── fonts
│       ├── oswald_normal_200.ttf
│       ├── oswald_normal_300.ttf
│       ├── oswald_normal_400.ttf
│       ├── oswald_normal_500.ttf
│       ├── oswald_normal_600.ttf
│       ├── oswald_normal_700.ttf
│       ├── pt-sans_italic_400.ttf
│       ├── pt-sans_italic_700.ttf
│       ├── pt-sans_normal_400.ttf
│       └── pt-sans_normal_700.ttf
├── parts
│   ├── footer.html
│   └── header.html
├── readme.txt
├── screenshot.png
├── style.css
├── templates
│   └── index.html
└── theme.json

We do have a new folder “assets/fonts” and in this folder we can find the Google fonts. As these can only be downloaded in the TTF format from fonts.google.com, this is what we also get with the (current) font management solution in Gutenberg.

But let’s take a look at the theme.json file, because this is the more interesting part of this whole step. You should now see something like this:

{
	"settings": {
		"typography": {
			"fontFamilies": [
				{
					"fontFamily": "-apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Oxygen-Sans, Ubuntu, Cantarell, 'Helvetica Neue', sans-serif",
					"name": "System Font",
					"slug": "system-font"
				},
				{
					"fontFamily": "Oswald",
					"slug": "oswald",
					"fontFace": [
						{
							"fontFamily": "Oswald",
							"fontStyle": "normal",
							"fontWeight": "200",
							"src": [
								"file:./assets/fonts/oswald_normal_200.ttf"
							]
						},
						{
							"fontFamily": "Oswald",
							"fontStyle": "normal",
							"fontWeight": "300",
							"src": [
								"file:./assets/fonts/oswald_normal_300.ttf"
							]
						},
						{
							"fontFamily": "Oswald",
							"fontStyle": "normal",
							"fontWeight": "400",
							"src": [
								"file:./assets/fonts/oswald_normal_400.ttf"
							]
						},
						{
							"fontFamily": "Oswald",
							"fontStyle": "normal",
							"fontWeight": "500",
							"src": [
								"file:./assets/fonts/oswald_normal_500.ttf"
							]
						},
						{
							"fontFamily": "Oswald",
							"fontStyle": "normal",
							"fontWeight": "600",
							"src": [
								"file:./assets/fonts/oswald_normal_600.ttf"
							]
						},
						{
							"fontFamily": "Oswald",
							"fontStyle": "normal",
							"fontWeight": "700",
							"src": [
								"file:./assets/fonts/oswald_normal_700.ttf"
							]
						}
					]
				},
				{
					"fontFamily": "PT Sans",
					"slug": "pt-sans",
					"fontFace": [
						{
							"fontFamily": "PT Sans",
							"fontStyle": "normal",
							"fontWeight": "400",
							"src": [
								"file:./assets/fonts/pt-sans_normal_400.ttf"
							]
						},
						{
							"fontFamily": "PT Sans",
							"fontStyle": "italic",
							"fontWeight": "400",
							"src": [
								"file:./assets/fonts/pt-sans_italic_400.ttf"
							]
						},
						{
							"fontFamily": "PT Sans",
							"fontStyle": "normal",
							"fontWeight": "700",
							"src": [
								"file:./assets/fonts/pt-sans_normal_700.ttf"
							]
						},
						{
							"fontFamily": "PT Sans",
							"fontStyle": "italic",
							"fontWeight": "700",
							"src": [
								"file:./assets/fonts/pt-sans_italic_700.ttf"
							]
						}
					]
				}
			]
		}
	}
}

Following the “System Font” we can find our two new font families with one definition per variant. This is a lot of code that was created for us automatically, so we don’t have to.

If you refresh the page now, we won’t see any change. That’s because we have only imported the fonts into our theme and defined it in the theme.json file, but we are not using them.

Set fonts for body and headings

You can set a font family for the whole page, some “types” of elements or for individual blocks. To get the result we want, the following has to be added to the theme.json file:

{
	"styles": {
		"elements": {
			"heading": {
				"typography": {
					"fontFamily": "var(--wp--preset--font-family--oswald)",
					"fontWeight": "400"
				}
			}
		},
		"typography": {
			"fontFamily": "var(--wp--preset--font-family--pt-sans)",
			"fontWeight": "400"
		}
	}
}

This will set the font for the body and all headlines, so inside the content, as well as the core/site-title, and other “headlines” blocks. We have to fine tune this later, but for the moment, we have the following result:

The front page with the two fonts.

As for fonts, this now looks a lot more like the original theme. But it’s just the first step. We still need to work on many aspects.

Bonus: Use WOFF2 instead of TTF fonts – or both

With the current solution, I really don’t like that it is using TTF fonts. They are usually used on desktop, not on the web. And even though most browsers can use them, they are a lot larger.

Using the google-webfonts-helper, I’ve downloaded all fonts in the WOFF2 format and adjusted the theme.json file accordingly. I’ve also put each font family files into a subfolder, to better organize them.

With these changes, the size of the web fonts could be reduced from 1.5 MB to only around 590 KB, for all variants. So while this step is not absolutely necessary, I would highly recommend to use WOFF2 files. Unless you have to support some really old browsers. Then you can always decide to download them in a different format with the google-webfonts-helper.

You can also keep the TTF files as a fallback. It would then look like this as an example:

{
	"fontFamily": "Oswald",
	"fontStyle": "normal",
	"fontWeight": "200",
	"src": [
		"file:./assets/fonts/oswald/oswald-v53-cyrillic_cyrillic-ext_latin_latin-ext_vietnamese-200.woff2",
		"file:./assets/fonts/oswald/oswald-v53-cyrillic_cyrillic-ext_latin_latin-ext_vietnamese-200.ttf"
	]
}

You can find the full example in the themes’s GitHub repository.

Hidden gem using the “Manage Theme Fonts” functionality

When committing the changes to the theme, I’ve recognized that the readme.txt file was change as well. First I thought, that I’ve probably changed something in this file as well. But then I saw these additions:

Oswald Font
Copyright 2016 The Oswald Project Authors (https://github.com/googlefonts/OswaldFont) 
This Font Software is licensed under the SIL Open Font License, Version 1.1. This license is available with a FAQ at: https://scripts.sil.org/OFL 
License URL: https://scripts.sil.org/OFL 
Source: http://www.sansoxygen.com
-- End of Oswald Font credits --

PT Sans Font
Copyright © 2009 ParaType Ltd. All rights reserved. 
Copyright (c) 2010, ParaType Ltd. (http://www.paratype.com/public), with Reserved Font Names "PT Sans", "PT Serif" and "ParaType". 
License URL: http://scripts.sil.org/OFL_web 
Source: http://www.paratype.com
-- End of PT Sans Font credits --

So not only does the functionality take care of downloading the fonts, storing them in your theme, updating your theme.json file. It does also make sure that you have the credits to legally use those fonts in your readme.txt file. How cool is that?! 🤓

Summary

Adding Google fonts (or fonts from other sources) can be done in two ways: manually and with the “Manage Theme Fonts” functionality. While the latter is still not “finished”, it worked pretty well with this theme. If they also add an option to download different file formats (or change the default), I can’t wait to see this land in core.

I initially planned to also write about how to set colors and the site width in this blog post, but I think the fonts topic is enough for this one.

Kickoff for my new blog theme

This will be the start of the blog series for my new blog theme. As mentioned in the previous blog post, the goal is to create a theme that comes as close as possible to the current design, while using the Site Editor to create all necessary styles and templates.

Creating the theme

When I developed from scratch in the past, I’ve usually used _s (underscores), but since this is a classic starter theme, I needed something different. Fortunately, there is the “Create Block Theme” plugin, you can use to create a theme from your WordPress installation.

After installing and activating the plugin, navigate to “Appearance > Create Block Theme” and choose the “Create blank theme” option on the left. You are then presented with a form on the right, asking you for name, description, etc. for the new theme. This is the data that is usually found in the style.css header comment.

After filling out the form, click the “Generate” button in the bottom left. This will create the new theme in the WordPress installation. Now you can activate the theme for your site. The result would look like this:

The frontend result of the theme with the site title in the top left, a navigation sith "Sample Page" in the top right, the "Hello World" blog post in the middle, and the "Proudly Power by WordPress" in the bottom, all with no styles.

Isn’t that beautiful? OK, not quite what we need. But we do have a full Block Theme now, and can start adding all the styles we need.

The theme’s file structure

But before we start working on the theme, let’s take a look at what we have. This is the initial file structure of our new theme:

$ tree
.
├── parts
│   ├── footer.html
│   └── header.html
├── readme.txt
├── screenshot.png
├── style.css
├── templates
│   └── index.html
└── theme.json

2 directories, 7 files

Not all that much. But we do have template parts for a header and a footer. The only “page template” we have is an index.html file. The style.css file is basically empty, it mainly consists of the header comment with the data from the form. Interestingly, we find a line Requires PHP: 5.7 in this file, even though this PHP version never existed. 😅

The most important file however is the theme.json file. In this base version, it is only 35 lines long and has definitions for the layout sizes, spacing units, a system font family and the header and footer template parts.

In the next blog posts of this series, we will work with this file quite a lot.

The name of the new theme

You might have recognized, that I have chosen the name “Kauri” for the new theme (and the development site). The current theme of my blog is named Waipoua. Elmastudio named many of their themes after things in New Zealand or Asia. Waipoua Forest is a forest in the Northland Region of New Zealand. This forest shows some examples of kauri trees. And by now you should know why I’ve chosen this name. 😊

Next steps

In the next episode, we will make our initial changes to the theme.json file, maybe adding the fonts or setting the general width of the theme. So stay tuned.

If you want to follow along with the code, you can find the current state on GitHub. But please don’t create any issues or pull requests, before this blog series is finished. 😁

New year, new project, new theme – what’s coming in 2024

It’s not the new “blog year”, but a new on our calendars. In previous years, I often wanted to finally start reworking the theme of my blog over the holidays. This time I finally did it … but only started at 1 January 😅

Continuing #project26

First things first: I will continue with #project26, posting every two weeks. I usually don’t plan blog posts in advance, but this year I have a second project, I want to follow, so topics will hopefully be easier this year. But I will also post about other topics in between.

A new, old theme

I’m currently using the nice Waipoua theme from Elmastudio. I have been using this theme since July 2012, and I still love its classical blog design. But given how old it is, there are some aspects that don’t make it the perfect theme anymore. Especially, some accessibility issues are reasons to replace it.

Start fresh, but copy the overall look

The optimal outcome would be a theme on a new technical foundation, but with the exact same “pixel perfect” result. As I only want to use the Site Editor for the new theme, that might not be possible. Not being sure about what I would set myself as a goal, I’ve asked around at Twitter:

Click here to display content from Twitter.
Learn more in Twitter’s privacy policy.

From the results and the comments, most people say, I should just try to re-create the overall look of the theme. And this is what I’ll try to do.

A step by step blog post series

For the future blog posts, I’m planning to document every step I take in re-creating the theme. I hope that this will potentially be helpful for many of you with a similar idea. And since I’m usually not creating (new) themes in my daily work, it’s also a great learning opportunity for me, to get more familiar with the Site Editor.

My first long blog series

I’ve had some blog series before, but this one is expected to last well into the second quarter of this year. Maybe I can launch the new theme for the blog’s birthday in June.

I will also try to publish the progress in code in the open and also create a staging site with the current state. But more on this on my next blog post.

If you happen to use that theme as well, I would highly appreciate your feedback on what you would like to see in the new theme. Or maybe you’ve done something similar, then I would be happy if you leave a comment here.

Quick debugging for SSH connections

Once again this week, I had issues connecting to a server using SSH. It was with a different user, and something was just not working. When debugging such issues, I always have to search for that debugging mode, so why not write down the solution on my blog, so I’ll find it faster next time.

Starting an additional OpenSSH daemon in debug mode

You can activate debugging mode on the client side, but often times the issue is on the server. To debug this, you have to run the server part in debug mode. While you can activate this for the main SSH daemon, it is often easier and safer, to start an additional SSH daemon, using a different port, and with debugging activate. To do this, run the following command as root:

/usr/sbin/sshd -ddd -D -p 22222

You need to use the full path to sshd to run this command. With the -D parameter, sshd will not detach and doesn’t become a daemon, so you can see the log output in the terminal. With the -ddd parameter, you turn on the maximum debugging level. And with -p 22222 we will use a different port.

Using client side debugging mode

Now that we have the server part running in debugging mode and waiting for incoming connections, let’s connect to it from a client. We will do so with the following command:

ssh -vvv -p 22222 -i ~/.ssh/id_ed25519 [email protected]

In this example, we are using the previously set port 22222. We also use a custom secret key file we want to test with -i ~/.ssh/id_ed25519 and with -vvv we also use the maximum verbosity in debugging for the client.

Two typical errors for SSH server and client

Now we should be able to find the errors for the server and/or client process. Here are two typical ones, I often come across.

Wrong permissions on the server

Issues with SSH are very often due to wrong file and folder permissions. This is a typical one:

debug1: trying public key file /home/user/.ssh/authorized_keys
debug1: Could not open authorized keys '/home/user/.ssh/authorized_keys': Permission denied

When you see this issue, you might have added the public key correctly to the authorized_keys file, but it is not readable by the SSH daemon. To fix this, make sure to change the folder/file permission to something like this:

chmod 700 /home/user/.ssh/
chmod 644 /home/user/.ssh/authorized_keys

If you got an error in the last attempt to connect, the server process will most probably have died, so make sure to restart it, for the next debug-attempt.

Wrong permissions on the client

On the client, the file permissions are also very often the case of the issues. When the permissions are “too open”, you usually see a message like this on the client:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for 'id_ed25519' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "id_ed25519": bad permissions
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
[email protected]: Permission denied (publickey).

The solution to this is similar to the server. You have to make sure, that the permissions are correct, but in this case, you have to limit the access down to only the user for the private key:

chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

The public key can be readable by others as well. So the second command is usually optional.

Conclusion

There are many different issues you may have to face when configuring SSH on a server. It is really strict, when it comes to file and folder permissions, mainly to protect you from sharing secure data with others. If you happen to have a secret key too open, and you share the client/machine with multiple users, it’s probably best to discard the key and create a new one. When you use ssh-keygen to create one, the file permissions are set automatically.

I usually only use SSH nowadays to connect to servers for terminal access and for file transfer. Using key pairs is often the best way to go. But those file permissions can really be a struggle. Hopefully, you now know how to debug those issue – and I do as well, looking up how to start that debugging mode again. 😀

Show and fix Stylelint errors in PhpStorm while coding

Following coding styles is important, not only when developing for yourself, but even more when working in a team. It means fewer issues, and it also avoids unnecessary changes when using version control, which can easily cause conflicts as well.

I use PhpStorm as my main IDE and when developing WordPress plugins or themes, I nowadays use “wp-scripts” to compile SCSS or JavaScript. This package also comes with “Stylelint“, a command line tool for “linting” of your code.

Running a linter on the command line

You can configure the “lint-style” command from “wp-scripts” in your package.json file. Then you run it like this:

$ npm run lint:style

> @2ndkauboy/[email protected] lint:style
> wp-scripts lint-style


src/style-dark-mode.scss
  5:3   ✖  Expected empty line before comment  comment-empty-line-before
 11:22  ✖  Expected a leading zero             number-leading-zero
 22:6   ✖  Expected indentation of 2 tabs      indentation
 27:9   ✖  Expected indentation of 2 tabs      indentation
 72:6   ✖  Expected empty line before at-rule  at-rule-empty-line-before

5 problems (5 errors, 0 warnings)

After running the command, you will find a list of all issues that have been found. They also give you the rule names in the last column. If you want to ignore/exclude some of them in your project, you can use a custom configuration in your project.

Running the tests inside the PhpStorm code editor

While these tools are great to be used on the terminal, or later in CI (like a GitHub Action), those tests usually come only after you made the mistakes and/or even committed them. Wouldn’t it be nice to see the issues earlier? Fortunately, PhpStorm has an integration for Stylelint. You can find it at “Settings | Languages & Frameworks | Style Sheets | Stylelint”. Here you have to “Enable” it and set some configuration parameters.

When you are on Windows, using WSL2, something like this would be the settings you want to use (adjust path for your local setup):

Stylelint package: \wsl$\Ubuntu\home\bernhard\PhpstormProjects\theme-tests\wp-content\plugins\dark-mode-for-astra\node_modules\stylelint
Configuration file: \wsl$\Ubuntu\home\bernhard\PhpstormProjects\theme-tests\wp-content\plugins\dark-mode-for-astra\node_modules\@wordpress\scripts\config.stylelintrc.json
Run for files: **/src/{**/*,*}.{css,scss}

On Linux/Mac, it could look like this (adjust path for your local setup):

Stylelint package: ~/PhpstormProjects/theme-tests/wp-content/plugins/dark-mode-for-astra/node_modules/stylelint
Configuration file: ~/PhpstormProjects/theme-tests/wp-content/plugins/dark-mode-for-astra/node_modules/@wordpress/scripts/config.stylelintrc.json
Run for files: **/src/{**/*,*}.{css,scss}

In this example, I’ve limited the “Run for files” to the src folder only. On my Linux machine, it otherwise tried to check every single CSS/SCSS file in the entire project and killed my machine. If you have used a custom configuration file, like explained before, you can use this file for the “Configuration file” setting. If you don’t have one, use the default one as shown here. When you have set the path of the “Stylelint package” correctly, you should also see its version number in the settings window:

Settings for "Stylelint" showing the version number "14.16.1" at the end of the "Stylelint package" settings line.

Checking issues while you type

Now that we have set up the Stylelint integration, let’s open that file we got errors for to see them in the editor:

The errors shown in the editor, with one of them highlighted, opening a modal showing more details on that error.

In this screenshot, you can see different things regarding the Stylelint errors. On the right scrollbar, you see red indicators for each error found in the file. In the top right, you also see the 5 errors we have in total (like we also had when running the command in a terminal). In the code editor, every error is underlined in red. When hovering over the error, you see more details, including the rule name.

Repairing errors using the command line

Stylelint comes with a parameter to automatically fix all issues in a file – that can be fixed. These are usually white-space issues. To automatically fix all fixable issues, run the following command:

npm run lint:style -- --fix

Since we use “wp-scripts” in a npm script, we have to add two extra dashes in between the command and the parameter we want to pass to it.

Reparing errors in PhpStorm

Since we already integrated Stylelint into the editor, we can also fix the issues from there. To do that, click on underlined error. After a second, click on the down caret next to the red lightbulb and choose “Stylelint: Fix current file” – this should fix all fixable issues in the current file:

Conclusion

Following coding standards is very important. The right tools can help you with that, and PhpStorm with its integration of many of those “Quality Tools” makes it even easier. I only wish that PhpStorm would automatically detect these type of tool – even on a “per folder basis”, and not just for the whole project. But for me this small initial setup help me to save a lot of time to solve these errors later on.

Add text to the “Privacy Policy Guide” for your plugin or theme

With WordPress 4.9.6, we got some new privacy tools. This includes the new “Privacy Policy Guide”. Have you ever heard of it or even used it? If not, you should take a look at it on your site. You will find it at “Settings | Privacy” and then in the “Policy Guide” tab.

Overview of text snippets for your privacy policy

When you run WordPress and have a couple of plugins installed, some of them might store user data. Even the theme might do that. In those cases, the GDPR and similar laws enforce you to inform the users about that data in your privacy policy. Yet, it can be hard to know what data is stored and for what purpose. Themes and plugins can provide you with a text snippet you can copy to your privacy policy page.

Adding a text snippet to the Privacy Policy Guide for your plugin or theme

When you develop themes or plugins and store user data, make sure to add a custom text to this special page, so anyone using your plugin or theme can copy it. To add text to this page, you have to call the wp_add_privacy_policy_content() function and pass it a title and policy text. This could look something like this:

function privacy_policy_demo_plugin_content() {
    $content = sprintf(
        '<p class="privacy-policy-tutorial">%1$s</p><strong class="privacy-policy-tutorial">%2$s</strong> %3$s',
        __( 'Privacy Policy Demo Plugin is using local Storage ...', 'privacy-policy-demo-plugin' ),
        __( 'Suggested text:', 'privacy-policy-demo-plugin' ),
        __( 'This website uses LocalStorage to save ...', 'privacy-policy-demo-plugin' )
    );
    wp_add_privacy_policy_content(
        __( 'Privacy Policy Demo Plugin', 'privacy-policy-demo-plugin' ),
        wp_kses_post( wpautop( $content, false ) )
    );
}
add_action( 'admin_init', 'privacy_policy_demo_plugin_content' );

With this snippet in your plugin or theme, you should be able to see the text on the Privacy Policy Guide like this:

The "Privacy Policy Guide" with our custom text as well as one for "Twenty-Twenty-One" with the notice "Removed December 17, 2023".

As you can see in this screenshot, you will find different text snippets here. A click on the button “Copy suggested policy text to clipboard” will only copy the text after the “Suggested text:” headline, so your text might need also to include the plugin or theme name, to make sense.

Update notices

You can also see a text snippet for “Twenty Twenty-One” here with the notice “Removed December 12, 2023”. Any text that is added using this functionality will be “versioned”. WordPress will automatically detect, if the text was updated, or in this case, if the theme or plugin has been removed or deactivate. This indicates, to the site’s owner, that they might want to update their privacy policy page or remove some old text from it.

Conclusion

Even though this feature is around since May 2018, many have never recognized it’s there and/or have used the text snippets presented here. If you, like me, haven’t checked this page for your sites for some time, maybe now is a good time to take another or first look at it.

Limit resources used by Docker

For many years now, I am using Docker for my local development environment. In the beginning I was using my own custom images, but lately I’m mainly using “abstractions” like DDEV or wp-env, especially when working with WordPress projects. I run those mainly on Linux, but also have a setup on a Windows dual boot machine.

My previous Linux work laptop was only a Core i5-7200U dual-core with 16GB of RAM. Since I sometimes worked on different projects at the same time, my machine was on its limit pretty fast, with multiple PhpStorm instances and Chrome browser tabs open. Checking the resources, it became clear, that Docker was the issue, taking 50% of all resources.

Measuring resources used by Docker

Different operating systems have different tools to measure the running processes. If you want to find out, which process if using how much, you usually use them. But there is also a command build into Docker itself: docker stats. With this command, you get an output like this:

$ docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"
NAME                                                 CPU %     MEM USAGE / LIMIT
34774832e449e0c5323d0c6eb5b88fdf-tests-cli-1         0.00%     628KiB / 15.01GiB
34774832e449e0c5323d0c6eb5b88fdf-cli-1               0.00%     1.133MiB / 15.01GiB
34774832e449e0c5323d0c6eb5b88fdf-tests-wordpress-1   0.01%     15.95MiB / 15.01GiB
34774832e449e0c5323d0c6eb5b88fdf-wordpress-1         0.00%     16.63MiB / 15.01GiB
34774832e449e0c5323d0c6eb5b88fdf-tests-mysql-1       0.02%     180.4MiB / 15.01GiB
34774832e449e0c5323d0c6eb5b88fdf-mysql-1             0.02%     183.1MiB / 15.01GiB
ddev-router                                          0.82%     43.99MiB / 15.01GiB
ddev-theme-tests-web                                 0.03%     144.4MiB / 15.01GiB
ddev-theme-tests-db                                  0.11%     150.6MiB / 15.01GiB
ddev-ssh-agent                                       0.32%     5.805MiB / 15.01GiB
ddev-theme-tests-dba                                 0.01%     20.1MiB / 15.01GiB

Changing the resource limits in WSL2

This is an example taken from within a WSL2 Docker setup. You can see two projects running with their containers. The “MEM USAGE” column also shows you the “LIMIT” all containers can take. On this machine with 32GB of RAM, it’s 50% of the available memory.

This limitation is set by WSL itself. By default, it takes 50% of the available memory or 8GB, whichever is less. On older builds however (before 20715), it was taking up to 80% of the memory! This can bring even powerful machines down easily.

Fortunately, it’s quite easy to overwrite this. All you have to do is create a .wsconfig file in your user’s home directory (%UserProfile%). Here, you create a file with the following content:

[wsl2]
memory=8G

Now you have to restart WLS2 with the following command (in Windows CMD or PowerShell), which will shut down all running distros, so make sure this is OK on your environment:

wsl --shutdown

Docker for Windows will now probably report, that Docker was stopped, and you can hit the “Restart” button. Now running the docker stats command again, you should only see a 8GB memory limit. There are more settings you can overwrite in that .wslconfig file, like the number of processors used. Since the virtual server, this blog is hosted, also only has 4GB of RAM, the 8GB I have defined here is still very generous.

Limiting the resources in other operating systems

I don’t use a Mac, so I can’t tell you how to change the settings there. And on Linux, there are many different options to achieve the same. It would be a bit too much to name all the different variants. But I do have a tip for those of you using Linux.

Limiting the resources per project

Instead of limiting the resources globally, you can limit them per container or for a project using docker-compose.yml files. When running a container manually, you can pass the resources into the call. But with a docker-compose.yml file, you can also set them for an individual service, like this, in which I’ve edited the file for the wp-env project:

version: '3.7'
services:
  mysql:
    image: mariadb
    deploy:
      resources:
        limits:
          memory: 2GB
# ...

Using the resources key, you can change different values for each service. With this change applied, the stats now look like this:

$ docker stats --format "table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}"
NAME                                                 CPU %     MEM USAGE / LIMIT
34774832e449e0c5323d0c6eb5b88fdf-cli-1               0.00%     576KiB / 7.761GiB
34774832e449e0c5323d0c6eb5b88fdf-wordpress-1         0.01%     15.87MiB / 7.761GiB
34774832e449e0c5323d0c6eb5b88fdf-mysql-1             0.02%     177.6MiB / 2GiB
34774832e449e0c5323d0c6eb5b88fdf-tests-cli-1         0.00%     2.664MiB / 7.761GiB
34774832e449e0c5323d0c6eb5b88fdf-tests-wordpress-1   0.00%     16.17MiB / 7.761GiB
34774832e449e0c5323d0c6eb5b88fdf-tests-mysql-1       0.03%     86.56MiB / 7.761GiB

As you can see, all services use the previously defined 8GB, but the MySQL service is limited to 2GB now. As the MySQL service is usually the one using the most memory, this is the service I would recommend limiting first.

Conclusion

This is not a blog post on how to optimize the resources for Docker containers in all operating systems and in all different scenarios. But I hope it gives you an idea on the options and helps you, you quickly limit them on a machine with a low amount of total RAM or one few processors/threads. For my old work laptop, it really helped, and I was able to get work done a lot faster, as the other processes didn’t have to share the remaining 50% of memory.

How to get rid of the “-2” suffix on a page

If you are reading this blog post, you probably came across this issue yourself. You try to set the slug of a page (or other post type), and WordPress is appending a “-2” suffix to the slug. You are searching for a page with this slug, but can’t find one. But where is the issue coming from?

The problem

Let’s say we have a website about Berlin, and we want to create a page about the “Brandenburger Tor” (Brandenburg Gate), we would give it that title, write some content and then publish the page. We would hope to get a URL like example.com/brandenburger-tor, but we get example.com/brandenburger-tor-2 instead. But why?

The cause: media library items

With WordPress 6.4, that was just released, attachment pages are gone. But they are not really. For those of you how don’t know them, attachment pages were frontend pages one could navigate to, and that would just show the title/slug and the attachment. In some themes, it would even show the user who uploaded the file and when. This is how it looks like in WordPress 6.3 with TwentyTwenty:

Frontend screenshot showing the title/slug "brandenburger-tor", the post meta information, the image in the content and the beginning of the comment area

As you can see here as well, those attachment pages have the ability to be commented. There might be some website that would use them, but for most, they were rather useless.

With WordPress 6.4, those pages have been “removed”. When you access the URL for them, they would just redirect to the attachment file.

But the pages are not really removed. They are just not accessible anymore. They still exist in the database and have a title/slug. Now if we upload an image with a name like brandenburger-tor.jpg to the media library, the slug brandenburger-tor will be used for the attachment page, even with WordPress 6.4 without those frontend pages.

The solution: changing the slug of the attachment page

Now, to “free” the slug for our page, we have to change the slug of the attachment page. So let’s see how we can do this.

Finding the page

First, we search for the attachment name (we can also search for the slug):

List of media items with the search term "brandenburger-tor" with one entry showing the image

Editing the slug for the attachment page

We then click on the media item. At the bottom right, we find some links for the media item. With the first one, we can open that attachment page (this redirects us to the media item with WordPress 6.4) and with the second one, we can “Edit more details”:

The "Attachment details" pop with the "Edit more details" link highlighted

This will open up the “Edit Media” view, where you can see the Permalink for the image:

The "Edit Media" view with the "Permlink" at the top

In older versions of WordPress, there was an “Edit” button next to it, but this button does not exist anymore. Instead, you have to use the “Slug” screen element (meta box), which you probably first have to “active”, using the “Screen Options”:

The "Screen Options" opened with the "Slug" checkbox highlighted and checked

Now you can scroll down the page to this new meta box and change the slug for the attachment page. You could simply attach a suffix like “-attachment-page” to it:

Meta box to change the "Slug" for the page and the "Update" button on top

After you have changed the slug, hit the “Update” button.

Change the slug of the page

Now you can finally navigate to the page and update the slug. WordPress should now no longer add the “-2” suffix to the permalink.

Bonus: using the WP-CLI

If you are using the WP-CLI, you can change the slug of the attachment page using the wp post update command.

First, you have to find the ID of the page. You can find this when you hover the “Edit more details” link, or you search for attachments using the WP-CLI as well:

$ wp post list --post_type=attachment
+----+-------------------+-------------------+---------------------+-------------+
| ID | post_title        | post_name         | post_date           | post_status |
+----+-------------------+-------------------+---------------------+-------------+
| 35 | brandenburger-tor | brandenburger-tor | 2023-11-19 16:09:23 | inherit     |
+----+-------------------+-------------------+---------------------+-------------+

Once you have the ID, updating the slug works like this:

$ wp post update 35 --post_name=brandenburger-tor-attachment-page
Success: Updated post 35.

Conclusion

Having a page with that “-2” suffix is really annoying. And when you name your images or other media files similar to page names and also upload them into the media library before creating the page, you might run into this issue.

My advice would be to either create the page first, before uploading the media files, or even better, use better and more descriptive (longer) media file names before adding them to the page or media library.

If you happen to have run into this issue, now you should know how to fix this manually.

The first “official” WordCamp Germany in Gerolstein

Two weeks ago, I went to the small town of Gerolstein, to participate in the first ever “WordCamp Germany“. But wait, the first WordCamp Germany? Haven’t there been any before?

The history of German WordCamps

The first ever WordCamp in Germany was held back in 2008 in Hamburg. It was even the first WordCamp in Europe! Back in the days however, those WordCamps were not “official”, as the ones we have now, that are organized with the support WordPress Foundation / WordPress Community Support.

One year later, there was a second WordCamp in Jena, and it had a guest from the US giving a State of the Word speach.

It continued in 2010 in Berlin, which was my first WordCamp and 2011 in Cologne. Although they were all named WordCamp Deutschland (WordCamp Germany), they were still independently organized. Following two year of having a WP Camp, the reason behind the different name is a long one, which was hard to explain to the community back in the days.

Then in 2014, we had the first “official” WordCamp in Germany in Hamburg. But this was a “city based” WordCamp. All WordCamp following were always named after the city. This is why WordCamp Germany this year was the “first official regional WordCamp” we had.

Wednesday: Pluginkollektiv Hackathon

The day before the WordCamp, we had a little side event: the Pluginkollektiv Hackathon. This group of volunteers is working on some plugins that are well known and widely used, especially within the German and European community.

We tested some plugins, worked on some upcoming versions, but also discussed quite a lot about the future of the Pluginkollektiv and some of the plugin. Some plugin that were taken over had already been closed, and we took the hard decision to close some more.

Thursday: Contributor Day

The day before the conference days was reserved for the Contributor Day. I participated as a table lead for the Meta Team. Three first time contributors joined me, and we have worked on different tickets. I continued with a WordCamp.org ticket and the other worked primarily on WordPress.tv tickets. One of them was an 8-year-old ticket regarding the font-size, and we also created three new tickets.

After the Contributor Day, we had a small dinner for everyone helping with the event, followed by the “opening party”.

Friday: The first conference day

After the opening remarks, I took the chance to meet with attendees I haven’t seen in many years, or even haven’t met at all in person.

WooCommerce Blocks: Ein aktueller Blick auf die neuen Blöcke für Produktseiten, Cart und Checkout

This was the first of three lightning talks. Even though I don’t really like eCommerce, this talk by Manja Neumann was really fascinating one, showing the possibilities with the new blocks. I like the great flexibility to arrange the elements on the WooCommerce cart and checkout pages. If I ever have to work with WooCommerce again, I will be happy to give them a try.

Ein-Klick-Entwicklungsumgebung mit GitHub Codespaces

I’ve heard the project name “GitHub Codespaces” before, but never really knew what they are. After seeing this talk from Thomas Rose, I can’t wait to give them a try in one of my projects!

State of TV – Vortragsaufzeichnung, aktueller Stand und Ausblick

The last lightning talk was about the current setup we use at German WordCamp to record all the talks, held by Frank Neumann-Staude. As you might have recognized by now, all the sessions titles link to WordPress.tv and the respective videos. That’s possible, because all videos were already available just in the night of the last day of the WordCamp, thanks to our amazing TV team!

Digitale Barrierefreiheit fürs Kognitive Spektrum

I’ve seen many talks from Maja Benke on accessibility, but this one was an exceptional one. It was not focussing on the typical a11y topics like contrast, font-size, etc. But it was about people “on a spectrum” and what an accessible website means for them.

Empowering women through code: unleashing the power of diversity in tech

In the next lightning talk round, I was only able to watch this talk from Tabea Braun about the Groundbreaker Talents scholarship program, that empowers women from underprivileged communities in Uganda to become Software Engineers.

That was the last session for the day. The rest I have spent talking to more attendees and some sponsors as well.

Saturday: The second conference day

The schedule for the second conference day was packed with another round of amazing talks!

WordPress-Login-Security

Even if you think you know everything about a topic, you will learn something new! This session from Angelo Cali and Simon Kraft was no exception to that! While some “basics” were familiar, the part about passkeys was fascinating. I still don’t fully understand the security behind them, but as a modern alternative to passwords, they are something to take a look at.

Meta-Meetup für WordPress-Meetup-Organisator*Innen

After taking a break and after having lunch, I’ve met with other meetup organizers in the workshop room. We shared our experiences and exchanged ideas around the meetups in the German-speaking community. With the meetup group in Berlin, we are still online, but we really hope to get back to an in-person meetup by next year.

After this session, I was interviewed for a podcast.

Exploring the power of generative styling

The next talk I’ve attended was given by my colleague Tammie Lister. I can’t even summarize what the talk was about. Just watch the video and experience it yourself!

This was already the last talk for me at this WordCamp. I took a small break to get some new energy for the last part of the WordCamp: the After Party! I even had the chance to dance some Kizomba and Salsa 😀

Conclusion

This “first” WordCamp Germany was a great success! Given how difficult it was to travel to Gerolstein, around 240 people attended. This was a normal number of a “big” German WordCamp and not necessarily something you could have expected for the first post-pandemic event.

We don’t know yet where the next German WordCamp will be held – maybe in Munich, which was not possible this year because the team could find any affordable venue. I only know that I will attend it again, just as all German WordCamps since 2010.

How to create a Super Admin and assign it to all sites of a multisite using the WP-CLI

Two weeks ago, I’ve started to work on a new project. The whole WordPress website was versioned in Git, including a DDEV configuration and an SQL dump for local development. This was great, as it allowed me to get started really quickly. But after installing the project, I couldn’t find the login credentials.

Getting all users of the installation

The usual “admin” or “wordpress” users didn’t work, so I first checked the list of available users with the WP-CLI:

$ wp user list
+----+------------+--------------+------------------------+---------------------+---------------+
| ID | user_login | display_name | user_email             | user_registered     | roles         |
+----+------------+--------------+------------------------+---------------------+---------------+
| 11 | jo         | jo           | [email protected]         | 2023-06-01 01:30:30 | administrator |
| 22 | jane       | jane         | [email protected]       | 2023-06-02 02:30:30 | administrator |
| 33 | john       | john         | [email protected]       | 2023-06-03 03:30:30 | administrator |
+----+------------+--------------+------------------------+---------------------+---------------+

For none of these users (names have been changed) I could find any login credentials. Therefore, I had to create myself a new user.

Create an administrator user

I usually use the --prompt parameter when creating a new user (or other entities), so I don’t miss an important parameter:

$ wp user create --prompt
1/15 <user-login>: wapuu
2/15 <user-email>: [email protected]
3/15 [--role=<role>]: administrator
4/15 [--user_pass=<password>]: wordpress
5/15 [--user_registered=<yyyy-mm-dd-hh-ii-ss>]: 
6/15 [--display_name=<name>]: 
7/15 [--user_nicename=<nice_name>]: 
8/15 [--user_url=<url>]: 
9/15 [--nickname=<nickname>]: 
10/15 [--first_name=<first_name>]: 
11/15 [--last_name=<last_name>]: 
12/15 [--description=<description>]: 
13/15 [--rich_editing=<rich_editing>]: 
14/15 [--send-email] (Y/n): n
15/15 [--porcelain] (Y/n): 
wp user create --role='administrator' --user_pass='wordpress'
Success: Created user 44.

Now I was able to log in to the site! But as soon as I was logged in, I’ve recognized that this was a multisite installation. So my new shiny administrator user was not able to see all the other sites.

Promote a user to a Super Admin

Using the WP-CLI you need a single command to promote a user to a Super Admin:

$ wp super-admin add 44
Success: Granted super-admin capabilities to 1 user.

After running this command, I was able to see all sites listed in the “Network Admin”. I would now be able to work with all of them. But since my new account was not directly associated with any of those sites, they would not show up in the “My Sites” dropdown in the adminbar.

Adding a user to all sites as an administrator

This specific multisite had only three sites, so adding my new user as an administrator to all of them is a rather quick task. But what about a network with 100 sites? That would take quite long and you might miss one site. Fortunately, you can use another WP-CLI command to solve this.

Getting a list of all sites

We would first need to get a list of all sites. This can be done with the following command:

$ wp site list
+---------+---------------------------+---------------------+---------------------+
| blog_id | url                       | last_updated        | registered          |
+---------+---------------------------+---------------------+---------------------+
| 1       | https://example.com/      | 2023-06-01 01:30:30 | 2023-06-01 01:30:30 |
| 2       | https://example.com/de/   | 2023-06-02 02:30:30 | 2023-06-02 02:30:30 |
| 3       | https://example.com/en/   | 2023-06-03 03:30:30 | 2023-06-03 03:30:30 |
+---------+---------------------------+---------------------+---------------------+

To assign the new user to one of these pages with a specific role, we can use this command:

$ wp user set-role 44 administrator --url=https://example.com/de/
Success: Added wapuu (44) to https://example.com/de as administrator.

We would now need to do the same things for every single site, using the url field. But for many sites, this also takes some time and we might make a mistake. So instead, I was looking for a single line command.

Adding the user as an administrator to all sites

I’m not the best shell developer, but with some trial and error, I came up with this command:

$ wp site list --field=url | xargs -I {} wp user set-role wapuu administrator --url={}
Success: Added wapuu (44) to https://example.com as administrator.
Success: Added wapuu (44) to https://example.com/de as administrator.
Success: Added wapuu (44) to https://example.com/en as administrator.

This command is getting the list of sites, as shown before, and for each of them only the url field. This is then passed with xargs to the second command, that would add the user to the site. Make sure to set the correct username (wapuu in this example) in the second command.

Conclusion

With some WP-CLI magic, you can quickly create an administration user, grant Super Admin permissions and associate it with every site in a multisite. I hope you’ll find this useful in one of your (future) multisite projects as well.