deckerweb Plugins · Knowledge & tools

A good plugin also knows what not to do

Thu, 12 Nov 2026 08:00:00 GMT

Adding more capabilities does not automatically make a plugin better. To me, good development also means deciding which tasks a tool should deliberately take on — and which it should leave to others. That creates room for mature features, a clear interface, and dependable maintenance.

I prefer mature features to a longer feature list

Useful features can be substantial. Some tasks need several settings, carefully designed workflows, and ways to handle different situations. I see little value in keeping a plugin small at all costs if that makes it less capable of doing its actual job.

What matters to me is whether a feature has been thought through. Can people understand it? Does it fit the rest of the plugin? Are its limitations clear? And can it still be maintained sensibly after the next update?

In my view, unfinished features are shipped far too often. Another option can look good in a release announcement. But the unanswered questions do not disappear. They eventually become problems for the people using the plugin — or for the developer who has to deal with the consequences.

The temptation comes from both sides

As a developer, you do not even need a user request to take on too much. One idea leads to another. Once the foundations are there, the next addition often looks like just one small step.

Then requests arrive from users. They usually reflect real tasks and deserve to be taken seriously. Even so, a worthwhile idea is not automatically a worthwhile addition to this particular plugin.

If every request is accepted, features can gradually accumulate that seem useful individually but no longer form a coherent tool together. The interface gets busier, the relationships become harder to understand, and every change has to account for more special cases. The cost of a feature is therefore more than the time needed for its initial implementation.

Understand the need before planning the feature

To me, a feature request is first a signal: someone wants to complete a task and has not found a suitable way to do it. The requested feature is one possible answer. It may not be the best one.

For example, someone might ask for another shortcut because a frequently used setting is difficult to find. Perhaps the plugin really does need that shortcut. But a clearer menu label or a better-placed link might be enough. A second interface for the same setting could simply hide the underlying problem.

The same applies when people evaluating a plugin cannot tell that a feature they need already exists. An informative screenshot, a clear description, or a useful example may help more than adding another feature.

Before implementing anything, it is worth asking a simple question: what are you trying to achieve, and where are you getting stuck? Sometimes the answer leads to a new feature. Sometimes it leads to a better interface. And sometimes it leads to better documentation.

What should this plugin deliberately not do?

I believe this question belongs at the beginning of product design. Should a plugin make an existing workflow easier, or create a workspace of its own? Should it display existing content, or manage content itself as well? Should it offer a few useful integrations, or try to support every conceivable system?

These are product and architectural decisions. They determine which settings will be needed, which dependencies will arise, and which responsibilities will require long-term maintenance. Nobody can make those decisions for you. A long wish list does not answer them, either.

With Toolbar Extras, I experienced what happens when an idea grows too far without sufficiently clear boundaries. I wanted too much and eventually could no longer deliver it as I had imagined. That has remained an important lesson for me.

A deliberate boundary does not mean that a need is unimportant. Perhaps it belongs in another tool, a documented extension, or a separate plugin. What matters is that the chosen solution remains understandable and can be maintained sensibly.

Explain boundaries through the benefits they bring

It is not enough to make these decisions privately. They should also be reflected in the documentation, on the product page, and in the plugin description. People choosing a tool should be able to understand what it is intended for.

I do not want to write a product page full of defensive statements. A concrete description of the purpose is more helpful: this plugin makes a particular workflow easier. It uses existing content to do so. Or it extends an existing system while leaving that system’s features where users already know to find them.

The benefits of leaving things out then become tangible: fewer duplicate settings, fewer unnecessary decisions, and a clearer route to the goal. Rather than promising everything, I can explain more precisely what value the plugin is meant to provide.

Important limitations must not disappear behind friendly wording, though. If a prerequisite is missing or a use case is unsupported, that needs to be stated clearly. A positive description and honest boundaries work well together.

Four questions before the next addition

I find these four questions useful when considering the next idea or user request. They do not make the decision for you, but they help you make it deliberately.

What specific need is behind the request, and can existing features already meet it?
Does the addition fit the plugin’s core purpose?
Would a clearer interface, better wording, or an example be more helpful?
Can I explain the feature clearly, finish it properly, and maintain it over the long term?

