-
Notifications
You must be signed in to change notification settings - Fork 9
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
Guzzle conflicts #1992
Comments
Hmm, you are right that I think we could remove that file from the built package, but that one isn't what's causing your problems :D I'll look into the others like it ;) |
Seems like |
Even if this plugin doesn't use the classmap, I think it may come into play when another plugin tries to load one of those classes and it tries each of the autoloaders in turn. If it finds a guzzle class via your autloader then that is what it will load (despite it having a different namespace). autoload_files is also problem because the functions it loads are different for different versions of guzzle. I think because the hash is determined by the filename, only one version gets loaded. I was hoping to get around that by manually removing those files from my autoload_files and loading them explicitly rather than via autoload. But when trying this I think I ran into the classmap problem,. |
No, I mean the |
After a long break to deal with other issues, I'm back on this. I think the class loading works fine because all the classes in your plugin have been included in your namespace. The problem is with static functions - such as those in /guzzlehttp/guzzle/src/functions_include.php. The set of files containing static functions appear in an array in autoload_files.php and autoload_static.php. The array is indexed by a file identifier that is generated from the file name which doesn't include your namespace. So the same file identifier is generated for your /guzzlehttp/guzzle/src/functions_include.php as for the one I'm using - even though I'm using a different version of Guzzle and the functions in yours are differently named because they have your namespace applied. I can't quite see where the array from autoload_static.php is used, but I can see that the files in autoload_files.php are loaded in autoload_real.php. The file identifier is used to index a global array which is used to stop the same file being loaded twice. So whichever of us loads a file with an identifier stops the other one's version from being loaded. I've managed to demonstrate a resolution of the problem, by (manually) editing all my file identifiers to have a prefix so they are different from your ones. However, it might make more sense if an edit was applied in your plugin as that would stop your plugin clashing with anyone naively using Composer to include Guzzle. It looks like a similar effect can be achieved by editing your autoload_real.php code to replace:
By Thoughts? |
The updated #2000 should fix this as well :) |
This has been raised to follow on from https://wordpress.org/support/topic/guzzle-coflicts/.
In the [documentation for PHPScoper (https://github.com/humbug/php-scoper/blob/main/docs/limitations.md#composer-autoloader) it says: “PHP-Scoper does not support prefixing the dumped Composer autoloader and autoloading files.
If you look at the contents of, say, autoload_classmap.php delivered with the plugin you will see that this still has the original un-namespaced class names. Whilst this may not affect the operation of this plugin, another plugin trying to load a guzzle class will find find this plugin's autoloader loading this plugin's (namespaced) version instead.
The text was updated successfully, but these errors were encountered: