Kau-Boys

One of the questions I get a lot is: what plugin do you always use. My answer is usually: none … except for when I still develop a site. Then it is Query Monitor and here is why.

What does Query Monitor do?

The Query Monitor plugin is THE debugging plugin for WordPress. It started with only helping to debug SQL queries, but can now be used to debug almost anything in WordPress. I’ve written a couple of posts on it before, but let me list a few of the hundreds of debugging features it has:

• SQL queries
• HTTP request
• Loaded template files (partials) and template hierarchy file used
• Loaded JavaScript files
• Loaded CSS files
• Hooks (actions and filters) used
• Loaded translation files (and listing those that are missing)
• HTTP API requests performed by the backend
• Updated transients
• Permissions (capabilites) checked
• Information on the environment (PHP, database, WordPress, server)
• List of all true/false Conditional Tags on the current page

Query Monitor is available on the frontend and backend. By default, only administator users can use it, but you can set an authentication cookie to even use it when logged out, which is really helpful when you want to debug a site as a normal visitor.

Why do I use Query Monitor?

If you are in the process of creating a website and something does not work, you can take many approached to debug the issue. For many typical issues, however, you don’t even need to activate the WP_DEBUG mode or use something like Xdebug. The Query Monitor plugin might just tell you what went wrong.

It is also really helpful to find slow SQL queries and then investigate further why they are so slow. I also use it a lot to find out why some translations do not work – often times because WordPress tries to load a file with the wrong name.

I don’t know how many hours or even days of debugging time I have saved, just because I always use Query Monitor. At one point, I even added an alias to my Linux system to install Query Monitor using the WP-CLI, just because I did that so often. 😅

Conclusion

If you develop a website and need to debug it, then you should give Query Monitor a try, if you don’t already have it in your toolbox.

You can also extend Query Monitor with your own panel, which I have described in the blog post “Adding a custom panel to Query Monitor” earlier this year.

Do you use Query Monitor? What is the feature you use the most?

I have a podcast website (but unfortunately, there have not been any new episodes in years). When I first started my journey into podcasting, I was wondering how to best set a site up. If you want to keep it really simple, you don’t need any plugin for a podcast. Since WordPress can embed audio files, you could just upload the podcast episodes into your media library and embed them into a normal blog post. But if you want to allow users to subscribe to your podcast, add transcriptions or subtitles, have a nice web player with more option, and other typical podcast features, you may want to use a proper plugin to help you.

What does Podlove Podcast Publisher do?

There are multiple plugins under the Podlove brand. The major on is the Podlove Podcast Publisher plugin. There is also the Podlove Web Player, but this is optional, if you use the publisher plugin. The publisher adds a new custom post type “episodes”, where all the content work is done. For each new episode of your podcast, you would create a new entry here. You should configure the settings of the published before you add your first episode. This is described in a short video on the Podlove documentation page.

One of the cool features of Podlove is the fact that you don’t need to store the files on the same server as your WordPress site. You can have them on an external server, or even on an S3 storage, as long as you can control the file names. You set the base path for the episodes, and as long as Podlove will find filenames like episode-name.mp3, episode-name.m4a, episode-name.chapters.txt, episode-name.vtt, and so on, those external files work just as good as files on the same server. This means you can even use one of these (premium) podcasting services and still (also) host the podcast on your personal website.

Besides episodes and the descriptions, Podlove Podcast Publisher can manage other things a podcast would need:

• RSS feeds (to subscribe to your podcast)
• Contributors (hosts and guest, including descriptions and link to social media profiles)
• Donation links (for hosts and also guests)
• A extensive web player with controls for speed, transcripts and subtitles, download buttons, etc.
• Integration to external services
• A subscribe button/widget
• and much more …

On integration is with the Auphonic project. I do use this project to enhance the audio quality of the audio and video productions and Podlove can send all your files to Auphonic, have it optimize the files, and store the optimized files back on your server. But I have not used the integration, yet.

Why do I use Podlove Podcast Publisher?

