Website pages are not opening correctly on nginx - nginx

I am trying to setup a Question2Answer website (yoalfaaz.com) on nginx with Ubuntu. Now, the homepage of the website does load but any other page doesn't load correctly. Mostly, when I click for any post on my website, it opens the homepage again and sometimes just breaks the layout.
Here's the sites-available file
server {
listen 80 ;
listen [::]:80 ;
root /var/www/yoalfaaz.com/html;
# Add index.php to the list if you are using PHP
index index.php index.html index.htm index.nginx-debian.html;
server_name yoalfaaz.com www.yoalfaaz.com;
location / {
# First attempt to serve request as file, then
# as directory, then fall back to displaying a 404.
try_files $uri $uri/ /index.php$is_args$args;
}
# pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
#
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php7.0-fpm.sock;
}
location ~ /\.ht {
deny all;
}
}
Now, previously only the homepage was opening and for every other page, I was getting 404 Not Found error. So I made some changes to try_files line and after that, the website pages are not opening in the correct way.
I have also checked for any kind of errors, but there are none and if I try nginx -t then it also shows successful. Please help me out, guys.

Apparently the problem is not nginx, but your application.
Looking at the HTML of your pages I see this:
<link href="./qa-plugin/q2a-embed-master/qa-embed.css" rel="stylesheet">
<link rel="stylesheet" href="./qa-plugin/q2a-tag-list-widget-master/tag-list.css?" TYPE="text/css">
<link rel="stylesheet" href="./qa-plugin/Welcome-Widget-master/welcome-widget.css?" TYPE="text/css">
The URLs of your CSS files are relative to the current path, so basically the location changes if the URL contains something that resembles a path or subdirectory.
Take for example this URL: http://yoalfaaz.com/4966/pardesi-ke-naam
Trying to load the CSS file ./qa-plugin/q2a-embed-master/qa-embed.css on that page will load http://yoalfaaz.com/4966/qa-plugin/q2a-embed-master/qa-embed.css which results in a 404 error.
You should change your code to output absolute URLs or root-relative URLs.
Example:
Absolute URL: http://yoalfaaz.com/qa-plugin/q2a-embed-master/qa-embed.css or //yoalfaaz.com/qa-plugin/q2a-embed-master/qa-embed.css (the last one is protocol-relative URL)
Root-relative URL: /qa-plugin/q2a-embed-master/qa-embed.css (always will start at the root of the domain)

Related

Problem with NGINX config - Wordpress - 404 on all pages except Homepage

I am fairly new to server issues and I am trying to figure out what may cause the following issue.
I have a wordpress website and the folder structure is as follows:
httpdocs(folder) >
folder1 (which contains the wordpress instance for security purposes)
wp-config file (the actual wp-config file)
index.php (which "calls" ./folder1/wp-blog-header.php)
I seem to get 404 errors on every page except from the homepage.
The server support team tried to put
location = / {
index index.php;
try_files $uri $uri/ /index.php$is_args$args;
}
and later
location = /folder1 {
index index.php;
try_files $uri $uri/ /folder1/index.php$is_args$args;
}
on the nginx additional directives, but the problem persists.
To be specific, I get the following error:
20840#0: *number "/var/www/vhosts/sitename/httpdocs/pagename/index.php" is not found (2: No such file or directory)
Obviously, I am missing something. Can someone help me?

NGINX try_files works for all but one url

I have a simple dashboard for my site. Here is the directive:
location /dashboard {
try_files $uri /dashboard/index.php;
}
It works for all items after /dashboard. For example, /users or /pages - all CRUD operations work as expected.
The index.php file at /dashboard is my "controller". It parses the url and includes and runs scripts from there.
For example: /dashboard/group/edit/123456 works as expected and I get the edit page for group number 123456.
But when I post from that page to /dashboard/group/update, it serves /dashboard/group/index.php
So, in the first example, The edit page is loaded and the url at the top of the screen does not change.
In the second example, NGINX is CHANGING the url so my script cannot get the url parts to do the job.
I thought it may have something to do with POST, but I have other forms that use POST without issue.
In addition, or possibly a clue, try_files is returning /dashboard/group/index.php while the directive should return /dashboard/index.php.
Is there another NGINX file that could have so old code in it that is overwriting this domain's config?
I've been at this a few hours and have run out of ideas. Any thoughts?
* One More Clue *
When I BROWSE to /dashboard/group/update, NGINX shows the page as expected. It is only when I POST to that page that NGNIX sends me to /dashboard/group/index.php.
Again, at the very least, it should be sending me to /dashboard/index.php and NOT /dashboard/group/index.php.
You not send all after /dashboard try this:
location /dashboard {
try_files $uri /dashboard/index.php?$uri&$args;
}
OR
location /dashboard {
try_files $uri /dashboard/index.php?$query_string;
}
Nginx docs: https://nginx.org/en/docs/http/ngx_http_core_module.html#try_files
Instead of
location /dashboard {
try_files $uri /dashboard/index.php;
}
Try
location /dashboard {
index index.php; #adding this may work alone
try_files $uri /dashboard/index.php?$uri;
}
I have concluded that I have a cache problem. The location directive works on all items that I have not yet accessed.
So, my configuration - as described - works as it should.
I just have to figure out how to clear my cache ( which in NOT set up in NGINX that I can see!)
Thank you all who helped!

How to configure nginx the way url shows less folder than it's real?

