Use rebranded composer components

[sgiehl]

refs #12519

[sgiehl]

@diosmosis @tsteur @mattab Switching to the rebranded packages (with new namespaces) might maybe cause problems while updating, as some plugins might still use the old namespace until they are updated.
Any ideas how we should solve that issue? Should we update the plugins before, so they use the actual available namespace? Or shall we still include both packages in Matomo 4 (old and rebranded ones), so both namespaces are still available - and remove the old one in Matomo 4.1 or so?

[tsteur]

and remove the old one in Matomo 4.1 or so?

I reckon this won't be possible since some people will update from older 3.x or 2.X to 4.1.

Updating plugins first can cause issues too if anything fails there.

Ideally the components would have both the new Matomo and the old Piwik classes but that might not be easily doable. Although the components typically maybe don't have too many classes so could be done maybe. Otherwise I suppose it should be fine maybe as long as the plugins don't access any component during update? They might though... also people manually updating core etc will have problems.

Do we even need to update the components from Piwik to Matomo or wait until we do this also for core?

[diosmosis]

Ideally the components would have both the new Matomo and the old Piwik classes but that might not be easily doable. Although the components typically maybe don't have too many classes so could be done maybe.

Could this be done via inheritance? Ie:

namespace Piwik;

class Abc extends Matomo\Abc {
  // empty
}

[sgiehl]

Could this be done via inheritance? Ie:

I guess that should work. Should we add those classes to the packages or to Matomo itself?

[tsteur]

Not sure what's easier?

[tsteur]

I suppose we would need to make sure the autoloader still finds the files etc.

[tsteur]

Very crazy thought... can the auto loader do that? Recognise Piwik namespace, then look for the matomo file that includes Matomo class, then do dynamically a if (!class_exists($piwikNamespaceClass, $doNotLoadFile)) { class $piwikNamespaceClass extends $matomoNamespaceClass }

Not sure if we can extend classes that way dynamically...

[sgiehl]

@tsteur I'll give it a try and implement it that way if possible

[sgiehl]

@tsteur found an even simpler solution using class_alias:

matomo/LegacyAutoloader.php

Lines 15 to 23 in 4226651

	public function load_class($className)
	{
	if (strpos($className, 'Piwik\\') === 0) {
	$newName = 'Matomo' . substr($className, 5);
	if (class_exists($newName)) {
	class_alias($newName, $className);
	}
	}
	}

[tsteur]

That's pretty cool 👍

[sgiehl]

Should be ready for review. Remaining package is piwik/device-detector. But I will do some more refactorings there before releasing a new rebranded version.

[tsteur]

Maybe I missed it but could we add maybe a few basic tests that this works?

In general behaviour seems otherwise good: https://3v4l.org/TAS8d

Can we assume, that if a file containing a Matomo class was loaded manually through include/require, then the logic would not work? (Probably not an issue but something to be aware of eg if we wanted to do that for all classes in core).

[sgiehl]

No, that works as well. Added some simple tests for it. See de2fea6