I have a Laravel application that refuses to acknowledge controller changes even if the controller doesn't exist anymore!
Using MAMP PRO 5.5.3 and Laravel 4.1
with
/Applications/MAMP/bin/php/php5.5.3/bin/php
I have followed these instructions
Stop caching for PHP 5.5.3 in MAMP
I have deleted the view storage in Laravel.
There was mention of adding - opcache_reset(); in my bootstrap/autoload.php
http://laravel.io/forum/02-06-2014-laravel-and-view-caching-in-development-cant-see-changes-right-away
But not sure how and where you do you do that, I tried but just got an error
Call to undefined function opcache_reset()
The caching still continues!
Despite the controller having been deleted 2 hours ago (to prove controller not being called), it is still showing the page with an imaginary controller.
It's driving me insane.
Any help really appreciated.
Further to this the route file is refusing to accept UserController
Route::get('register', 'UserController#getRegister');
Giving this error
.....controllers/UserControllerb.php): failed to open stream: No such file or directory
UserControllerb.php doesn't exist and was not asked for ?! but the route is wrongly looking for it
When I try this
Route::get('register', 'UserControllerb#getRegister');
Rightly give this error
Class UserControllerb does not exist
So the route has been cached (a previous back-up removed days ago)
I have tried to use composer which decides it doesn't want to work and no-one seems to know the solution for either problem.
Laravel composer signal "11" error symfony osx
Huge kudos to anyone who can solve this.
Related
I am no longer able to send email from my Laravel app once I updated to v6.10, 6.11. I have not changed any code, nor have I required or removed anything new from composer recently. This appears to be potentially something with the new build of Laravel, as this exact code is functional and sending email on v6.7 and below.
Error msg:
Class 'League\CommonMark\Environment' not found (View: /home/ww/app/vendor/laravel/framework/src/Illuminate/Mail/resources/views/html/footer.blade.php)
{"exception":"[object] (Facade\Ignition\Exceptions\ViewException(code:
0): Class 'League\CommonMark\Environment' not found (View:
/home/ww/app/vendor/laravel/framework/src/Illuminate/Mail/resources/views/html/footer.blade.php)
at
/home/videocyp/app/vendor/laravel/framework/src/Illuminate/Mail/Markdown.php:103)
The line from my footer from my published vendor file that is causing the issue:
{{ Illuminate\Mail\Markdown::parse($slot) }}
Inside the vendor file Markdown.php
use League\CommonMark\Environment;
class Markdown
{
public static function parse($text)
{
$environment = Environment::createCommonMarkEnvironment();
// etc...
}
Looking at League\CommonMark\Environment, I find the class (as does my IDE):
final class Environment implements EnvironmentInterface, ConfigurableEnvironmentInterface { }
I'm beyond my level of understanding here as to why Laravel is unable to see one of its vendor classes.
Anyone able to help?
Turns out this is the result of a significant (slightly breaking) change made to the Laravel build as of v6.10.
Due to a potential XSS vulnerability, it looks like they changed the root parser to League CommonMark. This is causing other issues with existing email published templates due to excess white space being parsed differently in the new CommonMark parser. Bugs are reported here, here, here.
My particular problem was extremely strange, but it is being reported elsewhere in addition to those reported back to Laravel. It was not consistent across my servers, but a complete rebuild (vagrant) solved the issue.
For the others with their previously published email templates showing raw HTML, a re-publish may resolve the issue if lucky and no changes were made to the templates.
Run the following to regenerate the list of all classes that need to be included in your project.
php artisan clear-compiled -o
composer dump-autoload
If still not working, maybe try reinstalling the package.
composer require league/commonmark
What version of Laravel did you upgrade from? Laravel 6.7?
Strange problem: Have installed Laravels 'Valet' to serve sites from .dev locally. When I am in my 'code' directory where I parked valet and create say laravel new blog installed perfectly and spins up on blog.dev. However say I create laravel new test and visit test.dev I get 404 - nothing found ...? I removed everything and tried again but the same thing happens. Has anyone else had the same problem?
UPDATE
Interestingly, from that same directory 'code' If i run a ping on blog.dev I get returned packets and pings. However I do the same on test, I get bunch of help commands?
FURTHER UPDATE
So inside the project 'test' if I run php artisan serve I get a response of Laravel development server started: <http://127.0.0.1:8000> and If I visit the path bingo it works. But that confuses the issue even further for me...?
EVEN FUTHER UPDATES
So, I wish to add this iMac was a previous developers so the home folder is called Adam, I am a seperate user but also an Admin with my own folder sat next to it called 'Dan'but not a 'home' directory as such it is just in the sames 'Users' directory whenever I try to do anything I get errors like: ERROR: Notice: Undefined index: domain in /Users/Adam/.composer/vendor/laravel/valet/cli/valet.php on line 55 That was when trying to spin up laravel share
For some reason laravel's dd() function decided to stop functioning. I have no idea how this happened. I tried composer update already but I'm not sure what else can be going on. The debug key is set to true in the config.
Where should I look to solve this problem? I'm using Laravel 4.2.16
NOTE:
dd() now simply functions as var_dump(), it doesn't prettify it anymore
Solved it. I loaded my vagrant machine with the wrong config and was running hhvm instead of regular php-fpm. Hence xdebug, which handles the pretty dd(), was not being loaded. I reloaded my box with the correct settings (without hhvm and hack) and everything started working again
Is dd the only Laravel helper function that doesn't work? If not then check the contents of vendor/composer/autoload_files.php. The laravel support helpers are loaded here. If the other helper functions are fine you can check the contents of laravel/framework/src/Illuminate/Support/helpers.php to see what's going on - this is where the function is created.
So a while back I decided to redo one of my models in Laravel completely, but I wanted to hold on to the original copy of the file just in case. So I renamed it to something like MyModel (OLD).php and left it there in the models folder next to the new model.
Now that I understand Laravel a bit better, I realize that wasn't a great idea, but in any case everything seemed to work for months. Then today, I made a minor update (modifying a database query) to one of the functions in my new model and suddenly Laravel is trying to load the old copy of my model. I finally moved the old copy out of the models folder and into a backup folder completely outside of my laravel application, but now Laravel throws the error:
include(pathToMyModels/MyModel (OLD).php): failed to open stream: No such file or directory
referring to this section of ClassLoader.php
/**
* Scope isolated include.
*
* Prevents access to $this/self from included files.
*/
function includeFile($file)
{
include $file;
}
I tried undoing the modification to the model, changing the route and controller function name, clearing laravel's cache, clearing the browser cache, using different browsers, but nothing seems to work except to manually include the model's php file before calling the class it contains. What can I do to get Laravel to automatically recognize my model like it does all the others I have?
Try to clear composer cache and then run composer dump-autoload.
composer clear-cache
composer dump-autoload
if you don't want to run commands then try this one, i think it's solve your problem.
goto your laravel_project_folder\vendor\composer
now open the file autoload_classmap.php and autoload_static.php in your text editor
and find your old/backup file name line
and rename with actual filename and correct their path.
now run your project again and check for the error occurance, i think your problem is solved.
i just knew that my laravel using old controller after 1 hour of debuging. what time waste
i tried accepted answer but still persist
i delete the controller and recreate, now works
copy all the code
delete the controller
make http request to that controller (404)
create file same name
paste in
None of out programmers has changed anything to the code, but out of nothing now, when a user tries to login on the backend, we have this error:
Fatal error: Call to a member function children() on a non-object in
/home/r1tech/public_html/app/code/core/Mage/Admin/Model/User.php on
line 437
Any ideas why this is happening?
Not a real Magento problem.
Somehow the files got corrupted. I re-uploaded everything and now it works just fine.
Leaving this for the occasional googler with this issue:
We had this problem today, after we had tested different caching mechanisms for Magento. In the process, the file cache directory was somehow corrupted or otherwise made unusable. If you're not keen on reuploading the entire thing as Beto Frega suggests, you should be able to solve it by removing (or renaming) the var/cache (in the Magento webroot, not the server itself!!) directory and creating a new one, which you then obviously give write permissions to.
This solved the issue for us -- and incidentally also some performance issues in the backend, due to the sheer size of the old cache dir.