-
Notifications
You must be signed in to change notification settings - Fork 259
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
getPackageVersion in Helpers causes OutOfBoundsException errors on systems with multiple composer installs #833
Comments
Hit the same issue. v2.2.4 didn't have this issue, although the file you reference was still labelled v2.2.1 in the header comments, I reverted back to this and no longer hit the error...
|
Oh man. @N1ghteyes did you find a solution to this? FYI, the reason for this was for Xero to see which versions of the library were bring used during support requests. |
@calcinai I hacked it in the end to return a set value (rather than checking against composer), so no not really a fix I'm afraid. I suspect the actual fix here is to maintain a version constant that can be referenced - it'll just mean a manual update to it every time you push a minor version. |
For reference, this is what I ended up doing (based on @N1ghteyes comment above). I created a custom class CustomXeroApplication extends \XeroPHP\Application
{
/** @noinspection MagicMethodsValidityInspection
* @noinspection PhpMissingParentConstructorInspection
*/
public function __construct($token, $tenantId)
{
$this->config = static::$_config_defaults;
$transport = new Client([
'headers' => [
'User-Agent' => sprintf(static::USER_AGENT_STRING, 'v2.4.1'),
'Authorization' => sprintf('Bearer %s', $token),
'Xero-tenant-id' => $tenantId,
],
]);
$reflectionProperty = new \ReflectionProperty(\XeroPHP\Application::class, 'transport');
$reflectionProperty->setAccessible(true);
$reflectionProperty->setValue($this, $transport);
}
} |
@ValCanBuild I think the best way to do this is just to add a file as part of the build pipeline (and the tag). Just not completely sure how this would work with composer releases in terms of keeping the git tag consistent with the version in the code. |
Run into a weird problem with a wordpress build, with the following error:
That pathing looked odd to me, so i Tracked the issue to here:
The reference to \Composer is loading the composer namespace instantiated by the woocommerce-eu-vat-assistant plugin, not the custom plugin that is calling it.
For clarity, several plugins have vendor directories included, which means several versions of the \Composer namespace which means that \Composer\InstalledVersions is calling the wrong composer.json for checks, thus is failing (so far as i can tell).
Not sure what the fix is here - i'll provide one if i can work it out. Anyone else run into the same thing?
The text was updated successfully, but these errors were encountered: