php artisan serve does not serve any assets

please run them

php artisan config:clear
php artisan cache:clear

delete files from public/css and public/js

npm run dev

Ran both commands and deleted the css files. I did not deleted the js files, as this is the only place where they are. CSS are compiled from sass.

After running npm the css files are again available. Unfortunately, the result is the same. Always getting 404 errors for js and css files

Change /Illuminate/Foundation/helpers.php/asset() function as follows:

function asset($path, $secure = null)
{
    return app('url')->asset("public/".$path, $secure);
}

Please don't advise people to alter their /vendor files. They will get overridden during upgrades.

for some reason the php artisan serve is not linking to your public folder, but index.php is working fine I assume?

if you stop your php server you should get no response? im wondering if something else is running at localhost:8000?

should be no need to mess about with the asset helper

@Snapey exactly. Index.php is working, but assets are not. If I stop the server, I’ll get no response. I am not aware of anything else running on port 8000. in fact I recently updated to Laravel 5.6 from 5.4 over 5.5 and it has been working with 5.5. beginning with 5.6 the problem occurred.

@rin4ik @Cronix should I change the asset function just for testing?

there is nothing wrong with the asset helper. as you have seen in the browser source, the link to the asset is fine.

if you hit the url for the asset and get 404 then its not even hitting Laravel at that point

did you setup config correctly?

<VirtualHost *:80>

DocumentRoot "C:/path/here/public"

<Directory "C:/path/here/public">

Options Indexes FollowSymLinks Includes ExecCGI

AllowOverride All

Require all granted

</Directory> </VirtualHost>

Thats for Apache

@rin4ik I am not using Apache, but the php built-in Webserver. Is there also any configuration needed?

@caldicot http://laravel.com/docs/5.6#pretty-urls

Yes, the default htaccess file is in the public folder.

<IfModule mod_rewrite.c>
    <IfModule mod_negotiation.c>
        Options -MultiViews -Indexes
    </IfModule>

    RewriteEngine On

    # Handle Authorization Header
    RewriteCond %{HTTP:Authorization} .
    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    # Redirect Trailing Slashes If Not A Folder...
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_URI} (.+)/$
    RewriteRule ^ %1 [L,R=301]

    # Handle Front Controller...
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ index.php [L]
</IfModule>

I haven't modified this file and at least it has been working with Laravel 5.5 As far as I know this the htaccess file is not going to be loaded by the php built-in webserver? Even when I remove the file from the public folder, the result is the same.

As far as I can tell, the server.php as a workaround.

// This file allows us to emulate Apache's "mod_rewrite" functionality from the
// built-in PHP web server. This provides a convenient way to test a Laravel
// application without having installed a "real" web server software here.
if ($uri !== '/' && file_exists(__DIR__.'/public'.$uri)) {
    return false;
}

Anything wrong with my htaccess file?

everything fine here

I setup a new Laravel 5.6 project from scratch to test if this problem is project related. And actually the problem also occurrs for the new project. I cannot load any asset through the browser/webserver. Could there be anything wrong during the upgrade from Laravel 5.5 to 5.6?

as mentioned

if you hit the url for the asset and get 404 then its not even hitting Laravel at that point

try removing .htaccess altogether and load the asset route in the browser

This should be a GET request to your server and nothing to do with Laravel

@Snapey, thanks for your detailed description - I actually didn't get it the first time :-) I've removed the entire htaccess file from the public folder, started the server again by issuing php -S localhost:8000 -t public command and entering the http://localhost:8000/css/search.css url in the browser. Unfortunately, the result is the same. I am getting a 404: [Mon Mar 26 15:10:27 2018] 127.0.0.1:53589 [404]: /css/search.css - No such file or directory

The point, why I think this is Laravel related, is the following: I started the server in a complete new folder, where only one fresh create text file exists. When opening this file through the browser it is working.

As I said, creating a Laravel project from scratch brings also the http 404.

Maybe this test is not meaningful?

I don't know what user account php -S runs under, I assume its your own so it should not be a matter of permissions - but that was another thought.

when you run this php -S localhost:8000 -t public, I assume you are running it in the parent of public folder?

Right, working directory of cmd is in the root folder of the Laravel project. The public folder is a child of that folder.

I am running this command either under my user (which is admin) or I start cmd explicitly as admin, but the result is the same: always 404.

I am not sure if permissions can be the problem. At least I thought starting as admin would avoid the permissions problem. Is this assumption wrong?

Does nobody have any additional ideas? Anything I could try? It's driving me nuts, that the dev webserver is not working ...

@caldicot you still couldn't solve this issue:(

try check permission to public folder

run in cmd:

chmod 777 public 

@rin4ik Unfortunately not :( Still having the exact same problem @cmtz I am developing on a Windows 10 machine. Could you please tell me, which permissions on Windows are needed. But in fact, I've issued the command as administrator and having the same problem. So, I am not sure if it's a problem with the permissions.

Thanks all of you for your help.

any other ideas?

This would be so much simpler if you used a vm like homestead, which uses the ubuntu os. It makes dev on windows so much easier because you're actually working on a VM that would be closer to your actual live server environment (most likely you aren't going to be hosting your production code on a windows server). It makes it a LOT easier to catch problems too, like windows os isn't case sensitive but linux is, so you wouldn't notice issues in your code running on windows that you would running it on linux.

@caldicot dont know if you still have this problem but I just had the very same symptoms/issues with the built in php webserver - for me the problem was that the path of my project contained a special char (ö) - after I moved the whole project to another folder it worked

thohoe solution worked for me! Thanks!!