Steps to reproduce
- create an entity type that includes AJAX calls on the node edit form, e.g. node with a link field and a media field, or a field with multiple elements and "add another" links
- as a user without the 'link to any page' permission, try to create an instance of that entity
- enter an invalid path in the link field, e.g. 'foo'
- click on the button that initiates an AJAX request, e.g. file upload, add another
Expected result
An error message should appear about the invalid internal path, but you should be able to proceed with the action
Actual result
It isn't possible to proceed.
The AJAX call responds with a 500 error "The internal path component is invalid. Its path component must have a leading slash" with field widget type "Link".
↵An AJAX HTTP error occurred.↵HTTP Result Code: 500↵Debugging information follows.↵Path: /fr/node/6/edit?element_parents=field_test/widget/0&destination=/admin/content&ajax_form=1↵StatusText: 500 Service unavailable (with message)↵ResponseText: The website encountered an unexpected error. Please try again later.InvalidArgumentException: The internal path component 'test' is invalid. Its path component must have a leading slash, e.g. internal:/foo.
This error generates from \Drupal\Core\Url::fromInternalUri
It happens from \Drupal\link\Plugin\Field\FieldWidget\LinkWidget::formElement
in code
$item->getUrl()->access() (core/modules/link/src/Plugin/Field/FieldWidget/LinkWidget.php:175)
For avoidance of this error we have next element validator where check input values
\Drupal\link\Plugin\Field\FieldWidget\LinkWidget::validateUriElement
So we can't catch this error on common entity save operation.
But we can catch it with any additional ajax buttons, which skip validation with #limit_validation_errors
It appears on all browsers.
In my example "foo" value is incorrect for Link field. We can avoid this error by putting only correct values. But customer can be confused. He doesn't know what values are correct, and he doesn't know why all his AJAX buttons don't work. So we should avoid 500 error with ajax buttons.
I have investigated this issue and found, that we need to add additional check in \Drupal\link\Plugin\Field\FieldWidget\LinkWidget::formElement
I have prepared patch and I will apply it in comment.
Issue fork drupal-2943135
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
kalistos commentedComment #3
kalistos commentedComment #5
andypostComment #6
zahord commentedHi, I was checking using 8.6.x and couldn't reproduce the issue using a link field and file field with ajax process
Comment #8
egruel commentedHi, I couldn't reproduce the issue usin wiht the admin user but i have reproduce this issue with a not admin user, and the patch fix the problem.
Comment #9
mangesh.borukar commentedAbove patch not working with Drupal 8.6.1, created a new patch to handle this issue.
Comment #10
mangesh.borukar commentedComment #11
mangesh.borukar commentedComment #12
mangesh.borukar commentedComment #13
mangesh.borukar commentedComment #14
mangesh.borukar commentedComment #15
mangesh.borukar commentedComment #16
malcomio commentedComment #17
malcomio commentedAs far as I can see from a quick test, the patch addresses the issue described, but it also seems to remove the URL validation - with the patch applied, I was able to create a link to a non-existent local path
Comment #18
malcomio commentedComment #19
malcomio commentedI haven't been able to reproduce this issue on a clean 8.6.x install.
However, the issue does exist on our project (which is built from an install profile with numerous contrib and custom modules enabled).
Need to clarify the steps to reproduce.
Comment #20
malcomio commentedComment #21
malcomio commentedIn our project, granting the 'link to any page' permission to the relevant user roles seems to prevent this error from occurring, but the underlying error should still be addressed - a missing permission shouldn't cause a 500 error on an AJAX request.
Comment #22
malcomio commentedComment #28
siemen_hermans commentedProviding a patch for Drupal 9.2.x
Comment #29
dhirendra.mishra commenteduploading against 9.3.x
Comment #31
bgreco commentedModified the failing test so it passes with patch #29
Comment #32
bgreco commentedComment #35
smustgrave commentedTested this without the patch following the issue summary steps
Created a user without the "Link to any page" permission
Added a link field to a content type with unlimited setting
Logged in as said user
Created a node by adding foo into the url
Clicking Add another did not generate a 500 but just highlight the url field as error.
If you're still seeing the issue can you provide an updated issue summary and testing steps about where you are seeing it please.
Comment #37
stefan.kornSo, maybe this issue can not be triggered directly via Drupal core, but there are cases where the issue occurs (see related issues).
and absolutely agree with #21
Proposing a patch that roughly does the same as the previous patches but only operates in the LinkWidget class. not sure why the LinkAccessConstraintValidator class was touched in the previous patches. Does not seem necessary to fix the problem given in this issue.
Comment #39
stefan.kornComment #40
stefan.kornComment #42
stefan.kornComment #43
Manoj Raj.R commentedComment #44
smustgrave commentedTried retesting and still not seeing the error.
Tagging for tests as we will need a scenario that shows this issue.
Comment #46
nlisgo commentedI'm going to attempt to add a test for this.
Comment #47
nlisgo commentedI'm trying to recreate the issue on 11.x and I have been unable to. Please can someone who can recreate it provide clearer instructions please.
Comment #48
andypostSometimes it's easier to create new MR from previous diff
Comment #49
nlisgo commentedComment #50
bwaindwain commentedI think this has been fixed in 10.2.1. See https://www.drupal.org/project/drupal/issues/3340154.
Comment #51
malcomio commentedAs per #50, I think this is a duplicate of #3340154: Link-widget throws exception when rebuilding a form with an invalid uri