Creating a podcast takes more than just speaking into a microphone, especially, when you are the person responsible for the post-production and publishing. Since I took that role for the podcast I co-hosted, I wanted to have a plugin that would support me as much as possible. If all the features Podlove is offering, it made the process really easy, after the first setup, and publishing a new episode was as easy as publishing a blog post. Using the template feature of Podlove made it even easier.

Conclusion

If I’d start a new podcast today, the Podlove plugin would be the first one I would install. I have not seen a second plugin that comes even close. And since I like the idea of “owning my files”, I love the possibility to have them on the same machine, while still being able to move them to an external storage any time, without any interruptions.

Do you have a podcast? Then why not share them here to get more subscribers? And if you use WordPress for your podcast, how do you manage it?

As mentioned in the last blog post, I have around 18 plugins active on this blog. For some, this sounds like a lot, but it really isn’t. I always say it’s not the number of plugins, but their quality and complexity. It can be tough to keep track about all the plugin you have. Are they still actively maintained? Have they been tested with your current WordPress version? Do they auto update? All these questions can be answered with the Plugin Report plugin.

What does Plugin Report do?

When you installed it in a single site, it will add a “Plugin Report” page in the “Plugins” dashboard section (in a multisite installation, you’ll find it in the network dashboard). When you navigate to this page, it will show you a table with all the plugins you have installed, and it will immediately start to retrieve the following information for each of them:

• Name
• Author
• Repository
• Activated
• Installed version
• Auto-update
• Last update
• Tested up to WP version
• Rating

The “Repository” column is an interesting one. It may say “wordpress.org” in green, which is the good state. It might be red with a note “wordpress.org, plugin not found”, which can still be OK, if this is a custom plugin. But if the message is “wordpress.org, plugin closed”, you should check on the plugin. It might have been closed for security reasons. If the “Last update” for such a plugin is also quite old, then this might be a potential security risk for your site.

All data is cached, so the plugin does not have to query the status of each plugin every time you go to that page. But you can choose to clear the cache and get fresh data.

Why do I use Plugin Report?

With nearly 20 plugins, you can’t really check on all of them manually, and you also won’t remember when you’ve seen the last update to one of them. There is also still an issue with plugins that have been closed on wordpress.org, for whatever reason: you don’t get any information about this fact. A plugin might have been removed years ago or closed because of a security issue. You would not be able to get any more updates for them, but since those updates also don’t show up, you will probably not be aware that you might have an insecure plugin in your WordPress installation. Just for this one use-case, the Plugin Report can help you, to only use plugins that are still maintained, or at least could get an update at some time.

Conclusion

The Plugin Report cannot really tell you which plugins might cause issues, but it gives you an overview on the current status on each of them. You, or the person responsible for the maintenance of your site, can then act upon this information. I use the plugin on many of the WordPress installations I maintain, and it helps be to quickly see, which plugins I might want to check on wordpress.org for current information.

The plugin was initially developed by Roy Tanck and is now maintained by the German community member Torsten Landsiedel, who is also a member of the Pluginkollektiv.

Are you also using this plugin? Or do you have a similar tool that gives you such information? Please share your tools and workflow in a comment.

The plugin I write about today is one of the most important ones for my blog. I could live without many of the around 18 plugins I have on this blog. But as this blog is presented to you in two languages, I need a plugin to connect the two blogs in the best way possible. And for me personally, that best way is using a multisite.

What does MultilingualPress do?

It utilizes the WordPress multisite feature to allow websites (even multiple ones) in more than one language. In my case, the main site of my multisite is the English one, the second site is the German one. MultilingualPress then lets me connect any content (posts, pages, taxonomies, custom post types, custom taxonomies) with each other. If you have a larger multisite, you can even connect more than two sites with each other or you create “multiple sets” of websites that have different languages. It is really very flexible.

