Facebook API - "assureEndpoint is being deprecated" - php

Trying to use a package to handle my requests to the Facebook API. Getting this error, and not sure where to start.
Here is the package:
https://github.com/edbizarro/laravel-facebook-ads
Here is what i'm doing...
$adsApi = FacebookAds::init($accessToken);
$adAccounts = $adsApi->adAccounts();
$adAccounts->all(['account_id', 'balance', 'name']);
Here is the error:
ErrorException (E_USER_DEPRECATED)
assureEndpoint is being deprecated, please try not to use this in new code.

You should use the getEndpoint instead of this.
They have mentioned this in the sdk files on line 360 of
https://github.com/facebook/facebook-php-business-sdk/blob/master/src/FacebookAds/Object/AbstractCrudObject.php
/**
* #deprecated
* deprecate with getEndpoint
* #param string $prototype_class
* #param string $endpoint
* #return string
* #throws \InvalidArgumentException
*/
protected function assureEndpoint($prototype_class, $endpoint) {
.....
}

Related

Method Illuminate\Support\Str::transliterate does not exist

I am using:
Laravel: 9.x-dev
PHP: 8.1.5
laravel/ui: v3.4.5
After updating my application from Laravel 8 to Laravel 9 I get this error when trying to authenticate.
It references line 92 in vendor\laravel\ui\auth-backend\ThrottlesLogins.php
protected function throttleKey(Request $request)
{
return Str::transliterate(Str::lower($request->input($this->username())).'|'.$request->ip());
}
I resolved this error by changing Laravel off the dev release in composer. In my case going from 9.x-dev to 9.1.5
Solution
Try to run this command :
composer update
Make sure you imported this class ex:
use Illuminate\Support\Str;
i hope it was useful
Just add this code to you LoginController.php file
/**
* Transliterate a string to its closest ASCII representation.
*
* #param string $string
* #param string $unknown
* #param bool|null $strict
* #return string
*/
public static function transliterate(string $string, string $unknown = '?', bool $strict = false): string
{
return ASCII::to_transliterate($string, $unknown, $strict);
}
/**
* Get the throttle key for the given request.
*
* #param Request $request
* #return string
*/
protected function throttleKey(Request $request): string
{
return self::transliterate(Str::lower($request->input($this->username())).'|'.$request->ip());
}
I resolved it by updating laravel/ui to 4.0
"laravel/ui": "^4.0"
Supported version on the readMe here https://github.com/laravel/ui/tree/4.x

Symfony incompatibilities. The LoaderInterface and the XmlFileLoader have an issue

