I want to add a directory in /cache. i.e. /cache/custom and if I run command:
./symfony clear:cache
All files in custom directory gets deleted. I don't want these files deleted even if I run ./symfony cc. Any solution?
The cache directory has a different purpose. You should not write your custom files to folders like cache, logs, components, vendor because they are overridden while running some commands or while running the application.
Related
I just inherited a composer project in a very bad shape. They sent me a zip file with the vendor directory in it and I suspect that the previous developer has edited files directly inside vendor.
Is there a way to "validate" the vendor folder to ensure that the files inside are unmodified?
Change the name of the old vendor to something else.
Execute composer install again.
Run diff to compare both directories.
E.g. for a sample project where I intentionally modified a single file inside vendor.
$ mv vendor vendor_old
$ composer install
### install output...
$ diff -rq vendor vendor_old
Files vendor/autoload.php and vendor_old/autoload.php differ
Files vendor/composer/autoload_files.php and vendor_old/composer/autoload_files.php differ
Files vendor/composer/autoload_real.php and vendor_old/composer/autoload_real.php differ
Files vendor/composer/autoload_static.php and vendor_old/composer/autoload_static.php differ
Files vendor/symfony/console/Terminal.php and vendor_old/symfony/console/Terminal.php differ
You can mostly ignore the changes to the autoload* files, but with this listing you can concentrate in those other files that report differences (and run a more exhaustive diff from them).
In the example, only vendor/symfony/console/Terminal.php was actually modified.
Copy the project into some other folder, and delete the vendor directory. Run composer install and compare two vendor files.
The easiest way to do this is by using composer status command.
The prerequisite is that package is installed from source (as described on the official Composer site):
If you often need to modify the code of your dependencies and they are installed from source, the status command allows you to check if you have local changes in any of them.
i want to create a bundle in my symfony project via
php bin/console generate:bundle
but it errors me in the terminal:
[Symfony\Component\Config\Exception\FileLoaderLoadException] The file
"../../src/AppBundle" does not exist (in:
C:\wamp64\www\exp\app/config) in
C:\wamp64\www\exp\app/config\services.yml (which is being imported
from "C:\wam p64\www\exp\app/config\config.yml").
[Symfony\Component\Config\Exception\FileLocatorFileNotFoundException]
The file "../../src/AppBundle" does not exist (in:
C:\wamp64\www\exp\app/config).
You might have deleted AppBundle from src folder (or test folder) manually which is the major reason for getting this error.
Browse app\config\config.yml , app\AppKernel.php and app\config\routing.yml and remove the referring to AppBundle.
Once done Please clear the cache and re-run the project.
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.
I run the command
php app\console cache:clear
And get the fowllowing answer in a local environnement in Windows
[Symfony\Component\Filesystem\Exception\IOException]
Failed to remove directory "D:\nginx\web\symfony\dev\var\cache\de~\annotations\fd"
I first checked if the weird de~ folder existed and deleted it running :
mkdir empty
c:\Windows\System32\Robocopy.exe /MIR empty cache *
which by the way works also to delete too long file names in the cache folder.
Then I checked in windows ui the cache folders, I had a previous cache folder in the app directory and now that I updated Symfony using composer (v2.8.7), it appears to be in the var folder.
All those cache folders are empty, but I still get the weird message with that de~ folder that does not exist anymore.
I know I worked with annotations to improve my entities to create a postgresql database and tables with correct behavior and modified my config file to use entity managers to have more control over which tables tables to create but I don't know if that error comes from there as I use Doctrine annotations in these entities files.
Try adding the --no-warmup flag to the cache clear command:
$ php app\console cache:clear --no-warmup
This has negated strange cache errors for me in the past. Otherwise some wrong permissions are probably being set somewhere.
I have two controllers with the same name:
app\controllers\CareersController.php (for public use)
app\controllers\Admin\CareersController.php (for admins)
Because of the naming conflict, I added namespace admin; to the admin controller.
Everything works fine locally but when I uploaded the new admin controller to my server, I get an error: Class Admin\CareersController does not exist
From what I understand, the fix is:
php artisan dump-autoload
and composer dump-autoload
However, I don't have Shell access to run those commands and composer isn't installed on the server anyway. So, is there a way to reload the auto-load file without Shell access?
Run composer dump-autoload locally. Then, in your hosting site,
you can update two files, autoload_classmap.php and autoload_static.php, manually in vendor/composer folder. I prefer to copy and paste the added classes from local to the hosting server.
You dont need shell access. Artisan includes a dump-autoload function. You can just it via a PHP call within your app:
Route::get('/updateapp', function()
{
\Artisan::call('dump-autoload');
echo 'dump-autoload complete';
});
Edit: just noticed you wrote "composer isn't installed on the server anyway". Not sure what will happen - try the command above and let us know.
If it doesnt work - then just run composer dump-autoload locally - then upload your new autoload.php.
As a side point - is there any option to switch servers? You going to keep running into various issues if you dont have command line & composer access. You could just use Forge and spin up a new server on DigitalOcean, Linode etc in less time than it would take to fix this issue :)
I was using a shared hosting by client's requirements and did not have access to ssh or composer, what I did was to composer dump-autoload on my local machine and then I figured that for my project autoloader just updates composer directory in my vendor directory, so I just re-uploaded that one folder after each dump-autoload and not all vendor directory
Edit:
Another pitfall for me that generated the same error but the cause was something else, I develop on Windows machine in which file and directory names are case insensitive when deploying to Linux server, the framework could actually not find my controllers so I changed
Route::get('/news', 'newsController#index');
to
Route::get('/news', 'NewsController#index');
now it is working, autoload is doing it's job correctly