InvalidArgumentException in Drupal\Core\Url::fromUserInput()

Yeah. It should be committed.

This is a problem but the patch is not the right way to fix it.

Yes, Drupal core changed the way paths are specified in code - in D7 they used to require that that leading '/' was omitted. It is now the opposite in many places (but not all) in D8. Specifically, the first argument to Url::fromUserInput() requires a leading slash (etc.) as described by that error.

But the function you're changing is already a patchwork mess and I don't want to make it even messier by pre-pending a slash where it doesn't belong. That section of code you're changing is simply checking to see if the path has a language prefix. You shouldn't be doing anything in there except checking then language prefix. You should leave $path untouched, like the original code did. Instead, try appending the slash to the first argument when calling Url::fromUserInput() and adding a comment to say why you need this.

But that's only part of what needs to be done in this function. All the custom parsing and piecemeal html-encoding needs to go and be replaced by Drupal utility functions or even PHP functions which can handle this in a standardized way so we don't have to maintain our own complicated and quite possibly buggy regular expression matching. Likewise, the function documentation needs to be specific and clear about WHAT this function is supposed to do. "format URLs" doesn't tell me anything I need to know to determine whether this is working correctly or not. And we don't have even a simple test case to check that URLs are "formatted" correctly by this function, so we have no way to knowing when it breaks or why it broke.

So bottom line is we do have a fix and I'll probably just move the slash like I suggested above, but this function really needs proper work and it would help a lot if someone who uses this module and needs this function spent some time cleaning up that mess and adding some tests. And that goes for all of the functions in the MimeMailFormatHelper class.

Needs test cases.

In patch with code:

- $path = implode('/', $args);
+$path = '/' . implode('/', $args);

It doesn't solve my problem. However, the following modification does:

 if ((strpos($path, '/') !== 0) && (strpos($path, '#') !== 0) && (strpos($path, '?') !== 0)) {
       $url = $path;
  } else {
       $url = Url::fromUserInput($path, $options)->toString();
  }

It's not the best patch in the world but it works.

But it's not applicable for 8.x-1.0-alpha6 so I've prepared patch for that specific version.

Patch solves the issue correctly as it matches the conditions where an InvalidArgumentException would get thrown to prevent those conditions from being met and resulting in the fatal error. Ie, here is the excerpt from the ::fromUserInput() method

if (!str_starts_with($user_input, '/') && !str_starts_with($user_input, '#') && !str_starts_with($user_input, '?')) {
  throw new \InvalidArgumentException("The user-entered string '$user_input' must begin with a '/', '?', or '#'.");
}

Thanks! Going to quickly convert it to a merge request, but since I'm not making any changes, just facilitating the maintainer's job, suggesting RTBC as status.

Nvm #4 not addressed, needs work

This was addressed in the 2.0.x branch using a try/catch statement as part of #3155325: Improve image detection. Perhaps better than this approach while silently fails? Closing as outdated. Thanks, everyone!