404 Non-PHP Assets Frustration

1

I’m posting this here 1st before hitting the Nginx forums, as per the subject I’m as frustrated as a pyro-maniac in a petrified forest.

I have the default sample app running locally and on a development server - not an issue as it works as advertised. I then take the existing UI controller from the current project I’m working on and integrate it into the framework. I’m using the ‘Smarty-View’ view lib (mathmarques/smarty-view) to implement the front end gui w the Slim framework. I extend the UI class w the Smarty implementation, construct and configure the class. It calls the method exposed in the route - no issues, everything working to a tee. When I fetch the template and render it, it’s a plethora of 404 messages (logs, debugger, etal) for any/all css/js/img type assets. The rendered page is all there with exception of the styling, etc.

I’ve wiggled the nginx web server configs back n forth to try and shake out the bugz to no avail - the index page is doing what it’s supposed to be doing (to my knowledge), as I can see in the nginx logs that there’s a request for the “/” index.php page (status=200), and the php-fpm logs indicate access with the request uri listed (after nginx did it’s magic) and a slew of 404’s barking about the file(s) not being present (which they are). I {ctrl} {u} the page to view the rendered source, and it looks EXACTLY like it should. The links for the content in question are there, and when I click on any of them the reply from the web server is still 404 - the google fonts and web content are not affected. I’m seriously scratching my head at this juncture, but I wouldn’t be at all surprised if I’ve missed something, glazed over a specific detail or similar.

I didn’t want this to be so verbose, but at the same time I didn’t want to appear vague about what’s taking place and figured it was time to get another set of eyeballs involved (if necessary).

Suggestions, ideas… constructive criticism? All greatly welcomed and encouraged - and thanx so much in advance for your time and looking this over! I’ll post any relevant files, log dumps etc upon request (didn’t want to clutter this initial post). Apologies if I’ve wasted anyone’s bandwidth with this issue…

2

so problem is with your static files/assets

I would check permissions on your files first

otherwise I believe problem will be in your nginx configuration, so without provided configuration and folders structure it is hard to guess…

3

Thanx @jDolba for the quick reply…

That’s where I was going next as it were, I’m just not as familiar with the Slim framework and wanted to get some quick input and/or direction (such as yours) before continuing on. If’n I can’t get to the bottom of this, I’ll post some configs and log file output.

Again, thanx in advance!

4

This ended up being an interesting combination of nginx (cache), virtualbox & composer. Of course a little conversation (workflow, assignments) with others cleared things up regarding chain of command and responsibilities moving forward… but I digress {grinning}

Regarding virtualbox, it seems there is a very uncommon issue concerning nginx. In this case the ‘sendfile’ configuration variable setting - it needed to be set to ‘off’ on any virtualbox in play and ‘on’ in production (or elsewhere), and the nginx cache required clearing (/var/cache/nginx). Something to do with not having the correct css cached (in this case almost nothing). I’m putting this here in the event any unfortunate dev stumbles upon this and it bails them out of a really confusing and a rather time consuming situation. A web search of ‘nginx’ ‘virtualbox’ ‘sendfile’ would probably turn up the article I read concerning this (apologies, can’t find the url)…

Oh, and again a big thanx in advance for jumping in @jDolba - it does not go unnoticed…

\m/