How CMS plugins, modules and extensions work

Almost every publishing CMS can be extended. Plugins add a newsletter sign-up, a paywall, a redirect manager or a custom article type without changing the core code. They also add risk, because a plugin runs inside your system with much of the same access the core has. This guide explains how extension systems are built, so you can judge what you are installing. For how to vet a specific plugin, see our thread on choosing plugins.

What is a plugin, and what do the names mean?

A plugin is a package of code that the CMS loads at startup or on demand. It might add an admin screen, a new field type, a widget on the public site or a connection to another service.

The terms vary by product. WordPress and Strapi say plugins. Drupal says modules. Other systems say extensions or add-ons. The architecture is similar enough that this guide treats them together.

How do plugins plug in? Hooks and events

Most traditional CMSs extend through hooks: named points in the core code where other code may take part. WordPress developer documentation describes hooks as a way for one piece of code to interact with or modify another piece of code at specific, pre-defined spots, and as the foundation that lets plugins and themes work with WordPress Core.

WordPress splits hooks into two kinds. An action takes the information it receives, does something with it and returns nothing. A filter takes the information, modifies it and returns it. In practice, an action might send a notification when an article is published, while a filter might alter the headline before it is displayed.

Drupal uses the same concept with different framing. Its documentation says hooks are one of the ways modules interact with contributed modules or core subsystems, and that a hook can be thought of as an event listener in the sense that an event triggers an action. The same documentation says that in Drupal 11.1 and later hooks are implemented by defining a class in the module’s Hook namespace and tagging the method with the Hook attribute, whereas Drupal 11.0 and earlier used function-based implementations named like mymodule_hookname().

That last point matters for publishers. The way extensions are written can change between major versions, so an add-on that works today may need rewriting by its maintainer when you upgrade the core. Read the project’s upgrade notes before you commit to a major version.

Plugins can also expose hooks of their own. WordPress documentation says developers can create their own hooks so that other developers can extend and modify their plugin or theme. The result is a layered system where add-ons depend on other add-ons.

How do API-based extensions differ?

Headless and API-first systems often extend through defined interfaces rather than hooks scattered through the code. Strapi documentation says plugins can use an Admin Panel API to interact with the admin panel and a Server API to interact with the backend server. It also says plugins can work exactly like the built-in plugins or third-party plugins from its Marketplace.

The difference for a publisher is where the extension sits. A hook-based plugin changes behaviour inside the CMS. An API-based extension may sit beside the system and talk to it through requests. The second pattern limits how deeply an add-on can reach, but only if the interface itself is limited. Check what the API permits before assuming that.

What can a plugin touch?

In most systems a plugin runs with the same privileges as the core application. That has three practical consequences.

1. It can read what the CMS can read. Content, user records and settings are normally reachable from plugin code.
2. It can write what the CMS can write. A faulty plugin can corrupt content or settings.
3. It runs on every request it hooks into. A slow plugin slows the page.

Some platforms may restrict add-ons more tightly than this, but you should not assume it. Ask the vendor how extensions are isolated, whether they declare permissions, and whether the answer is in the documentation. If it is not, treat every plugin as having full access.

How does plugin security work?

Responsibility is split. The core team secures the core and documents safe practice. The plugin author has to follow it. WordPress developer documentation, for example, says to always validate and sanitize user input before using it and to escape on output, and lists the principles never trust user input and escape as late as possible. Whether a given plugin follows those rules is something you cannot see from the admin screen.

Your defences are process, not trust:

• Install from a source that publishes version history and a way to report problems.
• Prefer plugins whose maintainers respond to issues.
• Remove anything inactive. Unused code is still code.
• Limit who can install or activate plugins to a small number of administrators.
• Keep a record of what is installed and why.

Some projects run formal security processes. Drupal’s security advisory policy, for example, says advisories cover stable releases in supported major version branches and are not issued for development releases, alphas, betas or release candidates. In other words, a module that is only in a development release sits outside that safety net. Check what your CMS’s project does and does not cover.

What are the update risks?

Updating is the main way plugin risk shows up. Updates fix security problems, but they also change behaviour. Three risks are worth planning for:

• Plugin and core diverge. A core upgrade can leave an add-on behind, as the Drupal hook change above shows.
• Two add-ons conflict. Both hook the same point and change each other’s output.
• An update changes a feature you rely on. Settings reset, output changes, or a paid tier appears.

A simple routine reduces the pain. Keep a staging copy of the site. Apply updates there first. Test the five things your newsroom does every day: write, preview, publish, upload an image, correct an article. Only then update the live site, with a backup taken just before. Our installation guide covers environments and backups.

How should a publisher decide what to install?

Ask these questions in order:

1. Does the core system already do this? Built-in features have the same maintenance as the core.
2. Is the plugin maintained, and when was the last release?
3. What licence and what cost does it carry? Our licensing guide explains the common terms.
4. What happens to your content if you remove it?
5. Does it affect page speed for readers? See news site design patterns.

The same logic applies to themes, which are the other major extension point. Read how themes work for that side.

What should you take from this?

Plugins are what make a general-purpose CMS fit a particular newsroom, and they are also where much of the ongoing work lies. Understand the extension model of the system you choose, check how its project handles security and upgrades, and keep your add-on list short. For the broader context, start with What is a CMS?.