czcomunicacion

Hi Jarno, quick follow-up to close the loop. I got it working and wanted to share exactly what fixed it, in case it helps future patches or other users hitting this.

Root of the conflict: as you suspected, another component was loading a v3 translation-contracts interface before Metricool’s. I traced it to the theme, not a plugin. The loaded interface resolves to:

/wp-content/themes/pro/cornerstone/includes/integration/Twig/vendor/symfony/translation-contracts/TranslatorInterface.php

That’s Cornerstone (the Pro theme by Themeco), which bundles symfony/translation-contracts 3.x. Because both it and Metricool ship Symfony unscoped under the global Symfony\Contracts\Translation namespace, the theme’s autoloader registers first and its v3 interface wins. Metricool’s bundled symfony/translation v5.4.45 (contracts 2.5.4) then fails the signature check against that v3 interface.

Temporary workaround (on my install): the v3 interface requires the : string return type on a couple of methods that Metricool’s Translator doesn’t declare. I edited vendor/symfony/translation/Translator.php and added : string to the two methods PHP complained about, in cascade:

– trans(...) (line ~197) –> added : string
– getLocale() (line ~160) –> added : string

After resetting OPcache, the OAuth sign-in connected successfully.

I understand this is a patch on my side that won’t survive a plugin update, and I’m not suggesting it as the real fix, just documenting what unblocked it. The robust solution would likely be scoping/prefixing Metricool’s bundled Symfony dependencies (e.g. via php-scoper/Mozart) so they can’t collide with another component’s copy. Flagging it in case it’s useful for a future release, since the Pro theme is fairly widely used and others may run into the same crash.

Thanks for the help pinpointing the load-order angle!