How OnePress lets you release features to all your brand sites (build once; deploy everywhere)

In OnePress, we treat features like internal products, built once, reused many times, and customized where needed. Whether deployed to the entire network of brands or selectively to a few, our approach ensures that every feature has the scale, flexibility, and governance needed for enterprise-grade delivery.

First up: What does OnePress consider as features?

In OnePress, “feature” is an implementation-agnostic unit of capability. It can be packaged in different forms depending on how it’s best consumed across your network. It can be a plugin but not necessarily so.

Features can be many things:

• Plugins: modular and self-contained, ideal for portability and selective activation
• Theme components: shared templates, blocks, or styling elements
• Code modules or libraries: reusable PHP classes, REST endpoints, Gutenberg blocks, etc., loaded via Composer or autoloaded
• Configuration files: SEO schema, analytics setup, robots.txt policies
• API-driven services: headless features exposed via GraphQL/REST

As you can now understand, our OnePress feature model supports multiple forms of delivery, not just plugins. That said, plugins are a common and recommended unit of modularity, especially when you want optionality and governance.

How OnePress enables feature lifecycle

With OnePress, features are treated like software. That means:

• Central version control: All shared features typically live in a central repo, with versioning and branching
• CI/CD pipelines: Features are tested, validated, and deployed automatically
• Feature registries: Teams can see what’s available and opt in

Think of it as feature-as-a-service, running on a platform that lets you deliver consistency, speed, and governance at once.

How OnePress approaches to feature sharing

OnePress supports multiple models for feature sharing, depending on how your organization balances central control with local autonomy. At a strategic level, these fall into three categories:

1. Global features (network-wide)

These are features built centrally and deployed uniformly across the network. These are often critical capabilities that must behave consistently everywhere. Every brand benefits from its functionality (for e.g. GDPR compliance features).

Key characteristics:

• Centrally managed codebase
• Feature flags or configuration files handle minor local differences
• Updates are pushed to all sites simultaneously

2. Selective features (activated by brand or region)

Here, features are available across the network but only activated or configured where relevant. OnePress implements this through a system of modular features, often toggled by configuration files or environment settings. These are handy when some brands or markets require specific functionality, but others don’t.

Key characteristics:

• One shared feature codebase
• Activation logic scoped to individual sites or segments
• Minimal duplication, maximum reuse

3. Brand-specific features (custom, but portable)

These are features scoped initially to one brand, but written for potential reuse (like internal open-source). They’re coded with portability in mind. Rather than siloing these features, OnePress builds them as modular, versioned plugins, designed to be reused, if and when needed.

Key characteristics:

• Developed with a “shared-first” mindset
• Extensively use hooks, filters, and config files
• Can be easily adapted and deployed elsewhere later

Governance, built-in

Feature sharing only works when local teams trust the system. That’s why OnePress includes guardrails to allow controlled divergence:

• Feature toggles are scoped per brand
• Environment-aware configurations (staging vs. production)
• Local override support where permitted
• Governance policies to prevent bloat and ensure alignment
• Audit trails to track feature usage, update history, etc.

This empowers local editors, developers, and marketers, without compromising performance or maintainability.

Example: Feature sharing in action with OnePress

A client we support runs a six-brand WordPress network, each brand independent, but unified through OnePress.

When one brand needed a custom design, the team didn’t fork themes or duplicate code. Instead, they used their lightweight OnePress setup to build the module as a self-contained feature (modular, namespaced, and registered in the central feature registry).

It was activated for just one brand. No clutter across the network. No risk of cross-brand conflicts. Just a clean toggle via OnePress’s scoped feature control.

That’s the power of feature sharing with OnePress: build once, deploy precisely, and scale without chaos.

Conclusion

OnePress changes how digital capabilities are built and distributed across your multisite multi-brand WordPress network. By treating features as modular, testable, and versioned units (delivered as plugins, code, or config) we help you move faster all without compromising consistency or control.

With OnePress, your feature stack becomes a strategic asset, enabling central consistency with brand agility. You can capture and scale innovation across your entire network. Build just once and deploy with precision (globally or locally), eliminating plugin chaos and dev duplication.

This approach also enables product thinking across your editorial, marketing, and engineering teams.