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_INCOMPATIBLE to raise/suppress errors for incompatible changes.
• Use WPDI_ERROR_DEPRECATED to 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-loaded

Other 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: low

When 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: __invoke

Here 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 used

This 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\WpPostTypes has 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.