So apparently now I get this weird error when I want to migrate my database
{"error":{"type":"Symfony\\Component\\Debug\\Exception\\FatalErrorException","message":"Class '' not found","file":"C:\\xampp\\htdocs\\l4crm\\vendor\\laravel\\framework\\src\\Illuminate\\Database\\Migrations\\Migrator.php","line":301}}[Finished in 1.3s]
Everything used to work of course and it doesn't matter which files I try to migrate (I tried only migrating one table, then another, they all give the same error)
Any ideas? I have been staring myself blind at this for over an hour now.
Also "composer dump-autoload" does not do the trick.
My composer.json autoloads the migrations also.
I had the same problem, I searched the internet and I found this solution that you should update your auto-generated classmap (aka autoload) with this composer command:
php composer.phar update
or
composer update
check this link : I found the solution here
I appear to have solved the problem.
For easiness sake to determine the order of migrations I had renamed the migration files to something like
1_create_users_table.php
2_create_..._table.php
3_create_..._table.php
and so on. Apparently this gave me the error, it really had to stay in the "yyyy_mm_dd_hhmmss_create_xxx_table.php" format.
if composer dump-autoload doesn't work, check your class name in the migration file. The className should be the same than the file name without the date
I had the same problem.
For me, composer update doesn't work (in other situations as well) with Windows for weird reasons.
But,
composer dump-autoload
works.
In my case, i had deleted a migration in source files but i didn't on "migrations" table on the database.
Delete the row and refresh migrations and do a "composer dump-autoload -o"
Related
I recently inherited a project based on the laravel framework, which after I have set up, installed all requirements by composer and run php artisan migrations on, will not run via php artisan serve.
When I researched possible causes for this, I came across the following on SO:
laravel5: chdir(): No such file or directory (errno 2)
Using artisan serve after changing the public folder name
When I follow the suggested solution in the second one of adding the lines
'''
$app = new Illuminate\Foundation\Application(
realpath(DIR . '/../')
);
'''
to bootstrap/app.php I get the same exact error.
Is there a configuration file somewhere I need to update? Most of the suggested solutions I've found like changing files under vendor seem to be rather hacky? I'm really stuck on this and any help would be greatly appreciated - thanks!
check the configuration of your Homestead.yalm folder, there you can specity where your project is in the folders->map section.
It may the error from composer so try
Composer dump-autoload -o
I know there is bunch of answer out there and none of them solved my problem. I am giving a try again in 2016 may be some one can help.
php artisan make:migration createxxxtable
don't show any error and it don't create the file
neither of these function output anything too.
php artisan list
php artisan help migrate
Its not new project. I had been working on this project earlier and it was working fine. Created bunch of migration.
I tried deleting everying inside vendor and do composer install and composer update still no luck.
I did tried command like dump-autoload , optimize , clear-compiled etc. too
Thanks
Ok found the solution. I don't know whats the reason. But it was because I was using url() helper in a custom config file i created in config folder. The config file and value of url and others works fine all across the website but it just break artisan command. I don't know why.
Removing that url() helper from my custom config file solved the problem.
Normally when this issue arises it's due to an error in your code. Check for these coporates
Could be a typo in your .env file
Could be a syntax error in your .env
Entering in wrong configuration(syntax error) in your config folder
can you please try php artisan does that open up the artisan commands?
If these doesn't show anything then check your path to project in console.
First of all I have just begun to tinker with Laravel 5 and php artisan, so don't judge to harsh please ;)
To get rid of ./public/index.php in the website path I did the following:
moved all the files in root/page_local/ folder;
moved files from public folder to root/page/;
modified the root/page_local/index.php file accordingly.
So the laravel works as it should now, but php-artisan is not. Every command that I try to run returns the same error:
[BadMethodCallException]
Method patter does not exist.
But I remember creating a Controller before and it worked, I tried multiple functions (--version, list, create::controller).
Even when I run composer update it errors when it tries to run php artisan clear-compiled.
I still managed to update the composer by running composer update --no-scripts
Please help me out on this one because I couldn't find any information regarding this issue on Laravel website and google. If you will need me to provide any of my code, let me know what you need and I will do so.
Thanks in advance.
Search your code for patter string, my guess is that you have a typo somewhere and the method is called pattern so use that instead. There is no patter method anywhere in Laravel code.
I'm running Laravel 4 in a local environment, and for some reason I cannot run php artisan migrate or php artisan db:seed without encountering the following error:
[BadMethodCallException]
Call to undefined method Illuminate\Database\Query\Builder::up()
I'm still relatively new to the framework, but I have tried all of the following to no avail:
composer self-update & full re-install of vendor folder
dump-autoload
manually verified all autoloaded classes are mapped correctly and no incorrect dependencies exist
re-installed migrations table
I used php artisan migrate:make products --table=m_products --create to generate the boilerplate, but in case you would like to see:
Migration: http://pastebin.com/931rivia (two custom migrations, pasted together for convenience)
Seeds: http://pastebin.com/zZMgi8K9 (both essentially the same, so only pasted one)
Edit: Just a note, I have made sure that there is no other class anywhere (in the namespace or otherwise) named "Users," "Products," or "Categories." Models & controllers all have different naming conventions so I'm pretty sure no references are being overwritten...
Does anyone have any clue what might be going on? Thank you!
To anyone else who may be having this issue, I did manage to find a resolution:
1) CLI logs are located in /app/storage/logs/* so chances are the stack trace there will help you identify any issues
2) The Migrator class ends up resolving the files in /app/database/migrations based on their NAME and NOT by using the ReflectionClass or otherwise to analyze the actual include.
Note: This is where the error crept in--all the definitions were correct, but the file was accidentally renamed to: SOME_DATE_category.php INSTEAD OF SOME_DATE_categories.php, and thus the Migrator was trying to call runUp() on Category which is in fact a model.
If anyone else comes across this in the future, look at the names of the files in your migrations folder and make sure they don't contain any strings which reference other classes. (or else just make sure not to modify them from the initial artisan migrate:create command.)
I can easily run the artisan migrate etc, but when i try to roll it back, with migration:rollback i keep getting this error,
c:\xampp\htdocs\laravel>php artisan migrate:rollback
{"error":{"type":"Symfony\\Component\\Debug\\Exception\\FatalErrorException","message":"Class 'CreateCodesnippetsTable' not found","file":"C:\\xampp\\htdocs\\laravel\\vendor\\laravel\\framework\\src\\Illum
inate\\Database\\Migrations\\Migrator.php","line":301}}
Is this a bug? or how should i debug this?
Maybe you've already solved this issue. But I'm noticing that for some reason a rollback often requires you to run composer dumpautoload first. Even if your migration works.
Having just wrestled with this problem for several days, I think I can now provide the definitive answer to solving this problem. Yeah, big call I know, but bear with me.
The first port of call if you encounter this problem is to run composer dump-autoload. This should result in an updated version of the file vendor/composer/autoload_classmap.php.
If autoload_classmap.php doesn't get updated then you may have a permissions problem, in which case you could try sudo composer dump-autoload.
However, if autoload_classmap.php does get updated, check that it contains an entry for your migration class (in this case CreateCodesnippetsTable). If there is no entry for this class then you should check your composer.json file and make sure the app/database/migrations folder is included in the autoload section, eg:
"autoload": {
"classmap": [
"app/controllers",
"app/models",
"app/database/migrations"
]
},
This last bit is what screwed things up for me. In a misguided attempt at optimising things I pulled as much as I could out of my composer.json file, naively thinking this would only affect web requests. It turns out this affected Artisan as well, so putting this line back in and running composer dump-autoload fixed the problem for me.
Finally, if all that fails, then maybe there's a bug in one of the supporting libraries that is causing the problem, in which case you can try updating using composer update or some variation thereof. However, I suspect that this will rarely be the true cause of the problem.
If you are in windows, simply use composer in your terminal/command line utility and do the following:
composer dump-autoload
Hope it helps!
From what I can see I am guessing you have changed the class name manually.
In the error you have the class name CreateCodesnippetsTable but in the migration file you provided (pastebin), the class name is CreateCodeSnippetsTable (notice the S in Snippets, I guess that is what you changed manually).
If you check the migrations table in your database you will see records for each migration. When you create the migration it will be saved in the database with that name and the rollback method tries to read the file with the name provided in the database, in the case when you change it manually laravel can't find the class and you get the error.
To fix this you can undo the changes and try to rollback or manually edit the migration row in your database to include the correct class name.
Hope this helps.
It seems to me there are no single solution of this error. I have tried many suggestion but at last this one works in my end.
COMPOSER=composer.json composer dump-autoload
I fixed it by running
composer.phar update
download the composer.phar file from laravel site and bring the composer.phar file to the root directory of laravel folder,
then from terminal come to the root directory of laravel and run the composer.phar update or simply run php artisan dump-autoload.
i faced the same problem and figure out the problem
I've created a migration for adding new column date in PatientReasonOfVisits table
i used laravel generators
when i create the migration the class name was
class AddDateToPatientReasonOfVisitsTable
sure after creating a new migration file u need to run composer dump-autoload to ensure the file is listed in class map file
the file name was
2014_09_02_214134_add_date_to_patientreasonofvisitstable.php
the migration done successfully
and a new record has been added into migration table.
in migration column the file name is used
when i rollback the migration
i got the class not found exception what class is not found
this one
AddDateToPatientreasonofvisitsTable
note : the difference between classes names
why and how i solved this problem
i guess when u rollback the class name resolved using the migration file name which in migration table
the capital and small letters is decided by underscores "_" in file name
so after renaming the migration file to
2014_09_02_214134_add_date_to_patient_reason_of_visits_table.php
and sure run composer dump-autoload after renaming the file
the class name resolved correctly with no exception
I simply dropped the migrations table then ran php artisan migrate:refresh
Then the migrations were all able to execute, not sure if that's the best method, but it worked for me.
I'm running Laravel 5.