When clicking on Edit button on main content page (adminpath/content) the following (example) link is generated:

http://www.site.com/node/999/edit?destination=/adminpath/content

However, the following error is generated when accessing above url:

The website encountered an unexpected error. Please try again later.

The following log entry is generated:

Location: http://www.site.com/node/999/edit?destination=%2Fadminpath%2Fcontent
Referrer: http://www.site.com/adminpath/content
Message: UnexpectedValueException: Invalid Host "www.site.com?destination=" in Symfony\Component\HttpFoundation\Request->getHost() (line 1238 of C:\inetpub\wwwroot\sites\site.com\vendor\symfony\http-foundation\Request.php).

Site is running under Windows Server (IIS)

CommentFileSizeAuthor
#19 2821674-19-not-working-with-drupal-8.2.x-and-query-destination.patch970 bytesHalfChem

Comments

kapetan created an issue. See original summary.

kapetan’s picture

kapetan commented
Title: Nor working with drupal 8.2.x and query destination » Not working with drupal 8.2.x and query destination
pleppik’s picture

pleppik commented

We are seeing similar behavior for a variety of admin pages, not just Edit Content.

Site is running under Linux.

raphael apard’s picture

raphael apard commented

I cannot reproduce this error.
You are using multisite ?
Could you try with the new release (8.x-1.1) ?

pleppik’s picture

pleppik commented

We are using the current version (8.x-1.1) and Drupal Core 8.2, in a single site installation.

Steps to reproduce (on our installation):

1) login as an admin user

2) go to any node, and click the "Edit" from the node's pop-up admin menu

This will give the error and log entry described in the report. Disabling the Rename Admin Paths module makes the error go away.

pleppik’s picture

pleppik commented
Version: 8.x-1.x-dev » 8.x-1.1
raphael apard’s picture

raphael apard commented

Do you set "trusted_host_patterns" in your settings.php ?

I try with "trusted_host_patterns" enabled but i'm cannot reproduce

pleppik’s picture

pleppik commented

We normally have trusted_host_patterns set, and encountered the error. We tried turning it off, but that did not correct the error.

pleppik’s picture

pleppik commented

Also, the error only happens when there's something that looks like a path passed as a parameter in the URL.

So this fails: /node/944/edit?destination=/etc/content (/etc/ is our renamed admin path)

This also fails:/node/944/edit?destination=/ (note no admin path anywhere in the URL)

But this succeeds: /node/944/edit

This also succeeds: /node/944/edit?arglebargle

But this fails: /node/944/edit?arglebargle=/etc/content

kapetan’s picture

kapetan commented

Same thing here, this happens only if '/' is included somewhere in the path. We also have trusted_host_patterns set. I'm almost sure the whole setup worked before updating to Drupal 8.2. We are also using custom bootstrap theme if this is important at all (it may be bootstrap specific)....

aprogs’s picture

aprogs commented

The bug was not reproduced with Drupal 8.2.1 and Rename Admin Paths 8.x-1.1.

Next steps were made to reproduce the bug:

  1. Configure Rename Admin Paths to use custom admin path.
  2. Go the Content page.
  3. Hit Edit in the Operations column.
  4. [Edit the node], hit the "Save and keep published" button.
  5. The user is redirected to the page specified in the ?destination parameter in the URL.

In the result user gets redirected without the error. Please let me know if you need more input about test environment.

kapetan’s picture

kapetan commented

The problem happens between step 3 and step 4, node edit page is not displayed at all, instead "The website encountered an unexpected error. Please try again later." error is displayed.

It's still there, tested with 8.2.3 and Rename Admin Paths 8.x-1.1.

pleppik’s picture

pleppik commented

On the theory that this might be some sort of interaction between modules, here's a list of the non-core modules we have installed and active on our site:

  • Rename Admin Path
  • Chaos Tools
  • Composer Manager
  • Feeds
  • Mail System
  • Swift Mailer
  • Contact Storage
  • Pathauto
  • Redirect
  • Token
  • Metatag
  • Yoast SEO
  • Honeypot
  • Google Analytics
  • Superfish
  • YAMLform
kapetan’s picture

kapetan commented

Ok, here are the modules we also have and match your list:

Chaos Tools
Composer Manager
Pathauto
Redirect
Token
Metatag
Honeypot
Google Analytics
YAMLform (WebForm now)

Currently, Druapl 8.2.4 with all latest updates for above modules and the problem is still here. Not sure, could be a conflict with Pathauto or Redirect....

All of the modules were here from the start but seems like update of some of above modules created conflict with rename admin paths since this problem was not present few months ago.

rooby’s picture

rooby commented

I am also seeing this error.

Currently I am running
* Drupal 8.2.1
* Rename admin paths 8.x-1.1

I see the problem on Apache/2.4.16 (Ubuntu), however I also have the site running on an IIS8 Azure instance and I don't have the problem there so it would seem to be server configuration related, which would explain why some people don't see it.

kapetan’s picture

kapetan commented

I went back to this issue today and after some time of analyzing the code and testing I think I found the solution for the problem, tested on two different IIS servers running Drupal 8.2.4 sites.

Here is original processInbound function:

public function processInbound($path, Request $request) {
$config = \Drupal::config('rename_admin_paths.settings');

// Admin path
if ($config->get('admin_path')) {
$admin_path_value = $config->get('admin_path_value');

// 404 for default admin path
if (preg_match('|^/admin(?![^/])|i', $path)) {
$path = NULL;
}
// Get back default admin path
elseif (preg_match('|^/' . urlencode($admin_path_value) . '(?![^/])(.*)|', $path, $matches)) {
$path = '/admin' . $matches[1];
}
}

// User path
if ($config->get('user_path')) {
$user_path_value = $config->get('user_path_value');

// 404 for default user path
if (preg_match('|^/user(?![^/])|i', $path)) {
$path = NULL;
}
// Get back default user path
elseif (preg_match('|^/' . urlencode($user_path_value) . '(?![^/])(.*)|', $path, $matches)) {
$path = '/user' . $matches[1];
}
}

return $path;
}

----
$path = NULL; line seems to be the source of the problem.

Changing this line to:

$path = '/';

resolves the problem, at least here... Hope this helps others with same issue.

raphael apard’s picture

raphael apard commented

Thank for analyzing this issue.
Changing $path from NULL to "/" will remove the 404 on original path "/user" for example and this original url will serve the frontpage instead of a 404.

kapetan’s picture

kapetan commented

Seems like NULL is problematic for the server so you can put $path = '/404'; and it will still work. I actually used this path during testing.

HalfChem’s picture

HalfChem commented
StatusFileSize
new 2821674-19-not-working-with-drupal-8.2.x-and-query-destination.patch970 bytes

I rolled a quick patch for the changes mentioned #18 . Thanks for all the hard work on this module!

raphael apard’s picture

raphael apard commented
Status: Active » Fixed

Thanks

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.