Kau-Boys

On one page I maintain, there is a small calendar with courses and workshops. To manage those, I had to choose a plugin that offers all the features I needed. As I had more complex requirements for an event management plugin for work projects, I decided to go with the free version of the “The Events Calendar” plugin, and here is why.

What does The Events Calendar do?

First of all, it adds a couple of custom post types: Events, Venues and Organizers. It also adds two custom taxonomies: (Event) Tags and Event Categories. You don’t really need to use all of them, but if you do, you allow people to find events in the same venue, from the same organizer, and so on.

When you create an event, you can set a start and end time, or make it an “all day event” (even spanning multiple days). For the venue, you can choose to show a map in an individual event. You can also define costs for the event, but this only shows a price. The core plugin does not offer a ticketing system, let alone payment options. There is a free add-on plugin “Event Tickets and Registration“, which allows selling of tickets with Stripe or a PayPal business account. But since registrations are not done on that website I’m using it on, I don’t have this extension installed.

In terms of listing events, you have a month, list and day view. It comes with an events list widget and a keyword search. People can subscribe via an iCalendar file, Google Calendar, Outlook 365 and Outlook Live.

Events can be edited with blocks in the Block Editor, but on the site I maintain, we use it in combination with the Classic Editor, since the UX changes were just a bit too complicated for the person running the site.

Other add-ons to the plugin

There are pro versions of the core plugin and the tickets add-on. The quality of the official extensions is very good. The prices per site are justified, if events are your main business on those sites or if you even sell tickets. For sites where events are just a minor thing, I find them too high, and would probably use external services that charge you a percentage on a ticket sale.

The free version of the calendar is lacking one major feature: displaying events of a certain category on a page. This is useful, even for a personal site, and does not justify the high price for the pro version in my opinion. Luckily, I’ve found a plugin just for this purpose: The Events Calendar Shortcode & Block. With this plugin, you can list events of a category on a page or post, using either a shortcode or a block. It even offers an Elementor widget and Bricks element, but since I don’t use those two page builders, I don’t know how well they work. Even this free plugin has a pro version, but the free one is really all I need on that one website.

There are a lot of add-on plugins in the WordPress.org Plugin Directory, and even if you don’t find one that fits, you can customize The Events Calendar quite good, since it has a lot of actions and filters, which you can find in their DevDocs or learn more about how to use the plugins in their knowledgebase. This is another strong argument for me to use this as my main events management plugin. Other plugins also offer a deeper integration into this plugin, like the MultilingualPress plugin I’ve covered some day ago.

Conclusion

When it comes to event plugins, I usually always use The Events Calendar. For one, because I’m quite used to it, but even more because I like it’s code quality. I had to use another at one point, which offers recurring events (this is only available in the pro version of The Events Calendar), but the code quality was so bad, that I hated working with it every time. With more than 700,000 active installations, just for the free version, it’s also the most used event plugin from the WordPress.org Plugin Directory.

Have you used The Events Calendar before? Or do you use a different one? What make you choose one of the alternatives?

Since I run a blog with mostly technical topics, that also contain code snippets, I want to make those more readable by using syntax highlighting. Many years ago, I chose a plugin that is also available on wordpress.com by default. It comes with different styles and many languages is supports. For languages that are missing, you often find an add-on plugin. Or you write your own one, which I did.

The SyntaxHighlighter Evolved plugin was initally developed by Alex Mills who passed away in 2019. Development is now continued by Automattic.

What does SyntaxHighlighter Evolved do?

As the name indicates, it is a plugin to syntax-highlight code. I use it in every blog post where I share code with you. You can use legacy shortcodes, either one per programming language like or a generic one passing the programming language like in your posts and pages. But you can also use a block and select the programming language from the block settings. You can also set other options here, like highlighting specific lines or a toggle to show line numbers.

The plugin used the syntaxhightligher from Alex Gorbatchev that is still actively maintained. It comes with two different "Hightlighter Versions": 2.x and 3.x - you can only use one at a time. I still use version 2, since it offers a "wraplines" feature I find quite useful. The package also have a version 4, but this one has not yet been integrated into the plugin.

Why do I use SyntaxHighlighter Evolved?

I regularly share code. Since I want to make it more readable, I want to use a syntaxhighlighter. I have chosen this plugin many years ago and migrating to a different one would be quite a task. But since it is not up to date with the latest version of the package, it might be time to find a replacement. It also sometimes breaks code blocks, especially if they contain HTML or some "HTML special chars" in other programming languages.

Add-ons to the plugin I use

I do use two add-ons. I have a couple of blog posts about the Apache webserver, and the highlighting for the configuration files are not in the core package. I do use the "SyntaxHighlighter Evolved: Apache" plugin here, which is not available in the WordPress.org Plugin Directory, but only on an external website. I've also blogged a lot about Sass, and there was no add-on plugin available for this language, so I created one: "SyntaxHighlighter Evolved: SASS Brush". Those add-on plugins rarely need to be updated. Only if the keywords of such a language change. For my Sass plugin, I just use the official JavaScript file with those keywords and update them in my plugin.

Conclusion

If you want to offer better readable code snippets in your posts and pages, a syntax highlighting plugin can make a huge difference. I still use a rather old one, but it still works.

Do you use a syntax highlighting plugin? Maybe you know one that offers a "wraplines" feature, and is maintained better than the one I still use. Then please share it in a comment, I would love to give it a try.

Even in December 2025, it is still not possible to upload SVG files to a WordPress website. As an SVG file can contain JavaScript code and is therefore considered a “potential security risk”, WordPress core does not allow the upload of SVG files. There are people trying to allow it in the future, while filtering out malicious code, but it will probably still take some time.

In the meantime, you can use a plugin or some custom code, to allow uploading an SVG to WordPress. In the 2015 advent calendar, I shared a snippet on how to allow the SVG upload (unfortunately, this blog post has not yet been translated to English).

But if you not only want to upload the SVG and use it in theme settings, but also put it into a post or page, I would recommend using a plugin that integrates SVG support better into WordPress. Here are two plugins I’ve used on different sites.

What does Safe SVG do?

The Safe SVG plugin is developed by 10up, a highly reputable WordPress agency. It not only allows you to upload an SVG, but also does something with the file. It sanitizes the SVG, which means that it tries to remove any code that might cause a security risk to your site. It also optimizes the SVG using the SVGO tool, which I also use (either in the browser or as an Inkscape extension) to get better and smaller files. With this plugin, you can also view SVG files in your media library (this is not possible, if you only allow the upload with a code snippet). And you can even decide the user roles that are allowed to upload SVG files.

What does SVG Support do?

The SVG Support plugin has almost the same features as Safe SVG, but it also adds some more options. One of them is “to inline” an SVG, which then allows you to modify the SVG using CSS. This is not possible, when the SVG is “loaded as an external image”. Such a styling can be useful if you want to change colors in an SVG in a “dark mode” for example.

Why do I use those plugins?

I use both plugins on one site each. On other sites, I only use the code snippet. It really comes down to your usage of SVG images in posts and pages. If you only want to use an SVG in the Customizer options for your site logo, the code snippet or Safe SVG might be all you need. If you want to use SVG images in your content, then the inline feature of SVG Support might be of use for you.

Conclusion

Both plugins have more than one million active installations, so we do see that people are using SVG files with their WordPress websites. It is about time to get SVG native support into WordPress Core and close this 13 years old Trac ticket I’ve linked above.

Do you use SVG files in your WordPress project? How to you use them? Only as static files bundled in themes and plugins? Or also in the content of posts and page? Then how do you allow the upload of them?

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.