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

Main Plugin Instance

PreviousPluginNextPlugin Components

Last updated 4 years ago

Was this helpful?

Your plugin should have exactly one class that implements the interface. If you have a very simple plugin, it can be the only class you have, but you need to have it. For convenience, the trait provides a basic implementation for most methods.

Basically what this interface enforces is a way to retrieve the most useful information from the plugin's . The class even goes a step further and actually retrieves all the values from said comment during the .

Therefore it would be enough to have a file Plugin.php that looks a bit like this:

<?php

namespace DeepWebSolutions\Plugins\MyTestPlugin;

use DeepWebSolutions\Framework\Foundations\Plugin\AbstractPlugin;

\defined( 'ABSPATH' ) || exit;

class MyPlugin extends AbstractPlugin {
    public function get_plugin_file_path(): string {
        return $path_to_file_with_plugin_header_comment;
    }
}

$plugin = new MyPlugin();
$plugin->initialize();

echo $plugin->get_plugin_version(); // echoes whatever the version header line is set to

As always, our provides a more complex example (albeit it relies on the extended classes provided by the ).

PluginInterface
PluginTrait
header comment
AbstractPlugin
local initialization action
example plugin
Core Module