[Support Request]: Unable to Load CSS/Maps #2561

New Issue

OVERLORD · 2026-02-05T04:30:42+03:00

OVERLORD commented

2026-02-05 04:30:42 +03:00

Originally created by @hunoz on GitHub (Jan 8, 2022).

Attempted Debugging

I have read the debugging page

Searched GitHub Issues

I have searched GitHub for the issue.

Describe the Scenario

When loading the main webpage, I am unable to properly load it. Currently, there are large icons that act as links, but no page loads properly.

When using Safari, it states that it cannot load styles.css or print-styles.css because "non CSS MIME types are not allowed in strict mode." I manually navigate to https://url/dist/style.css and it loads fine.

When using Chrome, I get 404 errors for print-styles.css.map, app.js.map, and styles.css.map. I do not have any of these files in my dist/ directory. I have verified I pulled from release branch per https://www.bookstackapp.com/docs/admin/installation/#manual.

Exact BookStack Version

Unknown, however just pulled from release today on 2022-01-08

Log Content

No response

PHP Version

7.4

Hosting Environment

CentOS 8 LXC container, NGINX redirects 80 to 443.

Originally created by @hunoz on GitHub (Jan 8, 2022). ### Attempted Debugging - [X] I have read the debugging page ### Searched GitHub Issues - [X] I have searched GitHub for the issue. ### Describe the Scenario When loading the main webpage, I am unable to properly load it. Currently, there are large icons that act as links, but no page loads properly. When using Safari, it states that it cannot load styles.css or print-styles.css because "non CSS MIME types are not allowed in strict mode." I manually navigate to https://url/dist/style.css and it loads fine. When using Chrome, I get 404 errors for print-styles.css.map, app.js.map, and styles.css.map. I do not have any of these files in my dist/ directory. I have verified I pulled from release branch per https://www.bookstackapp.com/docs/admin/installation/#manual. ### Exact BookStack Version Unknown, however just pulled from release today on 2022-01-08 ### Log Content _No response_ ### PHP Version 7.4 ### Hosting Environment CentOS 8 LXC container, NGINX redirects 80 to 443.

OVERLORD added the 🐕 Support label 2026-02-05 04:30:42 +03:00

OVERLORD closed this issue

2026-02-05 04:30:44 +03:00

OVERLORD commented

2026-02-05 04:30:46 +03:00

@ssddanbrown commented on GitHub (Jan 8, 2022):

Hi @shadowychaos,

Have you set the APP_URL value in your .env file to match your current url, including the correct https:// or http:// prefix?

None of the .map files will load as they are not supposed to exist. Loading of those is only attempted when browser the development tools are open.

@ssddanbrown commented on GitHub (Jan 8, 2022): Hi @shadowychaos, Have you set the `APP_URL` value in your `.env` file to match your current url, including the correct `https://` or `http://` prefix? None of the `.map` files will load as they are not supposed to exist. Loading of those is only attempted when browser the development tools are open.

OVERLORD commented

2026-02-05 04:30:49 +03:00

@hunoz commented on GitHub (Jan 8, 2022):

Hello,

Yes, my .env file contains APP_URL=https://FQDN. Understood on the map files, wasn't sure if those were necessary for regular usage.

Below is the Nginx config. I've verified all directories under /var/www/html are owned by nginx:nginx.

worker_processes  1;

events {
    worker_connections  1024;
}

http {
    server {
        listen 80;
        server_name $host;

	return 301 https://$host$request_uri;
    }

    server {
	listen 443 ssl;

	server_name $host;
	
        ssl_certificate /etc/pki/tls/certs/server.cer;
        ssl_certificate_key /etc/pki/tls/private/server.key;

	root /var/www/html/BookStack/public;
        index index.php index.html;

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

#        location ~ \.php$ {
#            include snippets/fastcgi-php.conf;
#            fastcgi_pass unix:/run/php/php7.4-fpm.sock;
#        }

         location ~ ^/(?:\.htaccess|data|config|db_structure\.xml|README) {
             deny all;
         }

         location ~ \.php(?:$|/) {
             fastcgi_split_path_info ^(.+\.php)(/.+)$;
             include fastcgi_params;
             fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
             fastcgi_param PATH_INFO $fastcgi_path_info;
             fastcgi_pass unix:/run/php-fpm/www.sock;
         }

#         location ~* \.(?:jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ {
#             expires 30d;
#             access_log off;
#         }
    }
}

I've previously tried uncommenting the bottom lines but that did not work either.

