Skip to content
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

Class Not found #20

Open
Shibly opened this issue Aug 11, 2020 · 9 comments
Open

Class Not found #20

Shibly opened this issue Aug 11, 2020 · 9 comments

Comments

@Shibly
Copy link

Shibly commented Aug 11, 2020

When I install the package through composer and tried for a test call, it says,

Class ClickSend\Configuration' not found

@ArcazSuarez
Copy link

ArcazSuarez commented Aug 22, 2020

I got the same problem. Does anyone know any solution?

@jacksegal
Copy link

I had the same issue, but managed to get it working by installing the ClickSend SDK in a fresh project (rather than adding it to a Laravel one).

So there seems to be some sort of clash with the autoload / namespacing?

@jacksegal
Copy link

After further investigation I noticed that my fresh project was installing v5.0.64 of clicksend-php but my laravel project was installing v5.0.1.

I tried to manually force my laravel project to install v5.0.64, but I received a guzzle clash:

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - Can only install one of: guzzlehttp/guzzle[7.1.0, 6.5.x-dev].
    - Can only install one of: guzzlehttp/guzzle[7.1.1, 6.5.x-dev].
    - Can only install one of: guzzlehttp/guzzle[7.1.x-dev, 6.5.x-dev].
    - Can only install one of: guzzlehttp/guzzle[6.5.x-dev, 7.1.1].
    - clicksend/clicksend-php v5.0.64 requires guzzlehttp/guzzle ^6.2 -> satisfiable by guzzlehttp/guzzle[6.5.x-dev].
    - Installation request for clicksend/clicksend-php 5.0.64 -> satisfiable by clicksend/clicksend-php[v5.0.64].
    - Installation request for guzzlehttp/guzzle ^7.1 -> satisfiable by guzzlehttp/guzzle[7.1.0, 7.1.1, 7.1.x-dev].

@jacksegal
Copy link

I can get it working on laravel by removing the following require from my composer.json:

"guzzlehttp/guzzle": "^7.1"

It then successfully makes the API call to ClickSend - although not sure which parts of Laravel need guzzle v7

@jacksegal
Copy link

jacksegal commented Oct 2, 2020

Okay, think I've found the best solution:

  • Forked this repo: https://github.com/jacksegal/clicksend-php
  • Increased the guzzle version in composer.json (to match Laravel)
  • Removed the original clicksend-php lib: composer remove clicksend/clicksend-php
  • Installed the forked lib (dev-master): composer require jacksegal/clicksend-php "dev-master"

@Waseem-Alhabash
Copy link

@jacksegal Thank You , works like a charm !!

This was referenced Oct 9, 2020
@xurizaemon
Copy link

xurizaemon commented Oct 9, 2020

@jacksegal rather than suggesting people use your fork, you can PR your change to the upstream repo

https://docs.github.com/en/free-pro-team@latest/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request

for me (not using Laravel, so I don't have the same deps as you), the fix was:

# get rid of currently installed 7.x guzzle
composer remove guzzlehttp/guzzle

# require compatible versions of clicksend and guzzle 
composer require clicksend/clicksend-php:^5.0 guzzlehttp/guzzle:^6.2

While the version bump might fix your composer issue, you may or may not find that ClickSend is fully compatible with v7 of Guzzle. The requirement really only wants to be changed if it's required. If ClickSend is compatible with multiple releases of Guzzle then Composer supports multiple versions eg ~6.0 || ~7.0 which would avoid requiring all other projects using the same library to upgrade their Guzzle lib.

@jacksegal
Copy link

Thanks @xurizaemon - there is actually already an issue open for them to update their dependencies: #23.

I was just letting people know there was a manual workaround to their problem 👍

@xurizaemon
Copy link

xurizaemon commented Oct 9, 2020

I get that, but it's no small task taking on maintenance of a fork; you really should consider

  1. whether the proposed change is required (read above please), and
  2. whether it's less maintenance for you in the long run, and less risk for others, if you get that fix into the core product and off your desk

Best of luck! 😁

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants