PayPal's documentation is pretty bad, but they do have a PHP notification verification sample here which mentions:
PHP Currently does not support certificate chain validation, that is necessary to validate webhook directly, from received data. To resolve that, we need to use alternative, which makes a call to PayPal's verify-webhook-signature API.
It also includes some files that aren't within the Checkout SDK. I found this question from a year ago in which someone created what seems like a decent explanation of all of the various missing packages and files that aren't included in the base SDK.
One of the key parts of their answer was to install a separate PayPal SDK, which they don't mention anywhere in the documentation, via composer (without mentioning its package name). Luckily composer has decent recommendations to my incorrect attempts at finding it so I got it eventually with: composer require paypal/rest-api-sdk-php. Looking through the files it downloaded, it's clear that this is the package that the Paypal documentation I listed above is including. However, upon requiring it I got the message
Package paypal/rest-api-sdk-php is abandoned, you should avoid using it. No replacement was suggested.
This seems pretty cut and dry, that it's not future safe and I shouldn't use it, but what am I supposed to do instead? Is there some new SDK somewhere I should be looking at or have they just given up on PHP and I have to just start making direct hand crafted API calls?
There is no supported SDK for webhooks -- not for PHP, nor for any other environment. Use a direct HTTPS integration.
I am updating a prestashop module by including a package that uses guzzle6.0.
Prestashop 1.7 uses an older version of Guzzle 5.
When I install the plugin on Prestashop the included package's version of Guzzle conflicts with the Prestashop one resulting in the following php error.
Uncaught PHP Exception InvalidArgumentException: "Magic request methods require a URI and optional options array" at /var/www/html/modules/package/vendorpackage/guzzlehttp/guzzle/src/Client.php line 81 {"exception":"[object] (InvalidArgumentException(code: 0):Magic request methods require a URI and optional options array at /var/www/html/modules/package/vendorpackage/guzzlehttp/guzzle/src/Client.php:81)"} []
I have found a few other examples of similar issues:
PrestaShop module classes not found (namespaces)
http://forge.prestashop.com/browse/BOOM-2427
Prestashop 1.6, conflict: 2 different modules requiring same class, different versions
https://github.com/Nexmo/nexmo-php/issues/77
Based on these I have a few ideas for how to get around the issue. None of these feel like the right way to do it. Surely there is a cleaner way to handle issues like this with composer?
Remove Guzzle from the included package - this is the simplest one, my problem with this is that if I remove this dependency where does it stop, whats to say any other dependencies wont clash later down the line that cant be removed?
Can check version of Guzzle in package and swap calls dependent on which one loads - similarly to the issue above I can hack a fix in to determine which type of call I should be using for this bug, but I cant tell what other issues this may raise and my code may end up littered with statements for each version.
Manually Change the namespaces of guzzle in the plugin. So I can go into the vendor folder of my package and force a specific namespace for the package, I am guessing this will solve my issue, but I am losing the point of installing a re-usable package.
Fork Guzzle and refer to that version. I could fork guzzle and include it as a VCS package in the plugin. Issue here being that I then have to keep that maintained moving forward.
The easiest way is to choose an alternative package for guzzle, but this might not be best for you.
Pros
You save a lot of time
Cons
You use different package to do the same thing.
The moderate way is to fork guzzle, and then you manually change the namespaces.
Pros
You don't change anything in Prestashop.
If Prestashop upgraded to guzzle 6.0, you could easily switch to it.
Cons
You have to maintain your own customized guzzle.
The hardest way is to patch Prestashop yourself
Pros
You get everything you want.
Send a pull request, you might help a lot of others.
Cons
If Prestashop kept using guzzlehttp 5.0, you end up in a patching nightmare.
Conclusions
I would choose the moderate way if I must use guzzle. If I just wanted to do something special in a few lines of code, I would just use an alternative package. And NO you cannot install different versions of the same package by composer.
Short answer: there's nothing you can do.
Long answer: I sort of found a workaround to your issue, given that I am in the same situation.
If your module depends on a package that depends on Guzzle, and if that package is under your control, you could make your package use HTTPlug. It is an abstraction and it relies on someone else include an actual HTTP client library. That someone could also be you, including a different implementation of php-http/client-implementation.
Over time, as Prestashop might also use this approach (along with other platforms), all of them might end up relying on PSR-7 abstractions of HTTP messages.
It's not really a solution to your current issue, but rather a strategy for the long run, which can also help with where you are right now.
You got two solutions:
Find a version of your package that uses GuzzleHttp 5 (if available).
Find an alternative of your package.
And NOT RECOMMENDED solution:
To change the namespace of Guzzle in your package and installed guzzle 6 too.
(example: use GuzzleHttp\ => 'use GuzzleHttpSix\')
This happens cause there is a conflict in namespace used (witch is the same for guzzle 5 & 6). And Prestashop gives priority to its packages.
The question does not specify what the main goal is. If your main goal is to update Prestashop (and not to solve the specific error), then I suggest that you create a local installation of the Prestashop environment - and use this to update your production environment manually, file-by-file. I can be done in the following way:
Create a fresh Prestashop installation in the intended version (1.7.5?) on your local computer (use a new database). Composer will ensure that the two installations use the same dependencies.
Backup your production database, and restore it on a local database server.
Reconfigure the local Prestashop to talk to local database.
Upgrade the local Prestashop. Check that this updated installation works.
Compare the local installation with the remote installation using a diff tool (for instance, Beyond Compare). Any differences between the two installations needs to be handled case-by-case:
Copy new / updated code from the local installation to the remote installation.
Remove any obsolete files from the remote installation.
Update the production database.
Remember to make a backup of the software and database before you begin.
You can just use "guzzlehttp/guzzle": "~5.0", in your module composer.json file and you the same version which uses prestashop.
I have a central Behat test suite codebase I use all throughout my companies projects. There is a ApiContext available which does curl calls using the curl lib from PHP itself but I really want to start supporting the Behat\Symfony2Extension in our Symfony projects as well so I don't have to setup nginx to listen to create a vhost to call those curl calls to.
I am a Symfony n00b and I'm not sure how to do this. I've setup the extension but the problem here (I think) is the use of curl in this case.
Maybe someone of you could help me get an idea of what I can do to fix this. I still want to support this lib with external calls as it is used in other projects too.
I downloaded this php api package from github
https://github.com/elastic/elasticsearch-php/tree/2.0
but I am having a hard time installing it. I unfortunately dont have permission to use the composer/auto-loader from where I work so I have to do it manually. Is there a way of doing this?
Thanks for your help.
The classes look pretty well formatted PSR-4 so you should be able to just download the directorysrc/Elasticsearch, and make a simple autoloader of your own and register it (assuming you don't already have one setup to serve classes that adhere to PSR-4).
Here's some options: http://www.php-fig.org/psr/psr-4/examples/
All the other directories seem to to be extraneous to running of the classes--for unit testing and benchmarking.
I'm looking for a script that will quickly implement package install/update functionality for my framework. It should be able to do the following things:
Must be PHP 5 compatible.
Should be able to install and update components' files and database tables.
Should allow defining of package dependencies and have a form of conflict resolving.
Should allow UPDATE SQL-statements when the developer of the package provides it. (To make database alterations without losing data).
Should be able to 'jail' an update package to a target folder.
Should be able to define and detect different package types to apply mentioned 'jail'.
Should provide an API to integrate it in custom backend.
Should allow downloading of the packages, preferably over HTTP (rather than FTP or others).
I plan on using this as a stand-alone utility to easily provide updates for modular frameworks as well as custom code for our clients.
If you have recommendations of tools that are similar or used in an open source framework to base it off that would be good as well. :)
I don't know of any magic tools to do this, but a couple that might help you do these tasks are Phrake and Composer.
Phake is a PHP version of Ruby's Rake util. You could use these scripts to set up your database, update files and run unit tests.
For package management you could use Composer to manage your dependencies (it can also download from PEAR if you depend on packages from those systems) and of course this could be incorporated into your build scripts.