Thoughtful boundaries pay off over time

I want to develop mature features that help in everyday work. That takes ideas and openness to feedback. It also takes a willingness to solve a request differently, postpone it, or deliberately leave it out of this particular plugin.

Boundaries are not a decision against users. When chosen well, they help a tool remain clear, do its job dependably, and stay maintainable in the future.

To me, a plugin’s future is therefore shaped by more than what it can do today. What it deliberately leaves to others matters just as much.

A personal opinion piece by David Decker about product decisions and plugin development. The examples of user requests are illustrative, rather than accounts of specific support conversations.

Read on the website

Why I publish my plugins on GitHub today

Sat, 07 Nov 2026 15:58:21 GMT

I have been publishing my own WordPress plugins since 2011. For many years, the WordPress.org plugin directory was their home. That is where my plugins found their users. I learned a great deal, gained experience, and reached people who still appreciate my work today.

A different path

Even so, I have decided to publish my plugins through GitHub now. That decision grew over many years — and out of a question about how I want to work today.

WordPress.org made a lot possible for me

When I started, the official plugin directory was the obvious choice for me. People looking for a plugin could discover and install it directly in the WordPress admin. That visibility was enormously valuable to an independent developer.

A website of my own offering ZIP downloads was not a serious alternative for me in 2011. I was only just getting to know GitHub. I saw it primarily as a platform for collaborating on code, rather than a way to distribute finished WordPress plugins.

WordPress.org therefore made a lot possible for me. I have no wish to dismiss those years or erase them from my story.

Over time, the platform became less of a fit

Over the years, the platform felt increasingly restrictive for the way I worked. Requirements and rules grew. I had less freedom than I wanted when presenting my plugins, adding screenshots, or including links.

That included affiliate links. For plugins offered free of charge, that income could be one of the few financial rewards for a considerable amount of development and maintenance work.

I never felt entirely comfortable with the support forums, either. That was partly about the technical system and partly about the procedures. From earlier years, I remember being required to communicate in English even for plugins whose content and users were exclusively German-speaking. To me, that did not make sense.

By around 2018, my wish to find another way had become much clearer.

There is a personal side to reach

A successful plugin attracts attention. That includes questions, bug reports, expectations, and occasionally negative reviews.

This often affected me more than people could see from the outside. When hundreds or several thousand people were using a plugin, a single bug report could feel like a catastrophe to me.

Of course, users need to be able to report problems. Still, I eventually had to acknowledge how much stress that kind of public exposure caused me. I did not always find the atmosphere on the platform comfortable, either.

My business is smaller today. A smaller user base is something I genuinely welcome: less pressure, a calmer pace, and more room for focused work.

The final push

The final push for me personally was Matt Mullenweg’s conduct in the conflict with WP Engine. I found it deeply off-putting. For me, that tipped the balance toward acting on a decision that had been taking shape for a long time.

From the outside, my departure may therefore look primarily political. But the reasons go back much further. The platform had been becoming less suited to my needs for years.

I also no longer wanted to depend on decisions about plugin suspensions and consequences that I found difficult to predict. I increasingly experienced the guidelines as a rigid set of rules within which I no longer felt comfortable doing my work.

Changes to my plugin translations were another concern. On several occasions, I saw wording changed without an understanding of the architectural decisions behind it. I want to be able to review and take responsibility for such changes in the context of the whole plugin.

Why GitHub suits me better today

I find working on GitHub faster, more pleasant, and less restrictive. I can organize code, documentation, screenshots, and releases in a way that fits my projects.

GitHub is another company’s platform, with its own terms of service. It is not perfect, either. But it is a better fit for the current scale of my business, my plugin development, and my client work.

I understand the price of that choice: I give up the significant opportunity for discovery through the WordPress.org plugin installer. I accept that disadvantage deliberately.

With my own website, detailed documentation, the deckerweb Updater, and the deckerweb Library, I am now building a different way for people to discover and use my plugins.

A personal decision

There is something I want to make very clear: I had no personal conflict with the staff or volunteers at WordPress.org. I was treated kindly in my direct interactions with them. My decision is not directed against those people or their work.

I chose this path myself.

I would not rule out ever publishing another plugin on WordPress.org. For the foreseeable future, though, my reasons for distributing my projects elsewhere carry more weight.

I still enjoy developing for WordPress. I want to build useful tools, document them well, and be able to maintain them over the long term. To do that, I need a way of working that suits me as a person, too.

Right now, I find that on GitHub.

A personal opinion piece by David Decker, reflecting my own experiences, perceptions, and decisions.

Read on the website

Plugin or code snippet: which is the better fit?

Wed, 28 Oct 2026 20:16:29 GMT

A code snippet is not automatically leaner, safer or better than a plugin. Both have their place. What matters is what the code does, how it loads and who maintains it over time.

Why I ask this question

When I see video titles such as “Use code snippets instead of plugins to reduce your plugin count,” I am skeptical. There may be a useful idea behind the advice, but it is misleading as a general rule. Poor code can slow down a website or introduce security vulnerabilities, regardless of where it comes from.

When I wrote the original article in 2025, I had already been using small functionality plugins for more than 15 years. I have also used Code Snippets on many websites since 2012, and I enjoy working with it. This is not an argument against snippets. It is an explanation of why I value both approaches and choose according to the project.

What applies to both approaches

Code has to live somewhere and be loaded: in a plugin directory, a theme or child theme, a database, or a file generated by a snippet manager. Its location alone tells you little about its quality.
Code needs maintenance. Security issues and changes to WordPress or PHP may require updates.
Unsafe or faulty code can cause problems anywhere. Troubleshooting can be difficult in a snippet, a plugin or a functions.php file alike.
An advantage can also be a drawback: fixed conditions may protect one client project from accidental changes while limiting flexibility in another.

Plugins: strengths and potential drawbacks

What works well

Updates can be delivered through a suitable update channel and, where supported and enabled, installed automatically.
Translation files and WordPress language packs fit naturally into a plugin’s structure, supporting translatable interfaces and multilingual projects.
On Multisite, network activation can make shared management easier.
Suitable code can also be organized as a must-use plugin, which loads automatically and stays active.
Plugins can be managed from the command line using WP-CLI.
Execution conditions defined by the developer are not easily changed by clients, which can be desirable.
Multiple PHP files can be organized together.
Scripts, stylesheets and other files can be included as one coherent package.
WordPress provides basic error checks during plugin activation. These do not replace a complete review.
The WordPress.org directory has submission and review requirements. These provide a framework, not a guarantee of flawless or secure code.
Plugin source code normally lives in files rather than in the database. Depending on the attack scenario, that separation can be useful.
An identifiable author and a maintained project often provide a route for questions, feedback or support.

What to weigh up

Some plugins grow beyond their original purpose and accumulate unnecessary settings.
Advertising and intrusive upsells can clutter the WordPress admin.
Some plugins load assets where they are not needed, creating unnecessary overhead.
For some users, activating and deactivating a plugin feels less convenient than toggling a snippet.
Plugin count is easily mistaken for a performance problem. Many small, well-written plugins can work well together; each implementation needs to be assessed on its own.
Hard-coded conditions may require additional code to change, or may offer no practical way to change them.

Code snippets: strengths and potential drawbacks

What works well

Many users find activation, deactivation and condition management especially convenient.
Depending on the snippet manager, conditions can be configured through a visual interface.
Titles, descriptions, tags and other metadata help organize customizations.
Snippets are convenient for small, clearly defined tasks, such as a few lines or a few dozen lines of code.
A snippet manager can help site builders who do not have access to theme files or SFTP on a client website.
Snippets stored in the database can travel with a database backup.
A safe mode can help recovery after a problematic snippet, where the manager provides one.
In my experience, a snippet manager’s activation checks can be more helpful than WordPress’s basic checks. They still cannot detect every logic error.

What to weigh up

A copied snippet usually has no automatic update channel of its own, leaving you responsible for maintaining it.
Translations and WordPress language packs are less straightforward for a pasted snippet than for a plugin structured to support them.
Multisite support depends on the manager. I particularly value the network-wide snippets in Code Snippets, which I have been able to use in its free edition.
The manager must load before it executes its snippets. For hooks that need to run early, a plugin or must-use plugin may be a better fit.
Poor naming and missing prefixes can cause conflicts with other code.
Shared snippets sometimes omit permission checks, input validation or safe output handling, which can create security vulnerabilities.
An easy-to-use interface for pasting code does not make the snippet a no-code solution.
Anyone who copies and activates code takes responsibility for its effects, even if they do not fully understand it.
Without a clear source or an accessible author, there is often no useful route for support or feedback.

