I wanted to make vendor directory common for more than one project. So I moved it and updated my app/autoload.php accordingly: ($loader = require __DIR__.'/../../../vendor/autoload.php')
It worked to some degree - it seems Symfony was able to find it's way to vendors directory BUT somewhere along the way autoloading my bundles got broken. I get this:
FatalErrorException: Error: Class 'My\FooBundle\MyFooBundle' not found
in (...)\Symfony\app\AppKernel.php line 19
How should I solve this? Should I somehow add dir with my bundles to app/autoload.php?
I understand that Composer is responsible for autoloading anything within vendors dir, but not my bundles, so I guess that messing with composer.json doesn't make sense, right?
You should check the vendor/composer/autoload_namespace.php file. The $vendorDir should stay the same, but the $baseDir certainly needs to be changed.
Make sure the line "psr-0" in composer.json point to correct path. In your case, I guess it should be YourBundleFolder/src. Normally it's just src because src is same level with composer.json. Now you have moved the vendor folder, I guess you moved the composer.json also. That's why it can not find your bundle.
Related
(I know others have written about this, but the answers don't seem to help in this instance)
I have a WordPress PHP plugin (https://github.com/LiquidChurch/lqd-messages/) which uses WDS-Shortcodes which in turn uses TGM-Plugin-Activation. When I run composer install from within the lqd-messages plugin I get the following error:
In ClassMapGenerator.php line 69:
Could not scan for classes inside "/lqd-messages/vendor/webdevstudios/wds-shortcodes/vendor/tgmpa/tgm-plugin-activation/class-tgm-plugin-activation.php" which does not appear to be a file or folder"
I can then go into /lqd-messages/vendor/webdevstudios/wds-shortcodes/vendor and see that there is no tgmpa folder.
If I then go back to /wds-shortcodes and run composer install, the tgmpa folder will be successfully created.
Obviously, this is less than ideal. Is there a way to get around these extra steps?
This is bug in webdevstudios/wds-shortcodes package - their autoloadig settings are incorrect. Dependencies should not declare loading files from other dependencies inside of vendor directory - this is not their concern (and these files will not exist in some scenarios, like yours).
I can only recommend forking this package and fixing autoloading settings:
"autoload": {
"classmap": ["includes/"]
},
BTW: You've made the same mistake in your package.
I'm searching for override a file which is in the vendor's directory
but is not a bundle.
I'm working with Symfony 2.7
To be more specific, i'm trying to override a method in this file :
vendor/akeneo/pim-community-dev/src/Pim/Component/Catalog/Updater/ProductUpdater.php
And I'd like to do it in a file like :
src/MyApp/Component/Catalog/Updater/ProductUpdater.php
All the documentation I've found is relied to parts of a Bundle.
So, is it even possible to do that ?
If it is, how to do it ?
There is a way to override a file using composer.
You can add in your composer.json under the autoload->psr-4 key something like this.
"autoload": {
"psr-4": {
"Pim\\Component\\Catalog\\Updater\\": "MyApp/Pim/Component/Catalog/Updater"
},
Where the first part is the namespace of the file you want to override and the second part is the new path.
This can create some issues when you add new packages to composer, so make sure you run composer dump-autoload to recreated the autoload order.
i don't really like this method, but it did save me a couple of times to fix files from bundles without actually forking the bundle, and if nothing else helps this can me used as a last resort.
More about composer autoload here
https://getcomposer.org/doc/01-basic-usage.md#autoloading
Hope this helps,
Alexandru Cosoi
We'd like to create a bundle which can deployed via composer/packagist for others to use. It'll wrap the logic created by the owners of MessageBird. Basically a kind of Service which will indeed be called with the container via ourvendor.messagebird.messaging.
Since it's a type of bundle (as per the docs of Sf3), we created a bundle while following the documentation:
http://symfony.com/doc/current/bundles/SensioGeneratorBundle/commands/generate_bundle.html
As the directory /src we used /vendor instead. That's when it all went wrong. Our namespace could not be located, loaded or even when we manually added it to the autoloading classes of Composer it failed all the same.
The question is, what is the best practice to go about this? We got it working right now and what we did was the following:
We created a bundle wit the following cmd:
bin/console generate:bundle --shared --namespace=OurVendor/MessageBird/MessageBirdBundle --bundle-name=MessageBirdBundle --format=yml
We moved the /src/OurVendor directory to /vendor/OurVendor as the only way to get a perfect generation was to use the default /src folder.
We manually updated the AppKernel.php
We did some debugging with namespaces for Composer but eventually we added "OurVendor\\":"vendor/" to the "autoload/psr-4" directive in root composer.json
We ran composer dumpautoload && bin/console cache:clear -e dev which resulted in an error.
We ran composer -o update which checked all dependencies and updated accordingly, including autogenerated autoload files
Strangely enough we had to add the Bundle to the AppKernel.php class and cleaned the cache again.
After all this it worked but the documentation said no such thing about developing a 3rd party vendor bundle.
http://symfony.com/doc/current/bundles/best_practices.html
So long story short, did we go about it the wrong way or what?
/vendor directory is managed by composer. Do not copy/move anything there. Don't even edit anything there, unless you understand all consequences.
When you create a shared bundle, you need to push it to a VCS of your choice, and add it as a dependency in composer.json of the project which uses it.
When you run composer update it will check-out your bundle into /vendor directory and generate correct autoload file.
Please read more how to use private repositories with composer.
Banging my head for hours here -- I'm sure I've forgotten something stupid.
I had a previously working Symfony component (Finder). I composer-updated after moving other components to dev in the composer.json file. The composer update no longer places the Finder files in the correct subfolder as it correctly did previously:
\vendor\symfony\finder\Symfony\Component\Finder (correct)
Instead, it's putting them into:
\vendor\symfony\finder (incorrect)
Unfortunately, most of the file pointers and autoloaders still point to the longer path (use Symfony\Component\Finder\Finder;)
Here is the composer.json:
{
"require" : {
"symfony/finder" : "~2.6" // have tried with "2.7.1"
},
"require-dev" : {
"raveren/kint" : "v0.9",
"filp/whoops" : "~1.0"
}
}
What the heck am I doing wrong?
No, the place where the finder is put is correct. It changed in Symfony, they threw out that whole bunch of useless directory levels that were empty.
Your code should not be affected by this transition. It would only be affected if it tried to include the file that was moved directly. Why would you want to do this - autoloading would solve it for you.
I don't think Composer would write incorrect autoloader files, but to be sure you can run composer dump-autoload to recreate them.
Vagrant and mounted folders do not play nice with composer using relative paths to folders added in via the
"autoload" option.
It in-correctly detects what the baseDir is and therefore will fail to register the namespaces.
Has anyone come across this before?
For isntance
"autoload": {
"psr-4": { "Inventory\\" : "./core/src/inventory/" }
}
The autoloading is supposed to be given relative to the path where the composer.json file is located. I've never seen that path starting with a dot, so first of all I'd try to get rid of that and see how that works.
Second thing that might simply be is that you got the autoloading wrong in some detail and mistake it for being something related to Vagrant. The way you currently set it up, a class named \Inventory\Foo must be located in the path core/src/inventory/Foo.php. Can you verify that this is the case? Otherwise please give an example of an existing class name and it's file name.