In this article we mainly tell you some
Plug-in, also known as Plug-in, refers to a specific type of functional module (usually composed of Implemented by third-party developers), its characteristics are: activate it when you need it, disable/delete it when you don’t need it; and whether it is activated or disabled, it does not affect the operation of the core module of the system, which means that the plug-in is A non-intrusive modular design achieves loose coupling of core programs and plug-in programs. A typical example is the numerous third-party plug-ins in WordPress, such as the Akimet plug-in, which is used to filter spam on user comments.
A robust PHP plug-in mechanism, I think, must have the following features:
Dynamic monitoring and loading of plug-ins (Lookup)
Dynamic triggering of plug-ins
The implementation of the PHP plug-in mechanism in the above two points does not affect the operation of the core program
To implement plug-ins in the program, the first thing we should think of is to define different hooks (Hooks); "Hook" is a very vivid image The logical concept is that you can think of it as a plug-in trigger condition reserved by the system. Its logic principle is as follows: when the system executes a certain hook, it will determine whether the conditions of the hook are met; if it is met, it will first call the function specified by the hook, and then return to continue executing the rest of the program; if it is not met, it will first call the function specified by the hook. , just skip it. This is a bit like "interrupt protection" logic in assembly.
Some hooks may have been designed by the system in advance, such as the hook I mentioned earlier about comment spam filtering. Usually it has been designed by the core system developers into the comment processing logic; another category Hooks may be customized by users (developed by third-party developers) and usually exist in the presentation layer, such as an ordinary PHP form display page.
Maybe you find the above words boring and drowsy; but to understand the code I wrote below, it is essential to understand the principles of the above PHP plug-in mechanism.
The following is the core implementation of the plug-in mechanism in PHP. The core of the entire mechanism is divided into three major blocks:
A plug-in manager class: This is the core of the core. It is an application global Global object. It has three main responsibilities:
is responsible for monitoring all registered plug-ins and instantiating these plug-in objects.
is responsible for registering all plugins.
When the hook condition is met, the corresponding object method is triggered.
Plug-in function implementation: This is mostly done by third-party developers, but certain rules need to be followed. This rule is stipulated by the plug-in mechanism and varies depending on the plug-in mechanism. You will see the following display code See this rule.
Plug-in triggering: That is, the triggering condition of the hook. Specifically, this is a small piece of code that is placed where you need the plug-in implementation to trigger this hook.
I talked a lot about the principles of PHP plug-in mechanism. Let’s take a look at my implementation plan:
Plugin Manager PluginManager class:
The following is PHP Content cited by the plug-in mechanism:
Add the above code The core of the entire plug-in mechanism is completed with no more than 100 lines of comments. It should be noted again that you must set it as a global class and load it first wherever the plug-in is needed. The places commented with # are the parts you need to complete yourself, including the acquisition and logging of the PHP plug-in mechanism, etc.