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. Foundations Module
  2. Actions

Integration action traits

PreviousExtension action traitsNextStates

Last updated 4 years ago

Was this helpful?

As opposed to and , integration action traits apply only to initializable and setupable objects. They are normally used for piping other actions at the end of the current one, if the current action is completed successfully.

They are similar to the extension action traits but have a few notable differences:

  • Their methods are always prefixed with integrate_.

  • The methods are called after the extension traits.

  • The methods can return a different exception type so, in case of failure, the result may be wrapped in an exception of the proper type.

  • The integration traits inherit different corresponding traits.

Let's use as an example the default InitializableTrait that you can find . If you check the initialize method, all the points above should be obvious by looking at the second elseif statement.

A good example of an integration trait is the which automagically calls the setup method of an object that initialized successfully and is also setupable.

The Foundations module comes with a few pre-built piping actions. Make sure to check them out on GitHub for the initializable objects and for the setupable objects .

local action traits
extension action traits
here
SetupOnInitializationTrait
here
here