A quick guide for everyday decisions

These examples are starting points, not fixed rules. This guide is an addition to the original 2025 article. The implementation and responsibility for future maintenance still determine the right choice.

Often a good fit for a snippet

A small customization for one website: you want to use an existing filter to change a label, for example. A focused snippet can be a good fit.
A focused extension to an existing plugin: you use a documented hook and understand its requirements. A snippet keeps the customization separate from the plugin’s own code.
A few project-specific customizations that you maintain yourself: you already use a snippet manager and want to name, organize and selectively enable or disable each change there.

Often a good fit for a plugin

A coherent feature with multiple files: PHP, stylesheets, scripts and perhaps translations need to be maintained as one package. A plugin is often easier to organize for this purpose.
The same tool on several client websites: you want a clear version and an established update process. A maintained plugin with a suitable update channel is often a better foundation.
A feature that must load early: the required hook runs before the snippet manager loads the code. An appropriately loaded plugin or must-use plugin may then be necessary; the actual loading order determines the choice.

My answer: choose for the task

I would not reject a plugin simply because it adds another entry to the plugin list, or favor a snippet simply because it is short. A small customization in a well-managed snippet manager can be exactly right. A plugin may be a better fit for related features, multiple files and an established update process.

What matters is an informed choice for the project: what functionality do I need, who maintains the code, and what options do I have if something goes wrong? Plugins and snippets are tools, not competing belief systems.

This opinion piece is based on my English GitHub wiki article from 2025. I have edited its language and structure for the website and added a German edition. It reflects my experience, rather than a comprehensive test of current snippet managers. Capabilities and safeguards depend on the particular tool and version.

My original GitHub wiki article (2025, English)

Read on the website

When a parent plugin is missing: pause features, keep working

Tue, 27 Oct 2026 11:58:37 GMT

An add-on often needs another plugin or a particular theme. I want a missing prerequisite to avoid unnecessarily blocking setup or maintenance: clear notices, retained settings and a sensible paused state instead of a dead end.

What a parent plugin means

An add-on extends an existing tool. Bricks QuickNav, for example, needs a supported Bricks builder for its navigation; Genesis Widgetized Footer needs an active Genesis theme for its footer features. GP Project Export Name works with GlotPress.

If that foundation is missing or temporarily inactive, some features cannot usefully run. This is different from a failed save and is not a reason to force you onto another admin screen.

Allow installation, pause dependent features

My principle is that, with the technical minimum requirements met, such an add-on should generally remain installable and activatable even if its functional foundation is not ready yet. Features that depend on that foundation pause, and a clear notice explains what is missing.

Existing settings should be retained. Where it is sensibly implemented, the settings page also stays accessible so you can understand the situation or prepare the setup. Not every setting needs to be locked; what matters is keeping unavailable features inactive.

The checked examples below already show this behavior. This does not mean every older plugin or every feature has reached the same state; the guide for the particular version describes its actual scope.

Setup should not depend on the perfect order

You might install my add-on first and the required main plugin ten minutes later. You might prepare a website before activating the appropriate theme. The add-on should explain what is still missing instead of turning that order into an obstacle.

Once the supported prerequisite is detected again, the related features can become available again. A missing-dependency notice does not replace setting up the main plugin or theme itself.

When support or troubleshooting needs a temporary pause

During a support request, a vendor may recommend temporarily deactivating their plugin. This can also be useful when troubleshooting. My add-on should not make that work harder through its own activation lock, a forced redirect or the loss of its settings.

Dependent features are unavailable during that time. After reactivating the prerequisite, check that the notices have cleared and the features you need work again. A theme change or a paused main plugin can still affect the website in its own right; the add-on’s paused state does not remove those effects.

Three existing examples

These examples refer to the published versions documented here. What matters is which feature is missing its prerequisite, not merely whether the add-on is listed as active.

