Releases: rmp-up/wp-di
More performance, extensible and centralized DI-Continer
WordPress Dependency Injection now offers a Factory for some Provider and (more important) a centralized container that can be reused among all plugins/themes:
<?php
\RmpUp\WpDi\WpDi::load( require 'services.php' );
$container = \RmpUp\WpDi\WpDi::pimple();Reusing an already existing container and the existing provider (by using the ::load()-Method) greatly enhances the performance.
Other changes:
- Features
- Preload core files using "preload.php" (esp. for the PHP 7.4 feature) to increase performance.
- Loader: The static WpDi::loader() helps to fasten up loading
- Introduced a factory for easier provider creation
- Bugfixes
- An argument-string can now have a leading "@" char without the service needed to exist.
- Backward incompatibility / deprecations
- Get rid of ServiceProviderInterface to switch to a more tree-like provider/parser.
- Drop Provider::register methods to no decouple PSR11 and pimple for more flexibility.
- Template references now must have a percentage sign "%" as pre- and suffix
- Removed all sanitizer which need some rework towards a layer that can be cached.
- Replaced LazyService with LazyPimple to decouple from PSR11 for more flexibility.
- Dropped various internal deprecated structures.
- Quality assuarance
- Performance profiling using xhprof
- Fixed some IDE warnings like typo and inspections.
Forward compatible release / Deprecation warnings
We are about to release a new major which has some breaking changes in the API interface.
Some of them have workarounds to support forward compatibility while other changes raise a E_USER_DEPRECATED warning to help you figure out what will change and how to migrate.
What is forward compatible? Slight changes in the signature of a method (e.g. injecting a string instead of an integer) is an easy to do task, which can be solved in the "old" version already.
What is forward incompatible? Heavy changes in the interface (e.g. removal of a method or class) is a bigger change for which you need the new version and refactor things.
You can use the following environment variables to suppress or raise those warnings:
- Use
WPDI_ERROR_FORWARD_INCOMPATIBLEto raise/suppress errors for incompatible changes. - Use
WPDI_ERROR_DEPRECATEDto raise/suppress errors for forward compatible changes.
I18N, Factory and Performance
We enhanced the performance by offering a preload.php which can be used for pre-loading the mostly used classes which bypasses the use of slow auto-loader.
Also you can now use factories to dynamically create services:
services:
MyFactory: ~
SomeThingElse:
factory: "@MyFactory"The best thing is about translatable YAML content, so that labels and titles are now in the target language:
services:
SomeThing:
arguments:
- !__ [ "Wer ist Adam?", dark ]
# Same as `__('Wer ist Adam?', 'dark')` but lazy-loadedOther changes:
- CI: Adapt testing to Composer2
- QA
- Improved Quality Assurance by using phpStan 0.12
- Check against the latest WordPress Version / WP 5.6 ready
Register CLI-Commands in CLI only
Registering CLI-Commands makes no sense when the user views the website via browser. Therefore we skip adding CLI-Command for such cases.
Other changes:
- Fixed testing against WordPress:dev-master
Meta-Boxes and Shortcodes
Meta-Boxes
Services can now be used for Meta-Boxes:
services:
MyBox:
meta_box:
rlcs:
title: Recent matches
screen: post
context: side
priority: lowWhen rendering the meta-box the service will be invoked.
Shortcodes
Services can also be used as shortcodes:
services:
MyOwnShortcode:
shortcode:
i_am_the_danger: deprecatedUsage
is_that_you: __invokeHere we see two shortcodes and how they are mapped to specific methods.
Other changes
- cli: Redirecting to other methods
- cli: Allow adding deep nodes
- qa: PHPStan uses original WP functions
PHP 7.0 Compatibility and YAML expressions
composer install rmp-up/wp-di
It is old but gold - it seems. PHP 7.0 is still present on many servers so we allowed wp-di to be compatible with this ancient thing. Also ...
Non-existent parameter fallback to options
parameters:
foo: bar
services:
SomeThing:
arguments:
- '%foo%'
- '%blog_public%'The parameter "blog_public" has not been introduced as parameter. But still wp-di tries to look up the option an inject this one instead. So every option can be seen as a "predefined parameter" now.
YAML expressions for constants and more
Using the YAML helper RmpUp\WpDi\Yaml allows to concat and inject PHP constants:
services:
SomeThingElse:
arguments:
- !php/const ABSPATH
- !join [ !php/const ABSPATH, "wp-content/uploads" ]Other changes
- Template names are now like parameter too so please surround them with a percentage sign
0.7.0 - Hello YAML-friends!
composer require rmp-up/wp-di:0.7
The goal of wp-di 0.7 was to refine the service definition with more keywords
to allow the use of YAML-Service-Configs for WordPress as known from other frameworks:
options:
my_plugin_option: 'This is the default until changed.'
service:
MyLittleClassIsServiceNow: # class name as service name
arguments: [ '%my_plugin_option%' ]
post_type: 'cpt_'
add_action:
personal_options_update: ~ # action to class-method mapping
edit_user_profile_update: ~ # this means "::__invoke"
user_edit_form_tag: editFormTag # so this goes to "::editFormTag"
or_this_way: # service name
class: SoBeautiful
wp_cli:
hello neighbour: ~ # means SoBeautiful::__invoke is usedThis release contains mostly the big features brought during the 0.6.x version ...
- Even more lightweight Widgets (thanks to lazy arguments, optional)
- Improved WP-CLI support for doc-comments
- Smaller overhead thanks to refactoring towards service-definition caching
... but we dropped some backward-compatibility so that we can go on with the next topic:
Customization of the service-definition for your own needs
Yes, extending this thing - we're getting there!
What did we change in 0.7 to get there?
- Arguments must be placed in their own "arguments" section now
(before you could just enumerate them) - Defining PostTypes is no longer in it's own section
and moved into the service definition which may be easier to use. - Using Options or Parameters now needs the
%param_name%format
with percentage sign (was without before),
which makes it more fail-safe to use parameters. - Class
Provider\WpPostTypeshas been removed - Class
Provider\Actions(and sanitizer) removed - Moving away from PSR-11 because this is wired to Pimple already
(due to the Provider logic) but may come back there in v1.0 or later. - And some minor technical internals (see commits to know more).
Have a look at the documentation to know more.
YAML, Widgets and Lazy Arguments
- Feel free to use YAML for describing services, the syntax has been extended for this.
- Every service can now be registered as a Widget
- Mark arguments as very lazy to solve bottlenecks
About Lazy arguments
No matter if a Widget is used or not, WordPress will load all of them, every time, every class with every dependency.
This totally costs to much time and memory for each request so we needed a solution for that:
services:
SomeRepository: ~
MyWidget:
lazy_arguments: true
widgets: ~
arguments:
- '@SomeRepository'The lazy_arguments flag does it. On the one hand WordPress will still load the Widget. But on the other it won't be able to load the injected services (here: SomeRepository) until they are really used.
Read more about the new YAML structure and other topics in the documentation.
Inject into CLI services
New WP-CLI commands can be introduced using the CliCommand::class. Unfortunately it was almost impossible to inject services or parameter from the container. With this patch we implemented and documented an easier way to inject services into CLI-Commands.
- CLI-Command-Services are no longer lazy as wp-cli needs the direct object/class for its features (e.g. help text)
- CLI-Command-Services are only available when working on the shell (to spare costs of web calls)
Bugfix: WP not as general dependency
composer.json had WordPress as dependency which lead to obsolete data in some projects.
Putting this as a dev-requirement will bypass this in most cases.