The dump-autoload command should have said something like "Generating optimized class loader" which would update the files located at vendor\composer... Since it did not I'd say it is not working properly... you should be able to run the command even if you didn't install Laravel via composer. (edit: provided the artisan file exists of course)

You might want to run the dump-autoload command with the extra debug to see what it is failing on.

-v is 1 for normal output -vv is 2 for more verbose output -vvv is 3 for debug

Could be permissions to write files, or something.

You might check the vendor\composer folder in the file named autoload_classmap.php, I'm assuming one was downloaded with your production code.

I have the following in there for my HomeController.php that is in the default Laravel install.

 'HomeController' => $baseDir . '/app/controllers/HomeController.php',

Hope that helps

Thanks for the reply.

After further analysis, I figured out that the error is that the Controllers that were referencing a model::method was choking and catching on the ModelNotFoundException. I created two additional 404 files and see which one was loaded. The one with the ModelNotFoundException is loading on Controller based pages where it is referencing model::method.

So, you are probably correct about the dump-autoload. I'll look further into seeing how I can run that properly.

File permissions are correct. I have chmod 777 storage/* folders.

Thanks for the suggestion to check out the vendor\composer folder. I'll look at that more closely.

I apologize for my noob issue as I am coming from using CodeIgnitor, Zend, and recently ExpressionEngine. So, getting used to yet another MVC framework is not without its learning curve.

Also, you might make sure you have a composer.json since you didn't use composer. I think the dump-autoload will pull the autoload classmap paths and psr paths from it.

No apologies needed, I totally understand the learning curve. Get ready for more changes with Laravel 5 which is slated for November. Laracasts.com has a few preview videos if your curious about version 5.

I do have composer installed, but was missing the composer.json file. I created it and put it in the same directory as the composer.phar file, which is in /usr/bin. When I run composer dump-autoload in the /vendors/composer directory, I get the following error message....

Composer could not find a composer.json file in /Users/elee To initialize a project, please create a composer.json file as described in the http://getcomposer.org/ "Getting Started" section

So, I copied the composer.json from /usr/bin to the /vendors/composer directory, and I get the following message:

Generating autoload files

But still receive the 404 error message for missing model::method in the controller based pages.

I do see the following in the autoload_classmap.php file.

'HomeController' => $baseDir . '/app/controllers/HomeController.php', 'Question' => $baseDir . '/app/models/Question.php',

Question is the Model that is used in the HomeController.

Still not seeing the Model file.

I tried restarting apache as well, didn't make a difference.

Oh boy, new version of a totally new Framework to me. :)

The composer.json normally goes in the project folder. I'm not sure of any side effects of it being in the vendors/composer folder.

If my project folder is \Code\test-project then composer.json would be in that folder.

A basic folder/file list

Code\test-project\app
Code\test-project\bootstrap
Code\test-project\public
Code\test-project\vendor
Code\test-project\artisan
Code\test-project\composer.json

The in the Code\test-project you run the 'php artisan dump-autoload'

The vendor/composer folder is where artisan writes its generated files.

Did you set the App to debug mode, it would or should give you better error messages (app\config\app.php, first array value in my config)

You might make a test route and see if you can access the model there. That would eliminate any controller reference issues.

in routes.php

Route::get('/', function()
{

$data = Question::where('id', '=', 1)->get();

dd($data);

});

It also might be a good idea to just create a new Laravel install and move the production files in to it.

Thanks for the reply.

There was no composer.json file in the project root. So, I found the one from the Laravel masters branch at github and downloaded it in my vendors/composer directory.

I was able to get the composer dump-autoload to work and the autoload_classmap.php file was updated. So, the controllers and models are referenced in it.

In terms of running the artisan command line, my artisan file in the /start directory is empty except for the following comment:

/* |--------------------------------------------------------------------------

I have edited my Controller to remove the Model::Method call and the controller page loads just fine, so the issue is with the model files. While they are in the autoload_classmap.php file, they are not being load automatically.

I hate to use App::bind or add each model into the routes.php file.

I don't know what creating a new install of Laravel will do since I already have all the files there including all the vendor files. But I may give it a shot since I am running out of options. I need to have the model files loading correctly asap to proceed with this project.

Humm,

You might try adding a namespace to the model, namespace App\Models;

Then try referencing the model with the full namespace App\Models\Question:where(...

You might also try creating a new test Model file and see if you can get it to connect, maybe there is something off in the model file.

You might also check the log file, in the storage\log\laravel.log file and see if there is more info.

You can just download the github master and unzip then run composer update to set up a new laravel install, http://laravel.com/docs/4.2/installation

Going out for a bit, hope that helps

Thanks for the reply.

I was able to create a new project and overwrote the files from production server. Got a slew of ServiceProvider errors with custom providers programmed by previous programmer when I tried loading the web site via browser and running the composer dump-autoload. There are also a bunch of other vendor directories in the production server than in the default install of Lavarel.

I went back to using the production set of files and the site loads again except for the controller pages that call a model. Back to square one.

Tried using the full namespace and got a not found error.

If I could just figure out how to use old school method of manually instantiating the model in the controllers bypassing eloquent, I would be good I think, hack work-around, I know.

I figured one problem may be is that I am lacking files in the root directory above /app directory, that may be part of the problem, try to get those files and run update and then dump-autoload and that may get me going.

I just found out that the site on the remote server where I downloaded the files from on Monday is also experiencing the same behavior, and unfortunately, the server is a Windows machine and does not have SSH and the Network Admin is not allowing remote desktop.

I have read somewhere you can run artisan through the web browser. Is that true?

But I don't think you can run composer through the web browser unless I use exec() method in a PHP Script.

This freelance project is looking more and more challenging as I delve into it. :)

Ugh, Windows hosting... so many caveats to deal with

There are not a lot of files in the root path on a normal Laravel install that would affect the including of a model file.

Here some nice info on Artisan I have bookmarked... http://code.tutsplus.com/tutorials/your-one-stop-guide-to-laravel-commands--net-30349

You should be able to do something like in a route closure :

 $output = Artisan::call('dump-autoload');
 dd($output);

Though this might break things, and you would need the web user to have write permissions to the composer folder. I'd make a full backup before trying something like this on production.

I've not seen composer ran via a webpage before so I'm not sure.

Taking over a existing project can be a challenge.

Not sure what other options to offer, its kind of hard with out seeing the structure and code.

Thanks again for your kind support.

Well, after a few more adventurous hours, I was able to cleanly install Laravel 4.2. Fixed some issues like custom classes that needed to be added in the composer.json file and the globals.php file.

Now, I can run composer and artisan commands to my hearts content.While dump-autoload does seem to do its job with updating the autoload_classmap.php file. As you can see with the following snippet:

'Question' => $baseDir . '/app/models/Question.php', 'HomeController' => $baseDir . '/app/controllers/HomeController.php',

Models still not being auto-loaded. So, back to square one.

QUESTION: Is there something with Eloquent that I need to configure further since the models are extending the Eloquent class?

I did read the Database help docs, including Eloquent.

I think I may have found the problem. In the databases.php config file, the fetch value is set for PDO. I did have to upgrade my PHP to 5.4 to work with Laravel 4.2. In doing that, while I think I compiled everything correctly, PDO seems to be misconfigured.

I will try to fix that and see if that fixes the issue.

I did do some more testing, and it is actually loading the model file, and I put some dummy variables in the method being called, and it returned the value. So, seems to be the fetch configuration, may be.

Let you know...hopefully, my wabble around with this framework has not been annoying.

But doesn't explain how the Windows production server stopped working. It was working fine and then broke, and I did not replace or delete files on the server, just downloaded. It seems that Laravel sporadically loses its mind and you have to run the dump-autoload commands often.

Ended up being a combo of the PDO driver and also data issue. Missing data that blew up the queries. I need to add some error checking to make sure that alternate text appears if no records are returned in the result set.

Sorry again for all the confusion.

No problem, glad you figured it out. :)