bricks-quicknav · v2.0.2: Without an active supported builder, settings remain accessible while toolbar navigation waits for its prerequisite. A notice explains the state.
genesis-widgetized-footer · v2.0.2: Without active Genesis, footer features pause. The notice on the settings page explains that saved widgets and settings are preserved.
gp-project-export-name · v2.0.0: Export features pause if GlotPress is not ready. Settings and the quick guide remain accessible; a permalink structure other than Plain is also required.

Technical minimum requirements still apply

A missing functional foundation is not the same as an outdated WordPress or PHP version. The plugin’s minimum requirements still apply, as do permissions and explicitly documented exceptions.

In future updates, I want to add or improve this calm approach to prerequisites wherever it makes sense. The aim is not to ignore dependencies, but to explain their state and keep a way forward open.

A natural fit: how my plugins work with WordPress

Tue, 27 Oct 2026 11:58:37 GMT

A useful plugin does not need to invent a new interface for every task. Many of my current plugins already use the tools built into WordPress where they make everyday work easier.

WordPress as a home, not just a platform

I want my plugins to feel at home in WordPress. That includes clear settings, appropriate permissions and understandable notices. The Command Palette and Site Health are two useful examples: they already provide familiar places for shortcuts and technical information.

Less is often more. An additional entry should help with a frequent task or answer a specific question. A competing second Command Palette or a diagnostic section full of irrelevant values would not be an improvement.

Site Health: information and tests are different

Under Tools → Site Health, the Info tab sits alongside the status tests. Many of my plugins add concise information there, such as component versions, the detected environment or effective settings. This can help with a support request without making you search through several settings screens.

An information section is not a separate health test or a security rating. Brand Admin Schemes, for example, reports scheme selection, palette source and environment without running additional tests or external requests. Site Essentials describes maintenance status and effective or currently inapplicable rules, among other details.

Some plugins also add tests tailored to their purpose. TabulaMea, for example, checks aspects of its storage structure, tables and scheduled tasks. The meaning of a result depends on the plugin; information should not be presented as a warning without a useful reason.

Command Palette: shorter routes to useful tasks

Where WordPress provides its native Command Palette, selected plugin commands can make frequent tasks quicker to reach. Which commands you see depends on the WordPress version, the current screen, your permissions and the plugin’s state.

Advanced Scripts QuickNav, for example, provides access to script management, new scripts, search and personal favorites. Site Essentials adds four navigation commands for settings, reports, website checks and maintenance. Türchenzeit offers a focused shortcut for creating a new calendar door.

These commands replace neither permission checks nor the normal plugin menus. If the native palette is unavailable on a screen, the regular routes remain the appropriate way in. A menu entry made searchable by WordPress itself is also not necessarily an extra command registered by the plugin.

Examples you can explore

These examples refer to the published versions documented here. Not every plugin includes both integrations; its own guide describes the scope and requirements.

brand-admin-schemes · v1.1.1: A concise Site Health information section without additional status tests.
advanced-scripts-quicknav · v1.3.2: Diagnostic information and native commands for working with Advanced Scripts.
site-essentials · v1.1.1: Configuration information about maintenance and effective rules, plus focused navigation commands for settings, reports, the dashboard and active avatar features.
tabulamea · v0.9.1: Analytics-related health tests, diagnostic information and permission-aware shortcuts.
tuerchenzeit · v1.0.1: Diagnostic information and a native command for creating a new calendar door.

Useful for support — share deliberately

When reporting a problem, the plugin version, detected prerequisites and a relevant diagnostic excerpt can make it easier to understand. Read the excerpt before sharing it and include only what is needed for your specific question.

Site Health is first of all a local view in the WordPress admin. Information displayed there does not by itself mean it is automatically sent to me. Each plugin’s documentation explains whether it uses external connections for other purposes.

Step by step, with a reason

Plugins without a suitable integration are intended to receive one in future updates where it offers a useful benefit. This is a development principle, not a promise for a particular version or a commitment to give every plugin identical entries.

The practical task remains my measure: which information helps answer a support question? Which command genuinely saves a detour? An entry that does not answer those questions usefully does not need to fill either WordPress tool.