I have app on Node.js on Nginx.
When I open page
domainname.com/somefolder/page.html
it should show in address bar the same page
domainname.com/somefolder/page.html
But page.html can be on the page deep in folder like
morefolder/anotherfolder/…./somefolder
Meanwhile I have folders, which are located in core folder and should open from this folder. How to solve it?
You can achieve it by configuring nginx as below:
server {
listen 80;
server_name domainname.com www.domainname.com;
#root /usr/share/nginx/html;
# Load configuration files for the default server block.
include /etc/nginx/default.d/*.conf;
location /somefolder/page.html {
root morefolder/anotherfolder/onemorefolder;
}
}
Your core folder is morefolder/anotherfolder/onemorefolder
All subfolders and html pages are within.
You browse domainname.com/somefolder/page.html it re-directs it to domainname.com/morefolder/anotherfolder/onemorefolder/somefolder/page.html but this is transparent to user and address bar shows same page you browsed.
Since I don't have exact name of files and folders I used this construction
location / {
try_files $uri /post$uri =404;
}
location / checks any URL which is not specified (i.e. domainname.com/test). In my case it was any URL like domainname.com/folder/file.html
try_files checks URL (aka $uri) and if it is not found then goes to next /post$uri and if it's not found, then shows 404 page
In my case i open page www.domainname.com/folder/file.html it checks whether it exists, it doesn't exist, then it checks whether www.domainname.com/post/folder/file.html exist and opens it if it exist, otherwise shows 404 page

Redirect nginx /index.html to root causing infinite redirects

I want to avoid having the same HTML page accessible on www.example.com and www.example.com/index.html, i.e i want to redirect the index.html to root.
This:
location = /index.html {
return 301 $scheme://www.example.com;
}
is causing me to get ERR_TOO_MANY_REDIRECTS, a redirect loop.
Any ideas what can i change to make it work?
PS this is my entire nginx conf
server {
listen 443 ssl http2 default_server;
listen [::]:443 ssl http2 default_server;
include /etc/nginx/snippets/ssl-example.com.conf;
include /etc/nginx/snippets/ssl-params.conf;
include /etc/nginx/snippets/letsencrypt-challenge.conf;
root /var/www/newsite;
index index.php index.html index.htm;
server_name www.example.com;
location / {
# try_files $uri $uri/ =404;
try_files $uri $uri/ /index.php?q=$uri&$args;
}
location = /index.html {
return 301 $scheme://www.example.com;
}
}
This is not a detailed treatment of the subject but a simplified explanation just to answer your dilemma. The answer is that you need to abandon the attempt to do what you are doing.
Webservers can only serve specific files such as an xyz.html file. They cannot serve folders.
A call to https://www.example.com/abc/index.html is a request for the index.html file in the abc folder of the web root. A call to https://www.example.com/abc on the other hand is a request for the abc folder of the web root, which as mentioned, cannot be served.
As you have noticed however, the second call results in https://www.example.com/abc/index.html being served. This is because webservers are generally set up such that when a call is made to a folder without specifying a specific file to serve, a redirect to the index.html file in that folder is generated and this is served instead. That is, the webserver internally turns the request for https://www.example.com/abc into a request for https://www.example.com/abc/index.html.
This is what the index index.php index.html index.htm; line in your config does. It says "if there is a request for a folder without a file specified, serve the index.php file instead. If there is not such file, serve the index.html. If there is not such file, serve the index.htm file. If this also does not exist, throw a fit"
The problem is that you then go on to instruct your webserver to redirect requests for https://www.example.com/index.html to https://www.example.com which the webserver redirects back to https://www.example.com/index.html which is again redirected back to https://www.example.com in an endless loop until the webserver or your browser finally gives up.
You stated that I want to avoid having the same HTML page accessible on www.example.com and www.example.com/index.html, i.e i want to redirect the index.html to root. The question is why? There is absolutely no benefit in doing this and as you found out, you end up in a redirect loop.
You may be trying some SEO stuff but this does not apply here.

nginx how to serve pictures or media files?

I'm having issues serving pictures with nginx. I originally started with a Django project and I wanted to serve the user uploaded media files via nginx but I wasn't able to get it working no matter what I tried.
So, I've make a second temporary droplet/server and am trying a bare bones setup with no Django project, just Nginx, to see if I can get it to simply serve an index and a couple pictures in a folder called 'media'. Here is the server block:
server {
listen 80;
listen [::]:80;
root /var/www/example.com/html;
index index.html;
server_name 159.89.141.121;
location / {
try_files $uri $uri/ =404;
}
location /media/ {
root /var/www/example.com/media;
}
}
Now, the index.html is served fine but if I try to go to 159.89.141.121/media/testpic.jpg it still doesn't work and returns a 404 error. I'm at a complete loss here, I've tried using alias instead of root, I've tried changing the folder structure and setting all permissions to 777 and changing folder and file ownership, permissions shouldn't be a problem because the index.html works fine with the same permissions; I just cant seem to figure out what I'm doing wrong. The picture is in the folder but nothing I try allows me to access it via the uri. Are there any obvious problems with my server block?
Well I decided to read the documentation and realized that the location block adds to the root directory specified..
So the pathing of
`location /media/ {
root /var/www/example.com/media;
}`
would end up routing example.com/media/testpic.jpg to /var/www/example.com/media/media/testpic.jpg
I've changed the location block to look like this
location /images/ {
root /var/www/example.com/media;
}
and it will now route example.com/images/testpic.jpg to /var/www/example.com/media/images/testpic.jpg
I'm not sure why it didn't work when I tried the alias directive, though...

Resources