@tsteur Not sure if updating the lib might cause problems while updating. The method DI\object has been removed, which is in use by some plugin configs. So it may cause fatals unless the plugin is updated together with core.

Also did not yet find a easy way to solve this:

there are some issues with having references in functions defined in configuration like here

matomo/config/environment/test.php

Line 101 in 0187b71

array('AssetManager.getStylesheetFiles', function (&$stylesheets) {

Might be required to change all event definitions to not use references if there is no other solution.... Will have a closer look at that...

@sgiehl is there any way that we define \Di\object ourselves maybe so it won't break? I just had a look it be mostly only PaidAds and SearchEngine plugin if I'm seeing this right? The other ones be mostly cloud related plugins or core plugins.

guess we could try using autowire as alias, might work in the most cases...

Wrapping the observer functions into \DI\value() seems to fix the problem. Not sure if that has any disadvantages 🤷
At least the tests seem to pass again.

I've also added a proxy for \DI\object() to \DI\autowire(), which should circumvent any possible failures due to plugins still using \DI\object()

Should be ready for a first review...

@sgiehl can you adjust the docs in https://developer.matomo.org/guides/dependency-injection ? It's showing DI\object a few times and it be great to describe when to use autowire and when create. Not sure if it's also mentioned in other places (likely not).

The docs mention also DI\link which seems now removed? Need to update this in our docs and changelog

@sgiehl also a question. Any reason we're using create here: https://github.com/matomo-org/matomo/pull/16311/files#diff-f96b6870514986e412c7f5454b5313a9R21 and autowire here: https://github.com/matomo-org/matomo/pull/16311/files#diff-cdccc896f5d7cfc50295cb535e230070R5

Which one is usually the better one to use?

Generally looks good otherwise. Be great to clarify usage of create vs autowire, update the docs etc. And be great if you could then also update the other free plugins and premium features after merging

I suppose we might also need to create new releases for plugins that already had a 4.x release

If I understood that correctly: DI\autowire needs to be used if any constructor parameter needs to be set by DI. If the definition already defines all parameters or none is needed you can use DI\create. So actually I guess it should be safe to always use autowire maybe 🤷

I suppose we might also need to create new releases for plugins that already had a 4.x release

If their DI config need to be updated... For some plugins it's only test config, so a new release might not be needed...

reading eg https://stackoverflow.com/questions/49474983/how-to-use-autowire-create-and-get-in-definitions-for-php-di I reckon autowire is a good choice that should always work.

looks otherwise good to merge. Need to update docs though.

I've also added a proxy from DI\link to DI\get now, so plugins that could possibly use DI\link won't break on update...

Sweet. Feel free to merge @sgiehl . Looks like some merge conflicts will need to be resolved.