@hunoz commented on GitHub (Jan 8, 2022): Hello, Yes, my .env file contains APP_URL=https://FQDN. Understood on the map files, wasn't sure if those were necessary for regular usage. Below is the Nginx config. I've verified all directories under /var/www/html are owned by nginx:nginx. ``` worker_processes 1; events { worker_connections 1024; } http { server { listen 80; server_name $host; return 301 https://$host$request_uri; } server { listen 443 ssl; server_name $host; ssl_certificate /etc/pki/tls/certs/server.cer; ssl_certificate_key /etc/pki/tls/private/server.key; root /var/www/html/BookStack/public; index index.php index.html; location / { try_files $uri $uri/ /index.php?$query_string; } # location ~ \.php$ { # include snippets/fastcgi-php.conf; # fastcgi_pass unix:/run/php/php7.4-fpm.sock; # } location ~ ^/(?:\.htaccess|data|config|db_structure\.xml|README) { deny all; } location ~ \.php(?:$|/) { fastcgi_split_path_info ^(.+\.php)(/.+)$; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_pass unix:/run/php-fpm/www.sock; } # location ~* \.(?:jpg|jpeg|gif|bmp|ico|png|css|js|swf)$ { # expires 30d; # access_log off; # } } } ``` I've previously tried uncommenting the bottom lines but that did not work either.

OVERLORD commented

2026-02-05 04:30:54 +03:00

@ssddanbrown commented on GitHub (Jan 8, 2022):

Okay, Couple of things:

When viewing the failing CSS file network request, in browser devtools, is the URL correct as per <APP_URL>/dist/styles.css?
If you open that request in the network tab of the browser tools, what is the Content-Type header value within the "Response Headers" section?

@ssddanbrown commented on GitHub (Jan 8, 2022): Okay, Couple of things: - When viewing the failing CSS file network request, in browser devtools, is the URL correct as per `<APP_URL>/dist/styles.css`? - If you open that request in the network tab of the browser tools, what is the `Content-Type` header value within the "Response Headers" section?

OVERLORD commented

2026-02-05 04:30:57 +03:00

@ssddanbrown commented on GitHub (Jan 8, 2022):

Ah, If the above is your whole configuration for nginx, you'll need to include the mime types, This is usually configured by default in nignx setups.

See the line include conf/mime.types; in "nginx.conf", and the "mime.types" section here:
https://www.nginx.com/resources/wiki/start/topics/examples/full/

@ssddanbrown commented on GitHub (Jan 8, 2022): Ah, If the above is your whole configuration for nginx, you'll need to include the mime types, This is usually configured by default in nignx setups. See the line `include conf/mime.types;` in "nginx.conf", and the "mime.types" section here: https://www.nginx.com/resources/wiki/start/topics/examples/full/

OVERLORD commented

2026-02-05 04:31:00 +03:00

@hunoz commented on GitHub (Jan 8, 2022):

Ah, as it turns out, it was an issue with the below section:

         location ~* \.(?:jpg|jpeg|gif|bmp|ico|png|css|js|swf) {
             expires 30d;
             access_log off;
         }

By uncommenting it and adding "default_type text/css;" to the section, it could correctly query css subpages. So now, it looks like this:

         location ~* \.(?:jpg|jpeg|gif|bmp|ico|png|css|js|swf) {
	     default_type text/css;
             expires 30d;
             access_log off;
         }

Very weird that I had to include that for it to properly query the css subpage. Changing this and emptying my caches, it loads properly now!

@hunoz commented on GitHub (Jan 8, 2022): Ah, as it turns out, it was an issue with the below section: ``` location ~* \.(?:jpg|jpeg|gif|bmp|ico|png|css|js|swf) { expires 30d; access_log off; } ``` By uncommenting it and adding "default_type text/css;" to the section, it could correctly query css subpages. So now, it looks like this: ``` location ~* \.(?:jpg|jpeg|gif|bmp|ico|png|css|js|swf) { default_type text/css; expires 30d; access_log off; } ``` Very weird that I had to include that for it to properly query the css subpage. Changing this and emptying my caches, it loads properly now!

OVERLORD commented

2026-02-05 04:31:05 +03:00

@ssddanbrown commented on GitHub (Jan 8, 2022):

By uncommenting it and adding "default_type text/css;" to the section, it could correctly query css subpages.

I think that might then lead to issues for other content-types that are not CSS files. If the mimes are included, as per my previous comment, then these types should be automatically detected.

@ssddanbrown commented on GitHub (Jan 8, 2022): > By uncommenting it and adding "default_type text/css;" to the section, it could correctly query css subpages. I think that might then lead to issues for other content-types that are not CSS files. If the mimes are included, as per my previous comment, then these types should be automatically detected.

OVERLORD commented

2026-02-05 04:31:13 +03:00

@hunoz commented on GitHub (Jan 9, 2022):

Ah you are correct, my apologies! I remove the default_type and add the include for mime.types and it still works, so this is definitely the safer method.

Thank you for helping figure this out, at least it was a small miss 😅

@hunoz commented on GitHub (Jan 9, 2022): Ah you are correct, my apologies! I remove the default_type and add the include for mime.types and it still works, so this is definitely the safer method. Thank you for helping figure this out, at least it was a small miss :sweat_smile:

OVERLORD commented

2026-02-05 04:31:17 +03:00

@ssddanbrown commented on GitHub (Jan 9, 2022):

No problem, Happy to hear it's now working. Will therefore close this off.

@ssddanbrown commented on GitHub (Jan 9, 2022): No problem, Happy to hear it's now working. Will therefore close this off.

OVERLORD referenced this issue

2026-02-05 10:22:44 +03:00

[PR #2561] [MERGED] Search owned by me #6017

Sign in to join this conversation.