Move PiwikTracker.php to own repository and add dedicated
Benefit: Library will be available to download and integrate into projects using package manager (composer/packagist), just like other API tracking Clients are.
ATM if you are using composer you have to include whole Piwik but include just PiwikTracker.php or not use package manager and handle updates manually.
There are other benefits like dedicated test suite and better exposure to community,
Hi, have a look here: https://github.com/piwik/piwik-php-tracking/issues/1
How could I miss that?
Should I close the issue since it's labelled now?
It is included as a submodule to stay backwards compatible and to keep the libs/PiwikTracker path. We can have another branch in this repository for a refactoring and could include the refactoring branch at some point under vendor/... via composer. Just in case someone starts a refactoring
@tsteur What about committing a symlink from
libs/PiwikTracker to the new location in
vendor? Existing scripts would continue to work this way I believe.
However, that solution wouldn't support Windows (not sure if that's a target platform of Piwik or not.)
It is a target platform of Piwik
I don't want to beat a dead horse here, but I have one last proposed solution:
<?php if (!class_exists('PiwikTracker.php')) require_once BASE_PATH . '/vendor/piwik/piwik-php-tracker/src/PiwikTracker.php';
At that point, you could manage the tracker with composer with the rest of your dependencies, and existing code would continue to function correctly.
In fact, if you're planning to use the autoloading feature of composer with
piwik/piwik-php-tracker, you would just needs
libs/PiwikTracker.php to be an empty file to prevent errors.
If it works I would be totally okay with that solution :) Not sure if there would be any other downsides or disadvantages? We just need to make sure to not break BC in some way.
We'd probably need to adjust at least the Piwik build script eg here https://github.com/piwik/piwik-package/blob/master/scripts/build-package.sh#L19-L20
BTW: We would still have some submodules afterwards, eg log-analytics. But I think none of these submodules would be actually needed in order to use Piwik, only in specific cases. If we did this, one could setup a minimal Piwik by only using composer I reckon
Cool. :) I can't think of any major ones. The first approach (not having a blank file) is probably the safer solution -- if any other symbols are created inside the
PiwikTracker.php file that the autoloader can't handle, they wouldn't be guaranteed to be in scope with the empty file / trust autoloader approach. But having the usual included file redirect to the one in
vendor/ should function exactly as expected.
I'll implement this in the next couple days and play around with it a bit to make sure it works. On that note, I'll comment to hold off on merging the PR I submitted earlier today.
Sweet, thx for that. I will add a label work in progress to the PR