Docker Again, Finding Composer Autoload

I think you missed my edit to the previous post. We were cross posting.

Is the nginx.conf in the same folder as the docker-compose?
It should be.

Hi Sam,
Here are the updated files for installing Composer and Auto-loading in Docker. Tested on Ubuntu 22.04.

Just run docker-compose up and browse to localhost for the front end or localhost:8080 for PhpMyAdmin.

sam-final.zip (45.3 KB)

1 Like

I now have the container running with Composer apparently working. Thank you.
The autoloader is being found and if I instantiate a PHPMiler object, it exists.

After testing the content of the zip, I copied the configuration over to the full app. That is installing Composer and PHPMailer correctly, but I’ve now hit another problem, but possibly one for another topic.
It is no longer loading any asset files, there is no CSS and no images showing.
My guess is this is to do with the nginx.conf file. If I revert to my origianl conf I just get a 404. I’m still quite new to using Nginx as opposed to Apache, so I’m not really sure, but my gues is the location block routing everything to index.php. If I view source and click the URL to my CSS, the browser shows the URL in the address bar, but the source I see is still that of the HTML page.
But oddly the request log in the shell show the files giving a 200 response:-

172.23.0.1 - - [11/Feb/2023:13:34:05 +0000] "GET /assets/images/graphic/share.svg HTTP/1.1" 200 7503 "http://127.0.0.1/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/109.0"

This is the nginx.conf:-

http {
    server {
        listen 80 default_server;
        root /app/public_html;

        index index.php index.html index.htm;

        location / {
            try_files $uri $uri/ /index.php?$args;
        }

        location ~ \.php$ {
            fastcgi_pass php:9000;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            include fastcgi_params;     
        }

        rewrite ^/([0-9a-z-/]+)$ /?page=$1 last;
    }
}

events {
    worker_connections 1024;
}

Hi @SamA74 ,

Here is an updated version for css, js and images. Everything works as it should in Firefox. For some reason in Chrome and Opera, the external CSS does not render but works if the CSS is in the page. No idea why yet.

sam-final-2.zip (227.6 KB)

This is odd. When I first put your previous config into the project, I got no CSS or images, with the exception of the Favicon which is PNG format.
Following the link in “view source” changed the URL, but displayed the HTML page.
All the asset requests in the shell gave a 200 response. Reverting to my origianl nginx.conf just gave me 404 on the page.
After altering the volume set up in the docker-compose file from:-

- ./app/public_html:/var/www/html/public_html

to:-

- ./app:/app

I did see some images, Jpeg and Webp ones, but not my SVGs and still no CSS. But now clicking the link in “view source” showed me the CSS source, the same for SVGs.
I noticed in Firefox Inspect it complined the Mime tyoe was wrong for the CSS.

In your latest config, in Firefox it mostly works, I get everything except for my SVG images. But in Chrome and Edge there is still no CSS. But oddly in Chrome Inspect it is showing 200 response for the CSS, as does Firefox for its missing SVGs.
It’s all very confusing.

I got the SVG working now, by giving them their own location block with:-

add_header Content-Type "image/svg+xml";

Surely I don’t have to set content-type headers for every file type?
I’m curious why I didn’t have to jump through these hoops initially.

You should not override the full nginx.conf but rather add the entire server block to a file in /etc/nginx/conf.d in the nginx container.

That way all regular mime types are preserved in the original nginx.conf.

So, only this, nothing else

server {
        listen 80 default_server;
        root /app/public_html;

        index index.php index.html index.htm;

        location / {
            try_files $uri $uri/ /index.php?$args;
        }

        location ~ \.php$ {
            fastcgi_pass php:9000;
            fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
            include fastcgi_params;     
        }

        rewrite ^/([0-9a-z-/]+)$ /?page=$1 last;
    }

(doesn’t have to be indented, I’m just to lazy to remove indentation since I’m on my phone :sweat_smile:)

I have created a file with the above configuration. I wasn’t sure what to call it, so it’s http.conf then I linked via a volume in the nginx image:-

- ./http.conf:/etc/nginx/conf.d/http.conf

What I get is as before, the PHP/HTML functions, but I’ve no assets loading, no images or CSS, except the favicon. The links (to CSS and images) in View source go to the HTML page again.
Console says:-

The stylesheet http://127.0.0.1/assets/css/style.css was not loaded because its MIME type, "text/html", is not "text/css".

What I have been reading suggests that I need to include the files in conf.d in the main nginx.conf but since I’m now not using my custom nginx.conf how would I do that? If indeed I should.

You should not use a custom nginx.conf. You should use the default one that comes with the container.

So How do I get it to use the additional file in /conf.d?
The docs say I need an include for the file in the nginx.conf, is this correct?

Yes, but the default nginx.conf comes with a directive to do just that IIRC.

If that doesn’t work, try /etc/nginx/sites-enabled (e.g. /etc/nginx/sites-enabled/my-site.conf). That’s what we use at work and certainly works.

If you want to see the default config, run

docker run --rm nginx cat /etc/nginx/nginx.conf
1 Like

I see it now. There is an include for mime.types and as you say, an include for any .conf file in /conf.d
But I was getting:-

But again making this change:-

Has 99% fix things for me.
Everthing looks fine in Firefox abd Edge. But in chrome some of my SVGs are not working, while others do. It may be down to the files themselves and Chrome being more fussy about them than other browsers.
But it looks like I’m almost set up, thanks.

1 Like

Hi @SamA74,
Here is the latest version. Everything you were looking for is working. CSS, JS, Images, SVG, Composer, PSR-4 Auto-loading, & Phpmailer.

I was able to finally understand what the problem was with the autoloading. The way it was the docker-compose was overwriting all the files created by the dockerfile so after docker-compose ran it overwrote the vendor directory and all the composer files. You can test it by running just the old dockerfile you had by itself and you will see all the files get installed to the container as they should.

Edit: Found out why css was not rendering in chrome in earlier version. Sloppy html in the index.php. Too many hours in front of the screen. :face_with_diagonal_mouth:

project.zip (85.7 KB)

1 Like

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.