All URLs Display Homepage Content on a Joomla Website Powered by NGINX

We had a weird case late last week: a new client contacted us and told us that all the links on his website were pointing to the homepage. He told us that he was using NGINX, and he told us that he thought that NGINX is the cause of the issue.

So, we checked the website – it wasn’t that all the links were pointing to the homepage, it was that all the links were displaying the homepage. For example, http://www.ourclientjoomlawebsite.com/ and http://www.ourclientjoomlawebsite/link-1 and http://www.ourclientjoomlawebsite.cm/link-2 were all displaying the contents of the homepage. The links were not being redirected, the links were just displaying the contents of the homepage.

The first thing that we did was to empty the $live_site variable in the site’s configuration.php file. So, we changed:

public $live_site = 'http://www.ourclientjoomlawebsite.com';

to:

public $live_site = '';

Unfortunately, that didn’t work, but, deep down inside, we didn’t expect it to: it was a long shot…

The second logical thing to do was checking the nginx.conf, which is the NGINX configuration file. Here’s what we did:

• We ssh’d to the server as root.

• We opened the file nginx.conf which is located under the /etc/nginx folder.

• We checked if the location / statement existed in the code (which is needed for Joomla to work correctly under NGINX), and it didn’t, so we added the following code immediately before the last line (the last closing curly bracket):

  server {
    location / {
       expires 1d;
       try_files $uri $uri/ /index.php?$args;
    }
  }

• We saved the file, and then restarted the NGINX webserver by issuing the following command in the shell:

  /etc/init.d/nginx restart

  Note: If after restarting nginx you see the following error: Restarting nginx (via systemctl): nginx.serviceJob for nginx.service failed because the control process exited with error code. See “systemctl status nginx.service” and “journalctl -xe” for details., then the problem might be that you didn’t put the location code block inside a server code block.

• We tested the website, but still, the same problem…

Odd, we thought… Mind you, disabling SEF did solve the problem, but, naturally, that wasn’t a real solution and it wasn’t an option for the client…

After spending a few hours beating around the bushes, we started pondering about exploring cheap suicide tactics, like holding our breath for too long. Luckily, it didn’t come to this, as we saw something curious: when we visited the administrator section of the website, we noticed that no CSS style was applied to the login page, which was weird. Checking the HTML code, we noticed that the following file was requested:

<link href="/templates/isis/css/template.css?de6fd0cafae3e6687ab8a1abd290a957" rel="stylesheet" />

But, from our experience, the above line should be something like:

<link href="/administrator/templates/isis/css/template.css?de6fd0cafae3e6687ab8a1abd290a957" rel="stylesheet" />

So, why is administrator missing from the link? Is it related to the original problem? It must be related to the original problem – because it’s a substantial issue with the URL, which is exactly what the original problem is.

The missing “administrator” problem restored our hopes, because not only we were increasingly confident that it was directly connected to the original problem, we were also confident that we were able to fix it, as the problem was easily traceable through code.

Once we investigated this issue further, we discovered something interesting, the JURI::Base() function was always returning empty. Huh?

So, we checked the implementation of the JURI::Base() function in the file uri.php file which is located under the /libraries/joomla/uri/ folder, and we discovered something even more interesting, $_SERVER[‘PHP_SELF’] was empty! In fact, it was always empty!

Joomla relies on $_SERVER[‘PHP_SELF’] heavily in its handling of SEF URLs and in its backend, which means that the original problem is really caused by $_SERVER[‘PHP_SELF’]. We found the root cause of the problem! Hooray! The next step was to actually solve the problem…

It was obvious that the problem was caused by the NGINX web server, and so we made an extensive research about the issue, and we discovered that, in order to address the problem of the empty $_SERVER[‘PHP_SELF’], a certain PHP global variable, called PATH_TRANSLATED, must be explicitly defined in the fastcgi_params file that is used by the nginx.conf file. The fastcgi_params is typically found in the /etc/nginx folder (at the same level of the nginx.conf folder).

Another thing that needed to be done was to change the value of cgi.fix_pathinfo in the php.ini from 0 to 1.

Here’s how we did all the above:

• We added the following code to the nginx.conf file (instead of the code added near the beginning of this post):

  server {
    location / {
  	expires 1d;
  	try_files $uri $uri/ /index.php?$args;
  	fastcgi_split_path_info ^(.+?\.php)(/.*)$;
      if (!-f $document_root$fastcgi_script_name) {
  		return 404;
      }
  	fastcgi_param HTTP_PROXY "";
  	fastcgi_pass 127.0.0.1:9000;
  	fastcgi_index index.php;
  	include fastcgi_params;
    }
  }

• We opened the file fastcgi_params (again, which is located under the /etc/nginx ) folder and we added the following line (after the PATH_INFO line):

  fastcgi_param  PATH_TRANSLATED    $document_root$fastcgi_script_name;

• We restarted NGINX by issuing the following command:

  /etc/init.d/nginx restart

• We opened the php.ini file (please check phpinfo(); to know the exact location of your working php.ini file) and we changed the following line:

  cgi.fix_pathinfo=0

  to:

  cgi.fix_pathinfo=1

• We restarted php-fpm by issuing the following command in the shell:

  /etc/init.d/php7.0-fpm restart

• We checked the website and the problems, all the problems, were solved! The URLs were working and the administrator section was working! Double hooray!

We are not sure whether this problem applies to all NGINX servers, or to just NGINX servers using PHP 7. In either case, the official Joomla documentation about NGINX should be updated, as it no longer reflects a guaranteed working solution.

If you’re running NGINX and your website is displaying the homepage for all the URLs, then please follow our guide above. It should work for you as it worked for us. In the unlikely case where it doesn’t work for you, then please contact us. Our service is fast, our work is professional, we are reliable, and our fees are super affordable.