Kau-Boys

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.

I don’t like cookie banners, but who really does, right? On this blog, I’ve removed everything that would need any “consent management tool” and switched to either cookieless solutions or two-click options. More on that in the following blog posts.

But on some site, you do need a consent tool. Then you have the option to choose between a wide range of different tools, both free and premium. Many large sites even use complete external services, that might not even come in the form of a WordPress plugin. Some solutions that are WordPress plugins are either exclusively premium or offer a free version, that is so limited, that it can’t really be used. This is where I’ve found the Complianz plugin as one that is indeed usable in its free version.

What does Complianz do?

Well, it’s a cookie consent banner, so it tries to help you to have your site only set cookies, when they are either necessary or consent was given to set them. It can also block external embed, like videos from YouTube, Vimeo and other streaming portals or embeds of Google Maps, Twitter, Instagram, and so on. It also records the consent given, to comply with regulations like the GDPR.

It offers a “cookie scanner” that runs on your blog, and not through a (paid) external service, trying to find all the cookies your site is setting. You can then put those cookies in different categories or add custom ones. It also creates a dynamic “Cookie Policy” page listing all the cookies in the different categories.

There is also a premium version of the plugin that offers more advanced things like statistics, A/B testing, geo IP consent, more documents, and more. But for a simple website that only cares about allowing visitors to accept certain cookies, those features are not really necessary in my opinion.

Why do I use Complianz?

From all the different cookie consent plugins I have tested, this one serves my needs best in the free version. If I don’t have a budget for premium solutions, Complianz is the plugin I would use. If I need to use one of these solutions in the first place.

Conclusion

If I can decide on the services used on a website, I would always try to chose only those, who are privacy-friendly and not set any cookies or load external data. But if I do have to use such services, I will use a plugin like Complianz, that is free and runs on the website itself, and not a paid external service, to implement a cookie consent banner.

Those two plugins might come as a surprise for some of you. I’m using the Block Editor, since it was still in a beta state and only available through the Gutenberg plugin. So I am not the usual user of the Classic Editor plugin. But I do have two sites I maintain where I’m using it.

What do the plugins do?

Both Classic Editor and the Classic Widgets plugin are used to preserve the “legacy components” from older WordPress versions that would nowadays use the Block Editor interface. The Classic Editor plugin allows you to either “deactivate Gutenberg” and use the old TinyMCE editor for your content, or you can decide on a per content element basis which editor you want to use.

The Classic Widgets plugin on the other hand brings back the old “widget admin area”, that was replaced with the “Gutenberg UI” in WordPress 5.8 and which now allows you to use any block in any widget area.

Why do I use both plugins?

The Classic Editor plugin is used on the podcast website I host. The podcast plugin I use there (this one will be presented in another blog post) does not fully work in the Block Editor. All “meta boxes” do work, but the editor crashed, at least for existing episodes.

I also use the plugin on a website of an acquaintance. That acquaintance is not a “technical person” and the new UI in the Block Editor for some plugins make it harder to create and edit content.

The Classic Widgets plugin is used on this very blog. I still use a theme that was written around 15 years ago, and that is using some widgets and widget areas that don’t work well with the new “Block Editor Widget Area”. As soon as I finally replaced the theme with an FSE one, I can remove this legacy plugin as well.

Conclusion

Even though I am a big advocate for the Site and Block Editor, I do see cases where plugins like Classic Editor or Classic Widgets are necessary. It should be our goal to make these plugins obsolete, especially if we develop plugins ourselves, but the reality is, that they will still be around for a couple of years.

Are you also using the Classic Editor? And do you it because you don’t like the Block Editor, or also because you have to deal with legacy websites?