Atualização 2:
Solução:
pode se aplicar a qualquer aplicativo PHP que precise de roteamento, pule o comentário se desejar :-P
...
location / {
try_files $uri $uri/ @lime;
}
# pass the PHP scripts to FastCGI server listening on the php-fpm socket
location @lime {
# no '.php' in our fancy uri, useless
# fastcgi_split_path_info ^(.+\.php)(/.+)$;
# fastcgi_intercept_errors on;
# useless as well
# try_files $uri /index.php =404;
fastcgi_pass 0.0.0.0:9000;
fastcgi_index index.php;
include fastcgi_params;
# fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
# Yeah, you should use index.php and it will route for you
fastcgi_param SCRIPT_FILENAME $document_root/index.php;
fastcgi_param HTTPS off;
}
...
Usar o @
login em try_files
para realizar o redirecionamento interno é a maneira mais clara recomendada pela documentação do nginx . A criação de um bloco de localização separado para cada rota causará grandes quantidades de configurações duplicadas à medida que seu aplicativo cresce. Enquanto isso, manipular o código para obter as informações de caminho no parâmetro de script (uma maneira desagradável usada por Dupral) quebra a elegância do mecanismo de roteamento por sua estrutura, portanto, não é recomendado.
Atualização:
É algo relacionado à sua configuração do nginx.
quando o cliente visitar /create/name/
, em sua configuração do nginx, ele acessará
location / {
try_files $uri $uri/ /index.php?$query_string;
}
com $uri="/create/name/"
e $query_string=""
, portanto, seja reescrito em /index.php?
e, em seguida, correspondido por
location ~ \.php$ {
...
Ou seja, na perspectiva do nginx, visitar /create/name/
é equivalente a visitar /index.php
. Como resultado, o script php não obterá o caminho especificado. Portanto, sempre obtemos a página de índice.
Você adicionou <?php
no início do seu arquivo php?
Além disso, de acordo com a documentação do seu framework, você também deve ter isto
require_once("src/Lime/App.php");
no seu index.php
.
Referência: