I've tried literally every suggestion on the web and it doesn't seem to work.
I'm using slim framework to create REST services, and I call them in this format:
http://localhost:8080/myProject/resources/myapp.php/test/
and in myapp.php I have this defined:
$app->get('/test/', ...
when I used xampp this of course worked, but when I migrated to nginx, I get the 404 error.
On the official page they say I should add this to location:
try_files $uri $uri/ /index.php?$args;
I've changed the nginx.conf accordingly:
location / {
root html;
try_files $uri $uri/ /index.php?$args;
}
I still get the 'No input file specified.' 404 error.
Any suggestions are greatly appreciated!
Kiitos Mika.... that worked perfectly.
I had several problems with my routes on production server using nginx. It seemed for me only the subfolders were not working in GET when there were variables, all were getting 404.
Adding the query_string fixed it.
Try this (from URL it appears you are not using index.php, but myapp.php):
try_files $uri $uri/ /myapp.php?$args;
The following in nginx.conf is known to work.
try_files $uri $uri/ /index.php?$query_string;
Related
I'm trying to understand why in many nginx configuration examples people use q=$uri&$args. For example:
location / {
try_files $uri $uri/ /index.php?q=$uri&$args;
}
I'm interesting in it because for one of installed plugins "q" parameter isn't in white list and nginx has such configuration. Can I just use /index.php?$args; intead? Can this affect some hidden functionality?
P.S. I have WP v5.3.2 and my theme doesn't use such parameter
I have a wordpress site and when I use Arabic characters for the url address of my page I get a 404 Error but when I rename the link name for my page with english characters it works!
I found this question here but the solution there did not work for me! It makes sense that this is related somehow to .htaccess file, but I already have other wordpress sites which are working with arabic urls and have the same .htaccess content!
This link helped me solve my problem. Specifically adding
location / {
try_files $uri $uri/ /index.php?q=$uri&$args;
#try_files $uri $uri/ =404;
}
to the corresponding configuration file in /etc/nginx/sites-available worked for me!
Ive faced this problem when trying to execute an action from a controller in fuelphp framework, I get an 404 message from nginx. Im able to see, for e.g. localhost/index.php or just localhost, but when I try to access to an action-controller like localhost/index.php/login/huehue I get the 404 error. Can anyone help me? this app is currently working in apache, I was facing this trouble here too but everything got fine when I executed
a2enmod rewrite
then I tried to search for equivalent config for nginx and I found this like:
location /{ try_files $uri $uri/ /index.php?$args
/index.php?q=$request_uri }
or this:
location /{
rewrite ^ /index.php?/$request_uri;}
but they didnt work for me. Ive spent several hours trying to find out the reason. This is my actual vhost file config for my site:
server {
listen 80;
listen [::]:80;
root /var/www/nginx/goutmeet;
index index.php index.html index.htm index.nginx-debian.html;
server_name goutmeet.local www.goutmeet.local;
location / {
try_files $uri $uri/ /index.php?$args /index.php?q=$request_uri #handler;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php7.0-fpm.sock;
}
location #handler {
rewrite ^ /index.php?/$request_uri;
}
}
Id love to know how to solve this since using nginx sometimes is a better option than apache, and having this issue with fuelphp framework and not being able to use this two great tools together is awful.
Thanks in advance.
The try_files directive can have one default action. You have three! See this document for more.
Choose one:
try_files $uri $uri/ /index.php?$args;
try_files $uri $uri/ /index.php?q=$request_uri;
try_files $uri $uri/ #handler;
I do not know which is the appropriate default action for your application. They all send the request to the PHP controller, but with different sets of parameters.
The first case passes the query string; the second case passes a single parameter containing the request URI; and the third case invokes the rewrite in the named location.
I found a workaround for this problem, just add this line to config file:
error_page 404 /index.php;
I know is not the best solution but its been the only thing that has worked for me. In my opinion its acceptable since all routes should be managed by the framework and not by the web server.
Hope this helps someone.
I have a problem with wordpress permalinks and nginx.
For example i have a post with id = 29 and name=stars.
When I access to my post at www.domaine.com/?p=29 using simple permalink it works, but when I access the same post using post name as permalink at www.domaine.com/stars I get an error 404 "Object not found".
I tried to check the existance of files using this directive :
try_files $uri $uri / /index.php?q=$uri&$args;
also i tried to use this one :
try_files $uri $uri / /index.php?$args;
But nothing work.
Plugins that i use: Hide My WP plugin, AMP, Yoast SEO.
How can i resolve this ?
Altering the line to this Solved my permalink issue
try_files /maintenance.html $uri $uri/ /index.php?q=$uri&$args;
I just migrated a site from apache to nginx, and am very pleased so far. However, the server doesn't seem to recognize a $_GET parameter.
I've read that the answer is to change the try_files directive to:
location / {
try_files $uri $uri/ /index.php?$query_string;
}
But this isn't working for me. I suspect it's because the query string I'm using is a few directories in, with the url something like:
http://www.mysite.com/thedirectory/thefile?sortby=director
I just can't tweak the try_files directive to work in that instance, and the documentation seems sparse or obsolete.
Any ideas? If I don't get this resolved, I'm going to have to go back to Apache.
I don't know where you got that answer from,but in the context of your problem I don't see the relevance. Let's first get something clarified:
Try_files looks to match the URI with a physical location on disk and allows you to control the fallback action.
The default fallback is to throw a 404.
$query_string is not relevant to the matching process. It is used for try_files constructs where something has to be added to the query string.
There are three possible causes and remedies for your problem:
The uri matches a real file, but without the file extension, which causes the php processing location to not get triggered. In this case your statement should be:
try_files $uri $uri/ $uri.php;
This is a virtual location and the router is in index.php, like it it's with many applications, like WordPress and Magento.
In this case the try_files should be:
try_files $uri $uri/ #appname;
Without more context providing a location block for #appname is not possible.
You are not including relevant fastcgi_param directives. In this case your try_files is noise. Fix the actual problem first, by including the provided example fastcgi_param, as mentioned in the comments.