0

I have also posted my question in Stackoverflow but i think here is more appropriate place to ask.

I use docker and i have setup a nginx container with nginx 1.12.2, a php-fpm container with 5.6.33 and a mariadb container for database purposes. I have managed to server a drupal site and everything looks fine except of urls.

When i click in a link i get http://localhost/#overlay=%3Fq%3Dadmin%252Fconfig instead of http://localhost/#overlay=admin/config.

I cannot understand why this is happening. The page is working properly and in nginx log i get:

[28/Jan/2018:11:55:14 +0000] "GET /?q=admin%2Fconfig&render=overlay HTTP/1.1" 200 11405 "-" "Mozilla/5.0

I don't know if it is nginx issue or something misconfigured in php-fpm parameters (like www.conf or php.ini)

My nginx configuration is following:

# If we receive X-Forwarded-Proto, pass it through; otherwise, pass along the # scheme used to connect to this server map $http_x_forwarded_proto $proxy_x_forwarded_proto { default $http_x_forwarded_proto; '' $scheme; } # If we receive X-Forwarded-Port, pass it through; otherwise, pass along the # server port the client connected to map $http_x_forwarded_port $proxy_x_forwarded_port { default $http_x_forwarded_port; '' $server_port; } # If we receive Upgrade, set Connection to "upgrade"; otherwise, delete any # Connection header that may have been passed to this server map $http_upgrade $proxy_connection { default upgrade; '' close; } # Apply fix for very long server names server_names_hash_bucket_size 128; # Default dhparam ssl_dhparam /etc/nginx/dhparam/dhparam.pem; # Set appropriate X-Forwarded-Ssl header map $scheme $proxy_x_forwarded_ssl { default off; https on; } gzip_types text/plain text/css application/javascript application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript; log_format vhost '$host $remote_addr - $remote_user [$time_local] ' '"$request" $status $body_bytes_sent ' '"$http_referer" "$http_user_agent"'; access_log off; resolver 127.0.0.11; # HTTP 1.1 support proxy_http_version 1.1; proxy_buffering off; proxy_set_header Host $http_host; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $proxy_connection; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $proxy_x_forwarded_proto; proxy_set_header X-Forwarded-Ssl $proxy_x_forwarded_ssl; proxy_set_header X-Forwarded-Port $proxy_x_forwarded_port; # Mitigate httpoxy attack (see README for details) proxy_set_header Proxy ""; server { server_name _; # This is just an invalid value which will never trigger on a real hostname. listen 80; access_log /var/log/nginx/access.log vhost; return 503; } # localhosy upstream localhost { ## Can be connect with "ngproxy" network # localhost server 172.18.0.3:9000; } server { server_name localhost; listen 80 ; root /var/www/html; index index.php index.html index.htm; access_log /var/log/nginx/access.log vhost; location = /favicon.ico { log_not_found off; access_log off; } location = /robots.txt { allow all; log_not_found off; access_log off; } # Very rarely should these ever be accessed outside of your lan location ~* \.(txt|log)$ { allow 192.168.0.0/16; deny all; } location ~ \..*/.*\.php$ { return 403; } location ~ ^/sites/.*/private/ { return 403; } # Allow "Well-Known URIs" as per RFC 5785 location ~* ^/.well-known/ { allow all; } # Block access to "hidden" files and directories whose names begin with a # period. This includes directories used by version control systems such # as Subversion or Git to store control files. location ~ (^|/)\. { return 403; } location / { # try_files $uri @rewrite; # For Drupal <= 6 try_files $uri /index.php?$query_string; # For Drupal >= 7 } location @rewrite { rewrite ^/(.*)$ /index.php?q=$1; } # Don't allow direct access to PHP files in the vendor directory. location ~ /vendor/.*\.php$ { deny all; return 404; } # In Drupal 8, we must also match new paths where the '.php' appears in # the middle, such as update.php/selection. The rule we use is strict, # and only allows this pattern with the update.php front controller. # This allows legacy path aliases in the form of # blog/index.php/legacy-path to continue to route to Drupal nodes. If # you do not have any paths like that, then you might prefer to use a # laxer rule, such as: # location ~ \.php(/|$) { # The laxer rule will continue to work if Drupal uses this new URL # pattern with front controllers other than update.php in a future # release. location ~ '\.php$|^/update.php' { fastcgi_split_path_info ^(.+?\.php)(|/.*)$; # Security note: If you're running a version of PHP older than the # latest 5.3, you should have "cgi.fix_pathinfo = 0;" in php.ini. # See http://serverfault.com/q/627903/94922 for details. include fastcgi_params; # Block httpoxy attacks. See https://httpoxy.org/. fastcgi_param HTTP_ACCEPT_ENCODING ""; fastcgi_param HTTP_PROXY ""; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info; fastcgi_intercept_errors on; # PHP 5 socket location. #fastcgi_pass unix:/var/run/php5-fpm.sock; # PHP 7 socket location. fastcgi_pass drupal:9000; } # Fighting with Styles? This little gem is amazing. # location ~ ^/sites/.*/files/imagecache/ { # For Drupal <= 6 location ~ ^/sites/.*/files/styles/ { # For Drupal >= 7 try_files $uri @rewrite; } # Handle private files through Drupal. Private file's path can come # with a language prefix. location ~ ^(/[a-z\-]+)?/system/files/ { # For Drupal >= 7 try_files $uri /index.php?$query_string; } location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ { try_files $uri @rewrite; expires max; log_not_found off; } } 
2
  • This looks like an issue with the Drupal overlay module, not with your nginx configuration. Commented Jan 28, 2018 at 14:14
  • Thank you very very much @MichaelHampton. Your comment really helped me to change my point of view. As i describe in my answer below, the solution was extremely simple (i have spent the whole weekend, searching for a solution, i was looking in the wrong direction) Commented Jan 28, 2018 at 15:47

1 Answer 1

0

Thanks to Michael Hampton i change my point of view and start looking for drupal related issue. I read that the overlay module couldn't work well with non clean urls. I was pretty sure that i have done every work needed for urls to work so i didn't even think that it is a clean url issue of Drupal. As i read here, Drupal Official Documentation about Configuring Clean Urls about False Negatives:

Clean-Urls Test - False Negatives

On some setups the Clean Urls test gives a false negative result. If you can visit Clean Url links like http://example.com/user/login and Drupal returns the user login page, then .htaccess and mod_rewrite are working. Visiting the Clean Urls admin page directly at http://example.com/admin/config/search/clean-urls, should give you a checkbox that lets you enable Clean Urls (note the lack of "?q=" in the URL). See http://drupal.org/node/1178850. Note: If Clean Urls like http://example.com/user/login. stops working (switching hosts) you can visit the same page by changing the URL to look like: http://www.example.com/?q=user/login.

So the solution was extremely simple. I visit http://localhost/admin/config/search/clean-urls and just checked to enable clean urls. And that's it.

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.