2

I have a very strange issue with a Drupal 8 install. My production setup is running on NGINX in a subdirectory - something like www.example.com/abc.

The site is running great, but I have seen an error occur that I can't pinpoint. One page that I setup as the frontpage (ie, /abc/index.php) is made with a view that uses the Slick Carousel module to show a carousel of nodes of a certain content type (news).

Here's what's going on:

  • sometimes the URL on an item of the carousel loses the /abc part of the path, effectively sending users away from the site (ie, /node/123 when it should be /abc/node/123).
  • this happens when the user who created the node has a certain role (lower than admin). If admins create the node it doesn't happen.
  • it is only visible/only affects anonymous (not logged) users. If a user is logged in, be it either admin or otherwise (including the role for who this happens), the page shows up the correct URL (ie, /abc/node/123).
  • it only happens on that page/view. In other pages/views which list the news content type, the same node shows the correct URL for all users, either anonymous and/or logged in.
  • I (admin) can solve it in at least 2 ways:
    • unpublish/publish the problematic node;
    • clearing the cache
  • the problematic role has no way of solving this using the above methods.

Now, to add difficulty to the whole process, I have no control over the NGINX configuration, although I was told it was setup according to NGINX's Drupal recipe.

Also, in my dev environment this doesn't occur, even though the configuration settings are the same (it's exported every time I deploy to production). The only thing that might be different is the settings.php file.

Obviously, I have no debug facilities in place for the production website, so there isn't much I can do to trace the issue. Also, there are no log messages indicating something might be wrong with this page.

I'm now trying to find a way to replicate the production environment in a VM, but even so, I'm not sure where to start looking for the problem.

Can anyone share any thoughts on this?

EDIT: I have replicated the production environment with Docker containers and I can't replicate the bug.

Meanwhile, I have seen some even weirder things happening: sometimes (again, fixable by clearing cache), the menus also get the wrong URLs - I have a block menu holding a link to the login page that instead of going to www.example.com/abc/user/logingoes to www.example.com/user/login.

I guess clearing the cache forces the URLs to be rebuilt and apparently it gets fixed. But aren't URLs rebuilt anyway when you publish content? Why can this affect the menus as well?

  • 1
    I believe drupal.org/node/2818185 may be the root cause of this, or potentially drupal.org/node/2817411. A few URL related bugs with Views were recently uncovered, those are two that I recall. – mpdonadio Nov 2 '16 at 12:44
  • @mpdonadio thank you for your thoughts. Do you suggest applying any of the several patches? – Joum Nov 17 '16 at 10:05
  • 1
    If you cannot replicate the bug after setting up an identical clone on different server, then it looks like it is not a Drupal issue. – No Sssweat Nov 24 '16 at 9:22
1

There are a few options to what might be wrong:

1. Globals are created incorrectly

What you want to do, is to have a look at DrupalKernel::initializeRequestGlobals() this is where $base_url and $base_path globals are generated. Behind the scenes, this is what Drupal 8 uses to figure out how links should look.

The issue might be related to these being resolved incorrectly

2. Relative URLs / Globals not used.

If the urls that are generated various places are relative, there might be some places that assumes that it should only include the drupal part, like /node/123 and thus remove the /abc part of the of the full url

Way forward

What I would do in your situation is to figure out how the urls are that causes trouble are generated. For starters you don't need to go through the entire trace, but you could find some theme function and log final URL + globals. In production where the issue can arise you can obtain information about what the root cause of the issue is, which has to be one of:

  • Urls don't use globals
  • Globals are wrong

Once you know the root cause, you can fix it.

The globals are generated from $_SERVER['SCRIPT_NAME'], I haven't heard example of this being buggy or inconsistent so most likely issue is some urls doesn't use this.

Urls are mostly generated through \Drupal\Core\Routing\UrlGenerator. I have seen Drupal having some some issues when menus are user created. Since the url is not created from a route. When you dig into it, it gets rather complex, since especially internal urls are converted a lot of times.

  • Thank you for your feedback. These URLs are only generated wrongly sometimes and every time it happens, it's in one specific page. Also sometimes there are URLs with the wrong path in the same page as URLs with the right path. – Joum Nov 23 '16 at 16:47
  • With this I mean I think that the URLs being relative or not is not the question, but rather if at some point, the URL generator class gets different/conflicting info on what the $base_path and/or $base_url might be. Do you know of something that might cause this? – Joum Nov 23 '16 at 16:49
  • @Joum Extend the service and log the behaviour. That is the best cause of action. Otherwise it will just be a guessing game, which can be very time consuming. – googletorp Nov 28 '16 at 8:29
1
+25

Did you try sites.php in the sites folder?

This file has a good documentation which probably might resolve you issue. Just rename example.sites.php to sites.php and put this in the beginning of the file:

 $sites = array(
   'www.example.com.abc' => 'abc',
 );

This asks drupal to look into abc folder in the root of your site when you try to access www.example.com/abc path. If that does not help I'd recommend to look what you have in the .htaccess file both in the root and abc subfolder. But with this file it is difficult to advise something as its settings may be very specific to the hosting environment and what the base settings it has. If you don't need to access www.example.com path you could put this in the .htaccess in the root of the site (public_html, www, or similar)

DocumentRoot "/abc"

After saving the setting flush caches both on the site and in your current browser too just to see the effect. Or look the site in another browser where the site was not seen before.

  • Thank you for your feedback, but I'm targeting NGINX, not Apache - .htaccess files have no influence in my case, I'd have to use some .conf file instead. Also, that doesn't explain why it happens sometimes and others not, and, also important, why clearing the cache fixes it. – Joum Nov 23 '16 at 16:41
1

Perhaps it is a NGINX config problem? Running Drupal in a subdirectory under Apache normally requires you to alter .htaccess and RewriteBase. I am not a NGINX admin but I would start by getting a copy of the running config. It might need stuff along

location ~ \.php$ {
        fastcgi_split_path_info ^(/abc)(/.*)$;
}

To avoid loosing in base directory.

  • Thank you for your feedback, but I really doubt it is an NGINX issue. Clearing Drupal's cache rewrites the URLs in question, how can NGINX affect that? – Joum Nov 23 '16 at 16:44
  • Drupal 8 uses Symfony\Component\HttpFoundation when trying to figure out where it is running. Have a look at api.drupal.org/api/drupal/… have a look at the code and the method doing getBasePath(). – steinmb Dec 13 '16 at 14:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.