When I write new blog posts, I usually write them in English first, even though my native language is German – it helps me to train my English writing skills. After I’ve finished a blog post, I let MultilingualPress create a connected German blog post in draft. With the release of version 5.0, MultilingualPress now offers automatic translations. You can either use DeepL, Amazon Translate or the OpenAI API. The later two only offer premium versions, that’s why I use DeepL. They give you a free tier with 500,000 characters per month, with is plenty. So far in December, my first 11 advent calendar blog posts only used 34,536 characters, so I’m far from every reaching that free limit. The only things that is not available in the free DeepL version is “informal German”, which I use for my German blog posts. But since I turn the “tone” of my German blog posts into what I would write naturally, I change lots of text anyway. It still saves me a lot of time. I do use the Block Editor for my posts, and MultilingualPress handles the translation of blocks perfectly. The only thing that “breaks”, are code blocks, that don’t come back correctly from DeepL.

You can even have MultilingualPress translate comments. I have not yet tested this feature – and I need to clean up or move some comments into the correct language before that – but I will try this feature as well. I might also blog about the process, but that has to wait for next year.

Why do I use MultilingualPress?

In the early (bilingual) days of my blog, I was using qTranslate. But when MultilingualPress came around more than 13 years ago, I’ve migrated. I see a lot of benefits in using a multisite for multilingual pages. Too many to name them in this blog post. But if you’ve every tried to create a larger multilingual website with single site plugin solutions like WPML or Polylang, you probably know about all the issues you run into.

In my blog post two days ago about the Individual Multisite Author plugin, I’ve mentioned that I don’t actually need that plugin anymore. That’s because MultilingualPress also offers a module to translate user information. But I also haven’t tested this module, yet.

Conclusion

If you want a multilingual website where you can really translate every single bit, even plugin and theme settings, then using a multisite is probably the best approach. MultilingualPress does not offer a free version, but it’s worth every penny. OK, I have to admit, that I don’t pay for it, as I now work for the agency, that develops it. But I have used it more than 10 years prior to joining them.

As mentioned in the blog post from yesterday, I am using two different statistics plugins on this blog. The “simple one” is Koko Analytics, the advanced one is Matomo.

Using Matomo with a WordPress site comes in two variants. You can use the Matomo plugin, which is the easier version. This basically installs a full Matomo copy into the wp-content/plugins/matomo/app folder. Updating the plugin also updates the Matomo installation, which is quite convenient. But it also adds more than 50 tables (including 30+ “archive tables”) into your WordPress database. This can be quite messy and is only recommended for very small sites, even by Matomo. If you care about separating your WordPress database from Matomo, or you run a multisite, like I do, I would recommend a different way.

What does Connect Matomo do?

I contrast to the Matomo plugin, you can use the more lightweight Connect Matomo plugin, formerly known as WP-Matomo or WP-Piwik (Piwik was the old name for Matomo), to connect a WordPress installation with a “Matomo On-Premise” installation. This means that you have to install Matomo on your webserver as a separate app. Or you use an external service that offers you a Matomo installation. You can also connect it to Matomo Cloud, but with currently 22 Euro a month, this is a quire costly option. I mean, the beauty of Matomo is the fact, that you can run it on your own hosting, right?

I don’t want to go into too much detail on how to set up a Matomo installation and how to connect it to WordPress. This could be covered in a whole blog series, as it can get quite complex. In my case, I have it on the same server as my WordPress multisite. I then use the “Self-hosted (HTTP API, default)” option for the “Matomo Mode”, point it to the “Matomo URL”, give it my “Auth Token” and it automatically adds all sites of my multisite to Matomo. In the “Enable Tracking” tab, I can choose between different ways to embed the tracking code and where it should be placed. Once these two steps are completed, tracking begins.

Inside WordPress you get a small dashboard section, that shows you the visits of the last 30 days, an overview of visits and visited pages from yesterday, and metrics like browsers, screen resolutions, device types, operating systems, cities, countries, keywords, referrers, and much more. To view the full statistics, you would log into your Matomo instance. Even if you use the Matomo plugin, it would open the “Matomo app” and not embed everything into WordPress.

Why do I use Connect Matomo?

