DWS WP Framework
  • Welcome
  • Primary goals
    • Modular design
    • No 3rd-party dependencies
  • Key concepts and dev tools
    • PHP and WP requirements
    • Object-Oriented Programming
    • Semantic Versioning
    • Version Control (git / GitHub)
    • Dependency Management (Composer)
    • Automated Testing (Codeception + Github Actions)
    • Dependency Injection (PHP-DI)
    • Coding Standards (PHPCS and PHPMD)
    • Dependencies Scoping (PHP-Scoper)
    • TypeScript and Sass
    • Task Runners (Grunt)
  • Setting up your dev environment
    • Windows
  • Your first plugin
    • Multiple plugins using the framework on the same site
  • Frequently Asked Questions
  • Bootstrapper Module
    • Motivation
    • How it works
    • How to use
    • White Labeling
  • Helpers Module
    • Motivation
    • How to use
  • Foundations Module
    • Motivation and How to use
    • Actions
      • Local action traits
      • Extension action traits
      • Integration action traits
    • States
    • Utilities
      • Stores
      • Handlers and Services
        • Logging Service
  • Plugin
    • Main Plugin Instance
    • Plugin Components
  • Hierarchies
  • Helpers
  • Utilities Module
    • Motivation and How to use
    • Hooks Service
      • Scoped Handler
    • Shortcodes Service
    • Templating Service
    • Assets Service
      • Scripts Handler
      • Styles Handler
    • CRON Events Service
      • Action Scheduler Handler
    • Admin Notices Service
    • Dependencies Service
    • Validation Service
  • Core Module
    • Motivation and How to use
    • Plugin Tree
      • Plugin Root
      • Plugin Functionality
    • Plugin Components
      • Internationalization
      • Installation / Upgrade / Uninstallation
  • Settings Module
    • Motivation and How to use
    • Settings Service
      • WordPress Handler
      • MetaBox Handler
      • ACF Handler
    • Validated Settings
  • WooCommerce Module
    • Motivation and How to use
    • Extended WC Logger
    • WC Settings Handler
Powered by GitBook
On this page

Was this helpful?

  1. Plugin

Plugin Components

PreviousMain Plugin InstanceNextHierarchies

Last updated 4 years ago

Was this helpful?

While the main plugin instance class of your project should implement the PluginInterface interface, the other classes should implement the interface. Obvious exceptions are classes designed to be -- and anything else that you think shouldn't (we don't know your project!).

Plugin components are simple though. They simple posses an ID, a name, and a means to get the main plugin instance. For example, our has a class for each unlock strategy and each of those classes is a plugin component. The name of the user profile unlock strategy is simply User Meta Unlock Strategy and its ID is an autogenerated hash.

The ID of a plugin component can be anything that identifies it uniquely, whereas the name is designed to be spelled out in plain English for human understanding.

As a rule of thumb, plugin components are singletons. This is not enforced, but be sure to know what you're doing if you instantiate the same component multiple times.

As you probably expected by now, there is a trait offered that provides a basic implementation of the interface methods. Moreover, the class also provides sensible defaults and magic use of your getters and setters.

PluginComponentInterface
utilities
Locked Payment Methods plugin
PluginComponentTrait
AbstractPluginComponent