Viewed   174 times

I am developing a plugin that used composer.. meaning it has a vendor folder inside the plugin folder which includes Guzzle HTTP dependency

On wordpress site we installed this plugin, there is an existing plugin that has Guzzle HTTP

Now when we activate this plugin i am getting an error something like this:

Fatal error: Cannot redeclare GuzzleHttpuri_template() (previously declared in /nas/content/staging/project/wp-content/plugins/my-plugin/vendor/guzzlehttp/guzzle/src/functions.php:17) in /nas/content/staging/project/wp-content/plugins/other-plugin/includes/lib/aws-sdk/GuzzleHttp/functions.php on line 31

I tried installing Plugins Load Order to force the 'other-plugin' to load first before 'my-plugin' currently the error is happening on the other-plugin's resources. this way, The error will yield in our autoload and we can catch that.

unfortunately.. Plugins Load Order did not work..

any ideas how to solve this?



Welcome to WordPress hell. We have 2018 and WordPress still does not have any dependency management and still didn't notice Composer existence.

WordPress ecosystem simply relies on assumption, that functions/classes names of plugins/themes should be unique. Obviously distributing popular 3rd-part Composer libraries with your plugin/theme is asking for trouble - it is easy to get names collision when other plugin is doing the same. There is no good way out of this situation.

If you want a bulletproof solution for standalone plugins, you should prefix namespaces of every package in your vendor directory with plugin prefix, for example myplyginvendor. Then GuzzleHttpClient becomes mypluginvendorsGuzzleHttpClient, so there is no risk of name collisions. This will require some work to write script for this (or you may use some existing solutions, like humbug/php-scoper), and you may get many duplicated dependencies (10 plugins may bring the same library 10 times, but with different namespaces), but this is the cost of integrating modern tools and patterns into outdated software.

If you're writing this plugin for yourself and you're controlling final installation, you may try to use Composer for installing WordPress and its plugins. You still may need to fix 3rd-party plugins (via forking) if they're have bundled some composer library, but in the long run it should simplify many things and you may avoid duplicating libraries for every plugin.

Wednesday, October 26, 2022

So register_rest_route goes inside "rest_api_init" action hook, and callbacks for routes can be defined in same file or in external one (then you can require it inside main file so you could add them to route/s). Here's an example:

Let's say you have a plugin "api-test", it's placed in: wp-contentpluginsapi-test and we'll add api-test.php as main plugin file (will be functional not oop for this example sake). Inside api-test.php you can have something like:

 * @wordpress-plugin
 * Plugin Name: WP Rest api testing..

 * at_rest_testing_endpoint
 * @return WP_REST_Response
function at_rest_testing_endpoint()
    return new WP_REST_Response('Howdy!!');

 * at_rest_init
function at_rest_init()
    // route url:$namespace/$route
    $namespace = 'api-test/v1';
    $route     = 'testing';

    register_rest_route($namespace, $route, array(
        'methods'   => WP_REST_Server::READABLE,
        'callback'  => 'at_rest_testing_endpoint'

add_action('rest_api_init', 'at_rest_init');

This is really simple example where everything's in the same file.

Wednesday, October 26, 2022

The namespace for guzzle 4 is GuzzleHttp in guzzle 3 the namespace was simply Guzzle.

A composer.json of:

    "require": {
        "guzzlehttp/guzzle": "~4"

Should allow you to run a php script of:

require 'vendor/autoload.php';

use GuzzleHttpClient;

$client = new Client();

$requests = Array(
    $client->createRequest('GET', ''),
    $client->createRequest('GET', ''),
    $client->createRequest('GET', ''),


If the autoloader still fails after changing the namespace it could be that your version of composer is out of date and does not recognize PSR4 autoloading. If there is no file in vendor/composer/autoload_psr4.php try doing a composer self-update followed by a composer dump-autoload to see if the problem is resolved.

Sunday, December 18, 2022

You don't need to add Guzzle to your composer.json, it's already autoloaded by it's own composer.json.

Guzzle 4

PHP 5.4.x+ required

composer require "guzzlehttp/guzzle" "~4.0"

Create a client:

$client = new GuzzleHttpClient();

Get results:

$response = $client->get('');


Guzzle 3

Install it:

composer require "guzzle/guzzle" "~3.0"

Create a client setting the base URL:

$client = new GuzzleServiceClient('');

Get your response:

$username = 'antonioribeiro';

$response = $client->get("users/$username")->send();

And display it:


If you still don't get it running, check the file vendor/composer/autoload_psr4.php, Guzzle must appear in it. If it doesn't, remove your vendor folder and install it again:

rm -rf vendor
rm composer.lock
composer install
Saturday, November 19, 2022

The short answer is see the following answer.... the long answer is you can work around it.

The only way I have coped in the past is to effectively fork the 3rd party library and cut a release myself. This of course is easier said than done and is just plain difficult if the library is large and complex and impossible if the 3rd party library is closed source. An easier route maybe to approach the 3rd party and ask them to cut a release.

Another option may be to copy their pom (ensure that it has no snapshots) change the version information and manually install the pom and artifact in your repository.

Tuesday, August 16, 2022
Only authorized users can answer the search term. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :