Prevent vendor conflicts with other WordPress plugins

[tsteur]

See https://wordpress.org/support/topic/activation-problem-critical-db-error/#post-12489059 and #19

We have quite a few vendor dependencies meaning there's a chance that other plugins embed the same vendor dependency but an older or more recent version and they aren't compatible with ours.

Doing a quick search found eg google/site-kit-wp#612 which solved this by prefixing vendor libraries see /~https://github.com/google/site-kit-wp/pull/696/files and /~https://github.com/google/site-kit-wp/pull/735/files

To ultimately solve this problem it may be interesting to see if we can do something similar. Might be quite a bit of work that needs to be done directly in core. This will solve a lot of trouble over the years of debugging similar issues.

Can't think of a different way to solve this.

[MikeNGarrett]

Very interested in this solution.

[tsteur]

Here's another conflict because of this with the popular WP-Optimize https://wordpress.org/support/topic/update-3-1-1-crashes-my-site/#topic-12931535-replies

[tsteur]

also see https://developer.yoast.com/blog/safely-using-php-dependencies-in-the-wordpress-ecosystem/

it's bit too late to do this in Matomo 4 so might have to do this as part of Matomo 5

[tsteur]

Generally this is as easy as this by the looks:

wget /~https://github.com/humbug/php-scoper/releases/download/0.13.10/php-scoper.phar
php-scoper.phar add-prefix

Then looks eg like this

(you can configure what files and namespaces etc to replace)

The problem is that this won't work actually or only for vendor libraries that only we use internally in the plugin.

I wanted to fix https://wordpress.org/support/topic/critical-error-after-upgrade/ to make the plugin work again regarding the newer PHP-DI library but already noticed while reading docs of course it can't work. That's because if if eg renames \Di\object() to \_PhpScoper7739d17947fe\Di\object() then this will work for our plugin but not for any other Matomo plugin. It's only a solution when you don't have any other plugins, or you own all plugins or only you use that vendor library and it is 100% guaranteed no other Matomo plugin won't access the vendor lib directly.

For when we do Matomo 5 we could prefix some things with Matomo like \Matomo\Di\object() and then get people to use this but it won't work any other way.

[tsteur]

We'll look into this as part of Matomo 5.

[mattmary]

Hello @tsteur

Here's how they proceed in the yoast SEO plugin: https://yoast.com/developer-blog/safely-using-php-dependencies-in-the-wordpress-ecosystem/
They use https://web.archive.org/web/20210412151924//~https://github.com/humbug/php-scoper

[MichaelSchober]

As far as I saw the proper fix is planned for Matomo 5. Is there some quick fix I can do right now for this issue?
It's currently happening for me with Matomo 4.14.2.

Thanks for the awesome work!

EDIT for anybody else stumbling onto this: here is the list with incompatible plugins.

[mattmary]

Hello @MichaelSchober

It's only plan for Matomo 5.x.
We are releasing the first beta soon, so it's coming.
Kind regards

Mat

[LordSimal]

Any update on this?

[eigenstil]

Any update on this?

I'm also very interested in this issue. As discussed in #618 this causes the WordPress backend to completly fail.

Background:

We have a lot of wordpress websites from our customers, where this became a problem in the last couple of days. all of these websites are now "inaccessible" in the backend. The only solution is to completly deactivate the matomo plugin (which is of course very bad, because then no more statistics are collected). Unfortunately, we can't disable the other plugins, as they are indispensable for the functioning of the websites.

[diosmosis]

@eigenstil @LordSimal we are currently working on this. You can track the remaining work in the following issues: #840, #841

[macwinnie]

Hey there =)
Any christmas present or at least an estimation for us on that topic? ... would be great to get those WordPress instances back up monitored and running =)

[diosmosis]

@macwinnie the remaining work involves making Matomo for WordPress work with Matomo 5, then just prefixing it and making everything work. I can't give an estimate, but it's the only thing I'm working on right now.

[schwarzpunkt]

Has the conflict between Matomo and WP Rocket been resolved with version 5.0?

[diosmosis]

@schwarzpunkt WP Rocket fixed the issue on their end. In Matomo for WordPress 5.0 we're also applying the fix so conflicts with other plugins will also go away. However, there appears to be an update issue with 5.0.2 that occurs if you're using a Matomo plugin installed through the marketplace. We're hoping to have that resolved by tomorrow at the latest.

[diosmosis]

Matomo for WordPress 5 prefixes some composer dependencies to prevent these types of conflicts, closing this one.