Class autoloading doesn't loads migration classes #56

driesvints · 2013-01-15T16:57:27Z

Autoloading was recently re-introduced to prevent us from having to run composer dump-autoload every time. See this commit.

But it seems this was only done for controllers and models. When I try to run a migration it still gives a Fatal error saying it didn't find the migration class:

PHP Fatal error:  Class 'CreateUsersTable' not found in foo/bar

Running composer dump-autoload fixes the problem.

I've tried adding the migrations folder to the array of folders here in app/start/global:

ClassLoader::register(new ClassLoader(array(

    app_path().'/controllers',
    app_path().'/models',
    app_path().'/database/migrations',

)));

Sadly that doesn't seems to be the solution.

Any suggestions...?

The text was updated successfully, but these errors were encountered:

taylorotwell · 2013-01-15T16:59:17Z

How did you create the migration? Using Artisan? Artisan should dump the autoloads for you when a migration is created.

taylorotwell · 2013-01-15T16:59:29Z

Also is this on a package or on your app?

driesvints · 2013-01-15T17:19:11Z

It's on the app. I'm using a clean Laravel 4 installation.

I created the migration with Artisan, yes. I did use the --env=local flag because otherwise it would try to use the default database config file instead of my development database config file.

driesvints · 2013-01-15T17:23:36Z

Could it perhaps be a permission problem? Should some folders/files be write able in the /vendor folder?

taylorotwell · 2013-01-15T17:27:33Z

Where did it place the migration? In app/database/migrations?

driesvints · 2013-01-15T17:29:44Z

Yep, exactly.

driesvints · 2013-01-15T21:45:19Z

I just installed Laravel 4 at home on my home dev machine and here I don't get the error I had at work. I'll try to reinstall again tomorrow at work to see if I can get it to work there as well.

taylorotwell · 2013-01-15T22:31:33Z

OK. I've never seen this error.

driesvints · 2013-01-16T08:54:23Z

I tried it again by changing some things on the original repository like tweaking permissions and manually removing the Autoload class in vender/composer/autoload_classmap.php and reinstalling the migration but no luck. Here is the problem at hand:

I did: php artisan migrate --env=local

PHP Fatal error:  Class 'CreateUsersTable' not found in /foo/bar/vendor/laravel/framework/src/Illuminate/Database/Migrations/Migrator.php on line 290
<!DOCTYPE html>
<html>

and so on...

I'm trying to install a fresh Laravel installation but it seems that Github is having some issues at the moment (when i run composer.phar install):

No luck either trying to clone it manually:

I'll try again later.

driesvints · 2013-01-16T10:59:28Z

It was a Github issue apparently: https://status.github.com/messages. I can clone the repo now.

I set up a new Laravel 4 installation, followed the steps I've taken previously and again ran into the same problem.

Here are the exact steps I've taken:

Followed the Laravel installation guide on http://four.laravel.com/docs/installation
Set up a virtual host pointed towards the public folder.
Created a local dev environment in start.php with following code:

$env = $app->detectEnvironment(array(

    'local' => array('*.loc'),

));

Set up a dev database in app/config/local/database.php with following code:

return array(

    'connections' => array(

        'mysql' => array(
            'driver'    => 'mysql',
            'host'      => 'localhost',
            'database'  => 'laraveltest',
            'username'  => 'root',
            'password'  => 'root',
            'charset'   => 'utf8',
            'collation' => 'utf8_unicode_ci',
            'prefix'    => '',
        ),

    ),
);

Ran php artisan migrate:install --env=local
Ran php artisan migrate:make create_users_table
Set up the database code in the created migration file like this:

use Illuminate\Database\Migrations\Migration;

class CreateUsersTable extends Migration {

    /**
     * Run the migrations.
     *
     * @return void
     */
    public function up()
    {
        Schema::create('users', function($table)
        {
            $table->increments('id');
        });
    }

    /**
     * Reverse the migrations.
     *
     * @return void
     */
    public function down()
    {
        Schema::drop('users');
    }

}

Ran php artisan migrate --env=local and bumping in the error:

PHP Fatal error:  Class 'CreateUsersTable' not found in /foo/bar/vendor/laravel/framework/src/Illuminate/Database/Migrations/Migrator.php on line 290
<!DOCTYPE html>
<html>

and so on...

That sums up everything. Pretty much stuck now :-/

driesvints · 2013-01-16T11:08:02Z

It's definitely related to my machine because I can get it to work no problems at home, I just have no clue why it doesn't writes the class in the composer Autoload file when it installs the migration.

I've setted permissions to 777 on all files but that doesn't seems to be the problem.

jackmcdade · 2013-01-16T14:51:34Z

Having the same problem.

driesvints · 2013-01-16T15:03:28Z

I've made a temp workaround by manually adding the classname to the composer autoload file. Add the classname in your migration file to this file: vendor/composer/autoload_classmap.php.

'<class name>' => $baseDir . '/app/database/migrations/<migration filename>.php',

Then run php artisan migrate again (perhaps with the --env= param).

thinksaydo · 2013-01-18T21:25:23Z

Same problem here as well. Fresh install. On a Mac running PHP 5.4.x.

thinksaydo · 2013-01-18T21:28:13Z

Running composer dump-autoload fixes the issue... I noticed /vendor/composer/autoload_classmap.php was out of date. So, apparently this command is still needed for some setups. Might be a permissions issue.

bpierre · 2013-01-20T21:39:56Z

Same problem, fixed with composer dump-autoload. Maybe the migrations documentation could be updated to specify that migrate:make does not only create a file, it also updates vendor/composer/autoload_classmap.php.

@taylorotwell:

Artisan should dump the autoloads for you when a migration is created.

OK, but the vendor directory is ignored by git, how to share the updates? Should I add vendor to the project repository, or do you recommend to run composer dump-autoload each time a new migration class has been added by someone else?

I am not familiar with Composer, but it seems awkward to manually handle the class loading system, and to rely on a modified vendor directory :-/

taylorotwell · 2013-01-24T05:17:34Z

How do you guys have Composer installed on your systems? Using a local composer.phar in the project directory or do you have the composer file in your bin?

In other words, what exact command do you type on the terminal to run Composer?

jackmcdade · 2013-01-24T05:43:52Z

I've tried it both ways, using a composer.phar file in my bin, and in the local project.

% php artisan migrate

thinksaydo · 2013-01-24T12:48:39Z

I have composer.phar in my bin and access it via an alias as "composer" - I'm running latest version of Composer.

driesvints · 2013-01-24T13:08:12Z

I have composer.phar installed in /usr/local/bin (working on OS X 10.8).

I run composer with: $ composer.phar install
I run migrations with: $ php artisan migrate --env=local

taylorotwell · 2013-01-25T04:52:36Z

I've still never come across this particular error, but will put a note in the documentation to try a composer update if your migration can't be found.

gerob · 2013-01-26T01:19:38Z

I have the same issue with migrations and local environments. I am on Windows 7 with Composer installed globally. I was trying to use the migrations from a workbench where I am building a simple blog. I had to manually add the paths to the workbench to get the migrations to run.

Adding this here for anyone else that has this issue. This is the path Artisan created the migrations at for me with the workbench. I am using Sentry for Users and Admin functions and the migrations for that ran fine with the mapping being added to autoload_classmap.php.

'CreatePostsTable' => $baseDir . '/workbench/bit-chisel/blog/src/migrations/2013_01_25_023930_create_posts_table.php',
'CreateCommentsTable' => $baseDir . '/workbench/bit-chisel/blog/src/migrations/2013_01_25_032838_create_comments_table.php',

robertovg · 2013-02-03T20:10:42Z

Same error on ubuntu 12.10, @driesvints thanks for the workarround! I haven't this error with windows 8.

howlowck · 2013-03-12T02:59:23Z

Have the same error on Mac with php5.4.x.

comanche · 2013-03-26T16:49:29Z

