I am using Symfony 5.1.8 in an existing project and installed Api Platform, version 2.5.7:
composer req api
I added an #ApiResource() Annotation to one of my entity classes.
When calling the /api/ route there is always just a message saying "No operations defined in spec!". The problem does only occur on my dev system (php 4.7.11, macOS Catalina 10.15.6, xdebug... ). So I do not think it's a configuration problem...
When I deploy this to my testsystem (debian with docker containers) everything works as expected - there are shown 6 resources I can interact with.
I tried to update my composer dependencies, clear the cache several times, clear the cache folder... nothing of this helped.
When calling
bin/console debug:router
on my test system, I get all 6 resources. In my dev system there are no routes shown.
Do you have any ideas where to start debugging to better understand the problem?
What are further interesting details?
Edit:
It works in the dev system when changing the environment to "test". But I do still not have a clue, why...
regards
Stephan
I found the answer.
I am using redis for system cache, so the deletion of the cache folder (./var/cache) didn't help.
A normal cache:clear didn't help, too:
bin/console cache:clear
But a cache clear of the system cache did the trick:
bin/console cache:pool:clear cache.system_clearer
Related
I build API project using Laravel 8, and I put my project on Git. My production server using Ubuntu Apache. I use only 1 database, and it's use on my local and production server.
I have weird problem since yesterday and make me confused. So, I push the latest commit to my Server from Local Server. Everything went well. But when I try to run my API via Postman, the results from my Local and Production server are different.
I checked manually in the files I pushed from local, everything is exactly same.
I try git status, everything OK. git pull are up to date. Here i attach the screenshoot.
Since i use laravel, i try to clear cache with php artisan cache:clear and it doesn't work.
Here i attach my Postman result:
As you can see, the result are different. I believe, there is no error with my code, It's work well on my Local server.
I try to contact my server provider, but didn't get any solution.
Anyway, this is Header from Prod Server
I'll appreciate all the answer from this thread. Thank you
Are you working on same branch in local and server? check your git branches in both.
Thank you for the answer and comment.
I already solve this problem. The problem pure from my production file and server.
first i try to restart my docker, and then run php artisan config:clear.
Locally, my Laravel 5.2 project works well, including events that are queued using Redis.
IMPORTANT UPDATE: I later discovered that this premise was incorrect (and my events don't use Redis), and so I'd accidentally posted this question in a misleading way. I hope my ridiculously long struggle and my answer below will be helpful to someone else who is an events newbie too.
But I've deployed my project to a production server (where I'm using a Laradock Docker setup).
There, on production, Redis works for caching and for delayed dispatching of jobs.
So I know that my Redis setup is good.
But events don't work (even though they worked when my project was on my local computer).
My question is not a duplicate of Laravel 5.2 event not firing in production because I'm not using broadcasting and because I am using Laradock.
I've also already tried these commands (inside the container at docker exec -it laradock_workspace_1 bash):
php artisan config:cache
php artisan clear-compiled
php artisan optimize
composer install --no-dev
composer dumpautoload
php artisan queue:restart
My events are working on production now. Here is what I learned:
I'd read https://laravel.com/docs/5.2/events many times, but I don't know where/why I got the idea that "events" (which were a new concept to me) relied on Redis or cron jobs. So the entire premise of my question above was wrong! I was not using Illuminate\Contracts\Queue\ShouldQueue, so everything was synchronous and should have been more straightforward than I was thinking.
I think this tip about composer dumpautoload and php artisan clear-compiled was helpful (for after each edit of files on production).
The main issue seemed to be that a certain database table of mine seemed to have records with weird values, and those records were being checked by the event, and that's where it was all breaking.
And I think these records probably got into that corrupted state because on production I don't think I'd started the cronjobs and workers immediately upon deployment.
My local environment was working because its table didn't have these corrupted records.
Hopefully my naive and misleading question (which led to this ridiculously long struggle and this answer) will be helpful to someone else who is an events newbie too.
We have set up a kubernetes cluster for our laravel application on google cloud platform.
Containers:
application code + php-fpm
apache2
others not related to the issue
(We run under nginx-ingress-controller but this seems unrelated to the issue)
We run a jmeter stress tests on a simple laravel route that returns "ok" and we noticed terrible response times.
Afterwards we run the same test on an index2.php (inside public dir το slide over the framework) which just returns 'ok'.
And we got this result(!):
After digging we found out that the composer's autoloading stuff cause this slowness.
Any advice on how this could be resolved will be highly appreciated.
Thanks
Ok. We found out that we had no opcache enabled.
As documented about composer optimize-autoloader:
On PHP 5.6+, the class map is also cached in opcache which improves the initialization time greatly. If you make sure opcache is enabled, then the class map should load almost instantly and then class loading is fast.
I have downloaded Magento in combination with DevBox to build my webshop locally. After installation with the terminal, I got the url to the shop and the admin (something like: http://127.0.0.1:32769/ and http://127.0.0.1:32769/admin/).
This all worked great! But then I stopped to continue some other time and stopped the working-container with the commandline.
When I wanted to continue, I started the working container and it now runs on another port. However, on this port only the HTML is loaded.
The system tries to download the rest of the files on the old port (:32769), which is obviously not working. Stuck here!
It's hard to say without seeing your system (not super familiar with the devbox), but regarding
The system tries to download the rest of the files on the old port (:32769), wich is obviously not working. Stuck here!
It sounds like the URLs generated in your source might be cached from the previous session. This means they have the old port number. If you clear your system's cache store, that should solve the problem.
I'm not 100% sure if the dev box ships with redis as a cache store, or the file system, varnish, or something else. It depends on the options you chose. The first thing I'd try is running Magento's cache clean command from the command line
php bin/magento cache:clean
The next thing I'd try is removing the var/cache/* folders. If you're using varnish or redis you'll need to research how to manually clear those caches. Hope that helps!
I install my web site on ovh server but i think composer it not install on it.
So i have a fatal error
Class 'App\Models\Product\ProductModel' not found in /home/xxxxx/App/Controller/Home/HomeController.php on line 26
in my ftp i have
composer.json
App
bootstrap.php
Model
Product
ProductModel.php
Controller
indexController.php
Home
HomeController.php
www
index.php
I auto load App as App
Do you know if the problem is composer?
Do you know if i can use with out composer?
How?
thank you
Use Composer before you upload your code. Composer need not be executed on the server - in fact this is regarded more of a problem than a solution because it requires all package hosting servers to be up, and the command line tools for accessing version control systems be installed (at least as a fallback).
The recommended way to use Composer is to run it locally (or on a deployment machine that is local enough), let it fetch all files, create the autoloader, and then copy all the collected files to the target server.
This approach also resolves the problem with Composer requiring about 1GB of memory (or more, depending on how many packages have to be considered) when being run - if your web server has less memory installed, you won't be able to use Composer.