Modular design
Last updated
Was this helpful?
Last updated
Was this helpful?
The DWS WP Framework has a modular design and thus consists of multiple so-called modules. Currently, there's 7 different modules that more-or-less build on top of each other. In relative order, they are:
-- validates that appropriate versions of PHP and WordPress are running or displays a user-friendly error if not.
-- a collection of small, helpful, static snippets that can be reused across various projects.
-- a collection of abstractions useful for building semantically-rich plugins; technically, simple plugins can already be built at this level.
-- a collection of services for working with template files, value validation, admin notices, dependencies, hooks etc.
-- an opinionated collection of abstractions for building plugins; relies on the abstractions defined by the Foundations Module and some services from the Utilities Module but its usage is optional.
-- provides a unified way for interacting with various settings APIs like , , and itself.
-- a bridge between the DWS Framework and the WooCommerce API.
The reasoning is simple. If you're building a plugin that's meant to be an extension for , then you probably want to include the WooCommerce module. If not, why would you want that code in your plugin? Similarly, you might want a very simple plugin that doesn't require any settings, so no settings module either. And so on...