Situation:
This is the screen message I became after installing tikiwiki 24.
Fatal error: Declaration of Symfony\Component\DependencyInjection\Loader\XmlFileLoader::load($resource, ?string $type = NULL) must be compatible with Symfony\Component\Config\Loader\LoaderInterface::load($resource, $type = NULL) in /var/www/contiki/vendor/symfony/dependency-injection/Loader/XmlFileLoader.php on line 46
So please, does anyone have a clue what's going on here? I'm quite new to composer, solved many compatibility issues but this is out of my range.
I don't understand why they are incompatible.
These are (part) of the files:
My /var/www/contiki/vendor_bundled/vendor/symfony/config/Loader/LoaderInterface.php
interface LoaderInterface
{
/**
* Loads a resource.
*
* #param mixed $resource The resource
* #param string|null $type The resource type or null if unknown
*
* #throws \Exception If something went wrong
*/
public function load($resource, $type = null);
/**
* Returns whether this class supports the given resource.
*
* #param mixed $resource A resource
* #param string|null $type The resource type or null if unknown
*
* #return bool True if this class supports the given resource, false otherwise
*/
public function supports($resource, $type = null);
/**
* Gets the loader resolver.
*
* #return LoaderResolverInterface A LoaderResolverInterface instance
*/
public function getResolver();
/**
* Sets the loader resolver.
*/
public function setResolver(LoaderResolverInterface $resolver);
}
The first part of the /var/www/contiki/vendor_bundled/vendor/symfony/dependency-injection/Loader/XmlFileLoader.php file
namespace Symfony\Component\DependencyInjection\Loader;
use Symfony\Component\Config\Util\XmlUtils;
use Symfony\Component\DependencyInjection\Alias;
use Symfony\Component\DependencyInjection\Argument\BoundArgument;
use Symfony\Component\DependencyInjection\Argument\IteratorArgument;
use Symfony\Component\DependencyInjection\Argument\TaggedIteratorArgument;
use Symfony\Component\DependencyInjection\ChildDefinition;
use Symfony\Component\DependencyInjection\ContainerBuilder;
use Symfony\Component\DependencyInjection\ContainerInterface;
use Symfony\Component\DependencyInjection\Definition;
use Symfony\Component\DependencyInjection\Exception\InvalidArgumentException;
use Symfony\Component\DependencyInjection\Exception\RuntimeException;
use Symfony\Component\DependencyInjection\Reference;
use Symfony\Component\ExpressionLanguage\Expression;
/**
* XmlFileLoader loads XML files service definitions.
*
* #author Fabien Potencier <fabien#symfony.com>
*/
class XmlFileLoader extends FileLoader
{
const NS = 'http://symfony.com/schema/dic/services';
/**
* {#inheritdoc}
*/
public function load($resource, $type = null)
{
$path = $this->locator->locate($resource);
$xml = $this->parseFileToDOM($path);
$this->container->fileExists($path); <-- This is rule 46
$defaults = $this->getServiceDefaults($xml, $path);
// anonymous services
$this->processAnonymousServices($xml, $path, $defaults);
// imports
$this->parseImports($xml, $path);
// parameters
$this->parseParameters($xml, $path);
// extensions
$this->loadFromExtensions($xml);
// services
try {
$this->parseDefinitions($xml, $path, $defaults);
} finally {
$this->instanceof = [];
}
}```
Sounds like something's got tangled up here, Tiki 24 is not out yet but will be branching soon, so if you want a stable safe Tiki now, probably best to use a stable released branch, i.e. 23.x? Also, we are still on Smarty 3.x and plan to upgrade to 4.x (and PHP 8+) after the release of 24 which is our next LTS version, so not sure where that is coming from... did you run sh setup.sh?
As Nico said above, this is probably more Tiki-specific than is suitable for here, so the best thing would be to come and chat with the community in our new Gitter room, here?
Welcome to Tiki! :)

Type error: Argument 1 passed to PayPal\Rest\ApiContext::setConfig() must be of the type array, null given, called in PaymentController.php on line 40

I'm trying to implement the paypal into my site.
But I'm getting this error .
Type error: Argument 1 passed to PayPal\Rest\ApiContext::setConfig() must be of the type array, null given, called in D:\wamp64\www\vonservices\app\Http\Controllers\PaymentController.php on line 40 .
Here is my controller code :
class PaymentController extends Controller
{
private $_api_context;
/**
* Create a new controller instance.
*
* #return void
*/
public function __construct()
{
//parent::__construct();
/** setup PayPal api context **/
$paypal_conf = \Config::get('paypal');
$this->_api_context = new ApiContext(new OAuthTokenCredential($paypal_conf['client_id'], $paypal_conf['secret']));
$this->_api_context->setConfig($paypal_conf['settings']);
}
/**
* Show the application paywith paypalpage.
*
* #return \Illuminate\Http\Response
*/
public function payWithPaypal()
{
return view('paywithpaypal');
}
/**
* Store a details of payment with paypal.
*
* #param \Illuminate\Http\Request $request
* #return \Illuminate\Http\Response
*/
}
?>```
\Config::get('paypal') is an old way to find data in config. Try use config('paypal') and php artisan config:cache before using it.
I know its very late but I had the same problem. What solved my problem was running
php artisan config:cache
And voila, it solved everything for me. Hope it works for others too.

Does PHP have a convention for describing Promise returns in function docblock

I just wrote a function like this
/**
* Send an asynchronous GET request
*
* #param string $url
* #param array $options
*
* #return \React\Promise\ExtendedPromiseInterface
*/
public function getAsync( $url, array $options = [] );
but when making docblock, I realized that #return \React\Promise\ExtendedPromiseInterface is very generic and doesn't really help client understand what returns are to be expected in case of rejection or fulfillment.
Is there some established convention for documenting which values or exception are expected as a result of this function so that the client could chain on this function by looking at the interface only?
For exceptions you can add:
/**
* #throws customException if the bad thing happens
*/
You could add as many of these as you like too. After the #return you can add a type before and a short description of what it is after.
Not having found anything, I ended up making this up
/**
* Send an asynchronous GET request
*
* #param string $url
* #param array $options
*
* #return \React\Promise\ExtendedPromiseInterface
*
* #promise.resolve \MyApp\Interfaces\ResponseInterface
* #promise.reject \MyApp\Exceptions\RequestException
*/
public function getAsync( $url, array $options = [] );

How to document usage of a method when called in an abstract form?

In a legacy project, I was confused when I tried finding the usage of a method in phpstorm and without success.
/**
* #param SomeEntity[] $someEntity
*
* #return bool
*/
protected function warmupSomeEntity(array $brandUniverses)
{
// I want to find this method's usage
}
Debugging a bit further, I found that the method is called on the fly in a rather abstract way via dynamic class method invocation:
/**
* #param string $warmer
* #param array $objects
*
* #throws RuntimeException
*/
public function warmupType($warmer, array $objects)
{
$method = "warmup$warmer";
if (method_exists($this, $
$this->{$method}($objects);
} else {
throw new RuntimeException("There is no warmer '$warmer'");
}
}
Is there a phpdoc syntax where I can document that the warmUpType method will call warmupSomeEntity, or warmupSomeOtherEntity so that I can find its usage again if I want to jump to the calling code block again?
The #uses keyword was what I was looking for as it:
Display a link to the documentation for an element, and create a backlink in the other element's documentation to this
It is supported by PhpStorm and the caller is found again.
/**
* #param string $warmer
* #param array $objects
* #uses warmupSomeEntity
* #uses warmupSomeOtherEntity
* #throws RuntimeException
*/
public function warmupType($warmer, array $objects)
{
...
}

Categories