As I want to have more advanced statistics and Google Analytics was no longer an option, Matomo was the obvious alternative. Since I did not want to stuff the Matomo tables into my blog database, and as I also use Matomo for other WordPress sites, I chose the Connect Matomo plugin to integrate it into my blog.

For my yearly “blog birthday” posts, I do consult Matomo, to find the most popular blog posts and the days with the most visits. It also helps me to understand where visits come from (which referrer and which country/city) and what devices are used. This help me to optimize the page and to find the right content for my audience.

Conclusion

If you need more than just a simple statistics plugin, and you want to be privacy-friendly, then Matomo is a great choice. You only have to decide how to use it with your WordPress installation. While the separate Matomo instance keep things more clean, it comes with a little maintenance overhead. But Matomo has a great update process, almost as easy as WordPress, and it never failed for me.

Are you also using Matomo? If so, which plugin do you use? And to do run your own instance, or do you have someone hosting it for you or even use the Matomo Cloud?

When I’ve removed all plugins and services using cookies, I’ve also cut ties with Google Analytics. But I still wanted to have a plugin that would give me some statistics and insights into my websites and the content that is read most often. I was using three potential replacements simultaneously, while still having Google Analytics as a reference. The two more “simple plugins” will be covered today.

What does Koko Analytics do?

The Koko Analytics plugin does not offer a ton of statistics, but the major onces are on board in the free version (there is also a premium one, which I have never tested, and don’t really need). It does track page views and also shows where people are coming from. It does not list things like countries, devices types, screen resolutions, search term, or other metrics. But it does offer a nice dashboard widget which shows the top pages and referrers of the day. You can exclude user roles from tracking and exclude static IP addresses.

The tracking can be set to “cookie”, which can be used to detect repeated pageviews. This requires a cookie policy and/or consent. There is also a (new) “cookieless” option, that tries to detect repeated visits without a cookie. I use the legacy “none” setting, which does not really care about unique or repeated pageviews.

All data can be deleted after a certain period, unless you set this period to zero, to never delete data (which I would usually do). All in all, it’s a nice little statistics plugin, if you only care about how many pages/posts were viewed each day.

What does Statify do?

This is another plugin of the Pluginkollektiv, but I don’t regularly contribute to this one. So, how is the Statify plugin different to Koko Analytics? It is even simpler, as it only offers a dashboard widget with the latest pageviews and referrers. You can set the period of days to show in the widget, and you can also set a deletion period (or set it to zero, to not delete old statistics). Just like Koko Analytics, it is very privacy-friendly, as it does not set any cookies. It doesn’t even offer an option that would set a cookies, unlike Koko Analytics.

More statistics with the “Statify – Extended Evaluation” add-on

There are a few add-ons to Statify, and I use one of them myself: Statify – Extended Evaluation. This plugin will soon be integrated into Statify, and it extends the statistics with overviews of pageviews per month and year. It also gives you a view of the most popular pages, posts, and other public post types (like episodes on my podcast website). You can also use it to export the stats into a CSV file.

Why do I use those plugins?

I use Koko Analytics and Statify (in combination with Statify – Extended Evaluation) on different pages, depending on the needs I have. On this blog, I do use Koko Analytics, as Statify was tracking too many “false positives” (potentially some bots, who like my blog) and it was too much off from what Google Analytics was showing me in numbers.

Conclusion

If you need a privacy-friendly (and cookieless) plugin, either of the two can serve you well. But you’ll only get limited statistics, mainly pageviews and referrers. I also use another statistics plugin, that give you a lot more, but more on that tomorrow.

Do you use one of the two plugin? Or maybe one of the other free (or premium) statistics plugins out there? Then share them in a comment.

At the end of every blog post, you’ll find a “Posted by” box, with a short introduction of the author of each blog post. This text comes from my WordPress user profile on this blog, and this can be an issue on multilingual blogs.

What does the plugin do?

Since I use a multisite for this blog, there is only one “user object” for me as the author of blog posts. Therefore, there is only one “Biographical Info” text field that can be used for the “Posted by” box below each blog post. When you write in two different languages on two different sites in a multisite (or you have some other “persona” on different pages), you end up having only one text for all of them.

This is where I’ve found “Individual Multisite Author” as a perfect little helper plugin for me. The plugin does offer a bio text field on each sub-site in your multisite installation. It automatically overwrites the default field and also returns the correct content on the different sub-sites, when the “WordPress API functions” are used to get this information.

The plugin is also developed by a member of the German WordPress community: Thomas Maier. It is always funny if you have an issue, then find a solution, and even know the person who wrote it. 😊

Why I use this plugin?

In the early days of my blog, I was not using a multisite. Even after I switched, I didn’t had a “Posted by” box below the blog posts. But as soon as I added a text here, I ran into this issue and was happy to have a tiny plugin that was exactly what I needed to get a translated bio for the second language.

Conclusion

If you run a multisite, and you need to have a different author bio on the different sub-sites, either because they are in a different language or you are using them for different purposes, this plugin might be for you.

Some months ago, I found out that I don’t even need the plugin anymore, since in the multilanguage plugin I use offers a similar functionality. But since the plugin still serves its purpose, I have not “migrated” to the other solution.

As I’ve mentioned yesterday, I do want to share another plugin from Matthias Kittsteiner and the Epiphyt brand. Today, I want to present his plugin Impressum Plus. The term “Impressum” is mostly used on German website, and is of latin origin. It comes from books and magazines, where it lists the people responsible for the media. It can be found on almost all German websites, since it is mandatory, when the site is not purely private/personal, which is hardly possible. On translated pages, you often find the translated term “Imprint”, which is not really the same. There is no real equivalent in many other countries, but you would typically find sites like “Legal Notice” with similar content. Nevertheless, there are certain things such a page must list, and this is where Impressum Plus comes into play.

What does Impressum Plus do?

There is a free version, simply called “Impressum“, which can generate all the required content for such a page. It is not limited to German speaking countries, but can also be used for those how would have a “Legal Notice” page. It offers you some text fields and fieldsets for your name, address, email address, phone number, entity type, and many more. You can then either use a block or a shortcode to place it on a page and have it dynamically generate the final page. You can choose to include headlines or only write down the content without any headlines in between.

In the “Plus” version, it also offers the dynamic generation of the privacy policy and the accessibility information pages. The generation of up-to-date privacy policy pages can be a time-consuming task, that needs to be done regularly. If you don’t want to do that manually, then the plus version might help you here.

Why I use Impressum Plus?

I have to admit, that I do not use it on my German site, yet. But I do use it on the English site of this blog. I usually used one of these “Privacy Policy Generators” and manually edited them to fit the services I use on this blog. When Impressum Plus was first released, I bought a license to replace this manual page. This was almost 6 years ago. 😅

I have even customized it a bit, since the plugin offers some filters to change the dynamically generated text. I use one combined page for the Impressum and privacy policy and I needed to change the heading levels, which I did with this “hack”:

function ipc_privacy_policy_content( $policy ) {
	$headline_level_increase = 1;

	return preg_replace_callback(
		'#<(/?)h(\d)>#',
		function ( $match ) use ( $headline_level_increase ) {
			$new_headline_level = intval( $match[2] + $headline_level_increase );

			return "<{$match[1]}h{$new_headline_level}>";
		},
		$policy
	);
}
add_filter( 'impressum_privacy_policy_content', 'ipc_privacy_policy_content' );

There are some more (and better) filters in newer versions, which you can find in the developer documentation.

Conclusion

If you need to have an Impressum, which you most likely need to have, unless your website is password protected and only for your family, then having the Impressum generated for you saves you time and protects you from legal risks, as the requirements changes from time to time. This is even more true for privacy policy pages. Impressum Plus is the only premium plugin I have a subscription for, but it lets me be less stressed about these pages. Now I only need to finally also use it on my German site. 😁

Two days ago I wrote about Complianz, the plugin I have used to implement a cookie banner. In this blog post, I’ve mentioned that I have removed any cookies from this blog and that I am using a two-click solution for any embed. This is where the Embed Privacy plugin comes into play.

What does Embed Privacy do?

If you want to embed some external resource in WordPress, you often simply paste the URL to this resource, like a YouTube video, into the editor, and WordPress will automatically embed it using the oEmbed format. This is really handy, but it also means that as soon as someone visits this page, the external resource will be loaded, and personal data might flow to this external service. To comply with the GDPR, CCPA, and similar regulations, this is often not allowed. You need consent from the person to show the embedded resource and (potentially) send data to this external service. You may get this consent through a category of your cookie banner, or you let them approve the embed. This is what Embed Privacy allows you to do. It automatically replaces many embeds on your site with a “two-click solution”, meaning that the first time someone sees an external embed, they are asked if they want to view it. Here is an example of a YouTube embed from a recent blog post:

To display the video, you can either click on that “overlay”, or you can choose to always display YouTube embeds on the page. There are also links to open the privacy policy of the embedding service and a link to open the external resource. Embed Privacy also offers an option to download the “placeholder” image from the external service, if this is available. Those placeholder images are stored/cached into the folder wp-content/uploads/embed-privacy/thumbnails/ on your server, so those as well do not load anything from the external server by the person visiting your page, making it a privacy-friendly option.

Why do I use Embed Privacy?

As mentioned earlier, I do not like to have a cookie banner on websites, if there are other alternatives. And in my opinion, Embed Privacy is the perfect plugin to implement two-click solutions for many embeds. If you need to embed a service that it does not handle already, you can add your own services. I’ll probably write a blog post on how to do that in January.

Another reason I like this plugin is that fact that it is developed and maintained by the German developer Matthias Kittsteiner under the Epiphyt brand. I may, or may not, write about another of his plugins. Maybe as soon as tomorrow. 😉

Conclusion

If you are like me, and you want to use a two-click solution for embeds, why not give Embed Privacy a try? Are you already using it or do you use a similar solution, then please share your thoughts in a comment.

It’s still surprising that Contact Form 7 has so many installations, but it is the third most installed plugin on the WordPress Plugin Directory. It is rather “technical”, since you have to build your forms using shortcodes. Only integrating it into a page also works with a block nowadays.

What do the plugins do?

The Contact Form 7 plugin is a form plugin, so it’s used to provide a form on a website that sends an email. It usually sends an email to the owner of the website, but it can also send a second mail, that is usually used to send a copy to the person that filled out the form. Mails are sent using the wp_mail() function, so it needs a web server that is configured correctly.

To prevent form spam, you can use Contact Form 7 with Akismet, Turnstile from Cloudflare and reCAPTCHA. If you want a more privacy-friendly alternative and one that is not using an external service, you can add “honeypot fields” to your form. The plugin I use here is now called CF7 Apps (previously it was called Contact Form 7 Honeypot). It does offer more that just honeypot fields, but this is what I mainly use it for. You can add multiple honeypot fields, and in many cases, this is enough to prevent most form spam.

Another thing that Contact Form 7 does not do by default is storing the mails it sends. You can either use one of the generic “mail logging” plugins, that would log any mail sent by WordPress, or you can use the Flamingo plugin, which was created by the developer of Contact Form 7. It’s a very minimalistic plugin that shows you an “address book” and a list of mails that have been sent with the forms from Contact Form 7.

Why do I use these plugins?

I use Contact Form 7 in combination with CF7 Apps on two websites that I maintain. On one of them I also use Flamingo. Since both of these pages only need simple forms and I know how to use Contact Form 7 to create usable and accessible forms, installing a “more mature” forms plugin feels like an overkill to me.

Conclusion

If you can handle editing a form using shortcodes and only need simple forms without things like multiple page forms, conditional fields, etc., then Contact Frm 7 might be all you need. Many themes even come with some better default styles, since it’s so widely used. And there are also many plugins adding additional functionality to Contact Form 7, like the other two plugins I’ve presented in this blog post.

Do you also use Contact Form 7? Maybe with other additional plugins? Or do you use a larger form plugin? Then please share your thoughs in a comment.