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.)
Related
Been scratching my head over this for hours.
I've inherited a large PHP project and it's now my responsibility.
I also admit that I am not very experienced with Symfony.
Looked all over StackOverFlow for help, but still cannot resolve the following issue.
I made a change in \src\Entity\SOMETHING\BLAH.PHP
Now when I run php bin/console make:migration I get the following error:
[Symfony\Component\Debug\Exception\FatalErrorException]
Compile Error: Cannot declare class App\Entity\SOMETHING\BLAH, because the name is already in use
All I changed was the string length of a column.
#ORM\Column(type="string", length=100, nullable=true)
I've tried moving the migration file that defined the table orignally out of the src folder
I've tried clearing the vendor and node_modules folders, and running
npm and composer install.
I've tried cache:clear command
I've searched the code, and the class is only defined once. Any help greatly appreciated.
The issue was that there were two files in the same directory with the same name, however with a different case (BLAH.php and Blah.php). For reasons unknown, the "duplicate" files did not show in any source code editor, nor in any ls commands to the directory, nor in any text searches with grep.
After moving one of the conflicting files, it was noticed when doing an ls that the other file with a different case was there. It was not visible prior to moving the file. After removing the other file and moving the original back, then the code compiled.
In summary: a possible file-system glitch was preventing files with the same name but a different case from being visible.
I was starting some .php files in the /public directory of Laravel, which works, naturally, but it is separated from the standard Laravel system. In fact, Laravel wants you to you routes I know, and if I want to use some Laravel stuff I would think that calling
require_once 'path/to/vendor/autoload.php';
require_once 'path/to/app/Services/Myfile.php';
would let one use that... but for example "use GuzzleHttp", if used in myfile, gets fatal "Uncaught ReflectionException: Class config does not exist" in Container.php of Laravel.
I know there's SHORTINIT in Wordpress though it is kind of a mess of requiring any file that you need and all the files with functions it uses... Is there something similar for Laravel? Or this is never properly used this way to hold php files within /public?
You don't need to use require as composer takes care of loading the library files.
However when you add any new library or make any changes to routes or config files make sure you run the optimize command.
php artisan optimize
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 am getting an error message in my Laravel 5 application:
PHP Fatal error: Cannot redeclare class Illuminate\\Contracts\\Support\\Arrayable in /var/www/.../bootstrap/cache/compiled.php on line 156
This error only occurs on my staging environment and not on my local website. I would love to post more info but I do not have it. Because I do not know where this error is caused.
If I remove the file (cache/compiled.php) everything seems to work fine. But after every deploy the same error occurs. On my localhost everything works fine as well.
My question: does anybody have a clue where to look because I am out of ideas.
Try this way.
At first remove the cache/compiled.php file
then run this command
php artisan clear-compiled
I had the same problem and found the following article, which was very helpful:
https://sentinelstand.com/article/laravel-5-optimization-commands
The only solution that was working for me was manually deleting bootstrap/cache/compiled.php. Switching around the order in which the autoloaders are called in bootstrap/autoload.php did not work for me because I had the same problem the other way round, ie. I had a class in compiled.php that was causing something from autoload.php to be autoloaded before autoload.php ran.
In my case, I am using a combination of PSR4 and manual class mappings in my composer.json file. I'm sure this is part of the problem. (Don't judge me: this app started in Laravel 3, so it's taking time to add namespacing throughout the code base :-).
One reason why things may work differently in different environments is because the artisan optimize command will only generate the bootstrap/cache/compiled.php file if you provide the --force option or if debugging mode is not enabled. So it is likely that you are not getting this file in development because debugging is enabled but are getting this file in staging and/or production because debugging is not enabled.
Ultimately, here's what I have landed on as a solution for production deployments:
artisan config:cache
artisan optimize
rm bootstrap/cache/compiled
Update symlink to point to new version.
This way you still get bootstrap/cache/services.json, which is helpful, whereas artisan clear-compiled removes that file. Also, there will be a very brief period of time where bootstrap/cache/compiled.php will exist, which is why it is important to run these commands before you update the symlink to point your web server at the new version.
It is also worth noting that the compiled.php file that is created by artisan optimize in Laravel 5.1 is no longer generated in Laravel 5.4 because, as Taylor has stated, PHP 7 is much more performant and so the benefit of bundling all the application classes into one file, which is meant to save on disk I/O, is negligble now. Taylor recommends enabling and properly configuring your OPcache instead - you will get far more performance benefits from that.
I experienced the same but eventually found the solution.
I have my own helpers.php files in laravel. Just like the framework ones, I added them as autoloads in my composer.json. A couple of those functions are macros for the Collection (\Illuminate\Support\Collection::macro(...)).
When that helpers.php file is autoloaded, the definition of those macros cause the autoloading of Illuminate\Support\Collection. This in turn uses Illuminate\Contracts\Support\Arrayable.
So basically all of these are already loaded by the time they are defined again in cache/compiled.php. Boom.
Long story short: For me the fix was simply to switch inclusion of the compiled file and the autoloader around.
bootstrap/autoload.php:
$compiledPath = __DIR__.'/cache/compiled.php';
if (file_exists($compiledPath)) {
require $compiledPath;
}
require __DIR__.'/../vendor/autoload.php';
This might not be a viable solution add include code in your compiled file runs right away and refers to helper functions, but I think the chances on that happening should be pretty minimal.
The problem is with the artisan optimize command. If you remove the compiled.php file and then do not run optimize, it should work.
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.