I followed this tutorial: https://gist.github.com/nicwortel/0c938aa77c5bd4fde064
I've added the following line in my composer.json, but it's not asking me to upgrade my directory structure. What's going wrong? (The script is present in my vendor directory)
"post-update-cmd": [
"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::defineDirectoryStructure",
]
I runned php composer.phar update, but composer didn't ask me to update my dir structure.
This is NOT a pretty solution, but it got the job done.
I checked if the script was actually called by Composer by putting a little print statement in the function. The function was indeed called. So I knew the question didn't popped up because the if statement returned false. So I simply deleted the if statement, so the function executed anyways. Not pretty indeed, but it worked.
Related
I upgraded Codeception to v4 (according to THIS) and then Symfony to v5 (according to THIS). Now, when I try to run tests I get an error about missing test file:
root#blabla: vendor/bin/codecept run
In GroupManager.php line 129:
GroupManager: File or directory /var/www/html/tests/unit/SomeFileCest.php does not exist
This file does NOT exist in current branch. It exists in another branch of the project, but current should not know anything about this file!
This problem happens no matter which branch I switch to. So somehow Codeception remembers, that one branch has additional test and demands that test in other branches. Looks like some sort of cache.
If I switch to the branch WITH the missing file, everything looks OK (I do get an error, but because of the old framework expected).
Error appears if I do vendor/bin/codecept run or vendor/bin/codecept run tests/functional for example (note that the missing test is a unit test).
I tried deleting /var and /vendor and running composer install/update. I also tried removing the branch completely and pulling from remote, but no joy.
Anybody has any idea why this would happen and how to fix this?
EDIT:
After some simple testing it looks like it's related to old references in tests/_support/failed (as #Naktibalda mentioned in his/her comment).
I still don't fully understand what happened, but this can be fixed by running:
vendor/bin/codecept clean
From Codeception help:
clean Recursively cleans log and generated code
I will try to investigate further to understand why this happens, but for now this is what I have.
I hope this helps someone avoid the frustrations I went through ;)
For my case we were using paracept, to run stuff in parallel. This generated group files in /tests/_data
Once I removed the group files in this folder my test suite ran normally.
Worth noting that codecept clean doesn't clear this _data folder.
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.
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"
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.