I had the same problem on Ubuntu 12.10. I previously had composer.phar in the parent directory of my Laravel 4 project folder. I watched Composer's autoload_classmap.php as I created a migration. The map was not updated eventhough the migration php code was generated. No error messages. I Moved local composer.phar into the base directory of Laravel 4 project. Created another migration. Same message in the shell. However the map is updated. Migration and rollback worked properly.

fbastage · 2013-05-01T14:59:39Z

I'm having the same issue on a fresh install. Just installed composer.phar and laravel 4 yesterday as per http://four.laravel.com/ , set up secret key.

Following tutorial by Andrew Perkins at http://www.youtube.com/watch?v=lEZ8cnVGVZE&list=PL09BB956FCFB5C5FD&index=1 (tutorial is based on Laravel 3, I'm making appropriate adjustments).

Created 2nd migration in this tutorial (add_authors).

The migration applies properly and populates db with a few rows in a recently created 'authors' table. !!! So at this point the autoloader and command line 'php artisan migrate' work properly. !!!
When I try 'php artisan migrate:rollback', I get an error that the class does not exist. The error is in the resolve() function. >> see vendor/laravel/framework/src/Illuminate/Database/Migrations/Migrator.php on line 303

return new $class;

Not knowing enough about Laravel at this point, I don't know how to resolve this, even as a short-term workaround, other than perhaps require_once() in the the resolve() routine that tries to instantiate the class, if !class_exists().

Any suggestions would be appreciated.

fbastage · 2013-05-01T15:09:23Z

on the advice of a coworker, I ran 'composer.phar update' which resolved my issue. I guess this issue has been fixed in the framework and updating it worked well.

jrahmy · 2013-05-03T18:40:57Z

@fbastage In my experience, if you don't run artisan dump-autoload, you will be able to migrate the database but not roll-back. Dumping the autoload file (also done on composer update) fixes rolling back.

warrenca · 2013-05-06T09:48:37Z

PHP: v5.4.4
OSX: 10.7.5

I was using Way/Generators and successfully run the migration, but when running php artisan migrate:rollback, I got the following error.

$ php artisan migrate:rollback
{"error":{"type":"Symfony\\Component\\Debug\\Exception\\FatalErrorException","message":"Class 'CreateFeedsTable' not found","file":"\/Volumes\/Data HD\/User\/Sites\/project\/vendor\/laravel\/framework\/src\/Illuminate\/Database\/Migrations\/Migrator.php","line":301}}

so what I did is to run the composer.phar update like most of the people here and it solves my problem

$ composer.phar update
Loading composer repositories with package information
Updating dependencies (including require-dev)
  - Updating symfony/console dev-master (v2.3.0- => 2c29086)
    Checking out 2c29086a53686d9dcb11353b9c15f946808ebe04

Writing lock file
Generating autoload files
Generating optimized class loader...
Compiling common classes...

$ php artisan migrate:rollback 
Rolled back: 2013_05_06_091607_create_feeds_table

taylorotwell · 2013-05-06T12:39:32Z

composer dump-autoload

rrosiek · 2013-05-13T01:56:25Z

I also was able to migrate a fresh database properly, but could not rollback or refresh. I'm using psr-0 style namespacing and folder organization. I had completely cutout my classmap attributes in composer.json and moved everything except the database folder. Putting it back for only the database items and running composer dump-autoload worked. So what I ended up with (which still may not be best practice):

"autoload": {
    "psr-0": {
        "MyApp": "app/src"
    },
    "classmap": [
        "app/database/migrations",
        "app/database/seeds"
    ]
},

Seems really obvious after looking at it now...I suppose I could have namespaced my database migrations, but seems pretty unnecessary.

taylorotwell · 2013-05-13T02:46:13Z

Yeah dump-autoload is required before rolling back I believe.

On May 12, 2013, at 8:56 PM, phishman9 notifications@github.com wrote:

I also was able to migrate a fresh database properly, but could not rollback or refresh. I'm using psr-0 style namespacing and folder organization. I had completely cutout my classmap attributes in composer.json and moved everything except the database folder. Putting it back for only the database items and running composer dump-autoload worked. So what I ended up with (which still may not be best practice):

"autoload": {
"psr-0": {
"MyApp": "app/src"
},
"classmap": [
"app/database/migrations",
"app/database/seeds"
]
},
Seems really obvious after looking at it now...I suppose I could have namespaced my database migrations, but seems pretty unnecessary.

—
Reply to this email directly or view it on GitHub.

ghost · 2013-05-26T14:36:22Z

composer dump-autoload fixed my problem!

ghost · 2013-05-26T15:05:05Z

Hi ,
I think this problem is caused by the composer classmap.
It seems when i run migrate:create command, it should update the composer classmap, but the user i use doesn't have the privilege to update the composer classmap,but it desn't display the error.
So this problem can be fixed by sudo composer dump-autoload or by sudo migrate:create .
I think we need to update migrate:create command. When the command didn't updated the classmap ,it should display error,not show successful infomation as usual.

siaobukol · 2013-06-10T23:32:29Z

i have the same problem
in my case i just updated my composer "composer update" and it works perfectly

fharbe · 2013-08-15T08:15:58Z

I am having a similar issue right now ...

I deleted one migration class and now I can't run artisan migrate:refresh or artisan migrate:reset anymore..

Any ideas?

Comment here: #2105

desertcrystal · 2014-05-30T18:15:46Z

Same issue with same solution:
composer dump-autoload

timzwier · 2014-06-05T07:18:53Z

Im getting the same error, but composer dump-autoload does not solve the issue. Running all commands with and without sudo, I can't seem to get the migration to work.

lionelgaillard · 2014-08-23T11:47:06Z

Hi,

Concerning workbench's dumpings, one problem is than it fail silently.
Try to cd inside your package inside the workbench, then run composer dump-autoload from there.

It happens several times that my package's composer.json was not valid because I left one extra comma and the error was never reported otherwise.

Hope it could help.

gnufred · 2015-02-05T14:33:22Z

Just had this problem myself with Laravel 4.1 on Ubuntu 14.04 LTS.
Here is how I fixed it

cd /home/user/projects/laravel_site/
curl -sS https://getcomposer.org/installer | php
php composer.phar dump-autoload

php artisan dump-autoload did not work for me.

taylorotwell closed this as completed Jan 25, 2013

laravel locked and limited conversation to collaborators Feb 5, 2015

Class autoloading doesn't loads migration classes #56

Class autoloading doesn't loads migration classes #56

Comments

driesvints commented Jan 15, 2013

taylorotwell commented Jan 15, 2013

taylorotwell commented Jan 15, 2013

driesvints commented Jan 15, 2013

driesvints commented Jan 15, 2013

taylorotwell commented Jan 15, 2013

driesvints commented Jan 15, 2013

driesvints commented Jan 15, 2013

taylorotwell commented Jan 15, 2013

driesvints commented Jan 16, 2013

driesvints commented Jan 16, 2013

driesvints commented Jan 16, 2013

jackmcdade commented Jan 16, 2013

driesvints commented Jan 16, 2013

thinksaydo commented Jan 18, 2013

thinksaydo commented Jan 18, 2013

bpierre commented Jan 20, 2013

taylorotwell commented Jan 24, 2013

jackmcdade commented Jan 24, 2013

thinksaydo commented Jan 24, 2013

driesvints commented Jan 24, 2013

taylorotwell commented Jan 25, 2013

gerob commented Jan 26, 2013

robertovg commented Feb 3, 2013

howlowck commented Mar 12, 2013

comanche commented Mar 26, 2013

fbastage commented May 1, 2013

fbastage commented May 1, 2013

jrahmy commented May 3, 2013

warrenca commented May 6, 2013

taylorotwell commented May 6, 2013

rrosiek commented May 13, 2013

taylorotwell commented May 13, 2013

ghost commented May 26, 2013

ghost commented May 26, 2013

siaobukol commented Jun 10, 2013

fharbe commented Aug 15, 2013

desertcrystal commented May 30, 2014

timzwier commented Jun 5, 2014

lionelgaillard commented Aug 23, 2014

gnufred commented Feb 5, 2015