This is a (partial) example to demonstrate the interaction between different reusable components to build an admin page in the WordPress back-end that shows a near-real-time display of the last 30 lines of my log files.
This code will not work as is, as some of it depends on a larger architecture system. Some of the files have been shortened, and the usual file headers and copyright notices have been removed for brevity's sake.
The related components that are discussed are brightnucleus/dependencies and brightnucleus/settings. The configuration is loaded through brightnucleus/config.
Notable "features" of the below code:
- Project-specific logic is in Config files, making this reusable across several sites or projects. In fact, this is used across several sites by providing site-specific Config files that override the defaults.
- Logic is only coupled to a log file reader interface. The concrete implementation can be easily replaced by re-mapping the interface in the Dependency Injector to a different class (which might even be outside of this particular plugin).
- All logic is contained within the Config file, even for the JS-specific stuff. The JavaScript file gets all the necessary information through a JavaScript object that is created through PHP. So, chances are good that this JavaScript file can be minimized and shipped and will probably not need a lot of changes later down the road.
- All general boilerplate code is in external components. Unit tests are written once, and are valid and usable across all sites that make use of them. Each new project will start with more than half its code already being unit-tested from the start.
- Changes to the underlying infrastructure (like when WordPress changes its Settings API), are contained within these external packages, and each relying project will probably only need a
composer update
once the changes are live.