Convert local absolute menu links to relative to enable access checking & site portability

If a user logs onto http://www.example.com and there is a menu item which links to http://sub1.example.com - how is the menu system going to know whether the user (anonymous or logged on user) has access to the URL ? Of course, you can check if the URL is in any affiliated domain or in same domain as an alias, but how do you plan to check if user can access ? The only way I can see that you would be able to do this is to allow the menu item to have a configuration where roles can be added, and then the roles can be setup, just like nodes and blocks can have roles to determine access (assuming a roles based access control module is being used).

I think I like point 1 and 2 of the proposed solution, which in fact is a feature request. On my D6 site repetitively users put full URLs that in fact should be internal. This causes great trouble in our sandboxes where these links point to production site (sandboxes and production don't have the same domain).

Average users do not know how to handle absolute and relative paths. Paths are part of command line culture and most users belong to GUI culture.

I think that when an absolute path is entered that points to an internal page, then it should be automatically changed to a relative (with Ajax?).

Point 3 is not needed, because Drupal takes care of that already. Internal menu links that point to un authorised content will not appear in a menu. That is another reason to automatically change the path to an internal path, because external paths will appear always, no matter if the user is authorised.

Deleted second submission because of missing server response.

Not sure how this falls into DX, so removing that tag for now.

I'm in agreement with #4. Rather than propagating the problem (of moving the site to a different environment/domain and having links break), the absolute links should be converted to relative. Proposal updated.

If so, apply all access checks and controls similar to if the URL was entered as an internal path.

I crossed this out because it should no longer be necessary with the change. Or am I missing something?

Better title (as it's now worded as a feature request), and also added the site portability issue to the IS.

Problem is:

Exception: Error: Call to a member function getCurrentRequest() on null
Drupal\menu_link_content\Form\MenuLinkContentForm->reformatInternalLinkIfEnteredAsExternal()() (Line: 139)

It seems like $this->requestStack isn't defined, but it should be coming from FormBase. I'll add a local class variable to work around the problem.

Looks like FormBase::getRequest is the better option as it sets the request stack if it hasn't been set yet.

I've tested this patch and it works as documented.

This latest update is:

• much simpler,
• keeps extra URL info after the path (e.g. fragments & parameters), and
• works with subsites (e.g. https://example.com/site1/path).

This works as desired, except for the case where I put in the domain of the site itself, in which case:

• The "link" field in the form gets saved as an empty string.
• The link now works, but
• The edit form for this link can no longer be saved (validation fails because the "link" field is blank).

If I put a slash in the "link" field, it gets automatically replaced with a "<front>" token. Presumably, that's the behaviour we would prefer when the domain of the site is entered.

Thanks for finding that one. This latest patch seems to handle it, and still works for subdirectory sites.

Thanks, I've tested and this fixes what I saw in #22. Everything else we've tested looks fine to me.

All looks good so setting back to RTBC! Tests failure is not related (see #3055648: Frequent random fail in \Drupal\Tests\media_library\FunctionalJavascript\MediaLibraryTest).

Happened again.

I suppose we need to wait for that one then?

Trying again as one possible cause of the problem was fixed.

Looks like more unrelated test failures. Trying again.

Thanks for filing this feature request. It looks really useful. However in order to commit a feature we need an automated to test to prove that the feature works and ensure that we don't break it in the future. For more information about writing tests in Drupal 8 see the following links:

1. https://www.drupal.org/docs/8/testing
2. https://api.drupal.org/api/drupal/core%21core.api.php/group/testing/8.7.x

Indeed! Before getting to those, I just wanted some feedback letting me know that I was on the right track. Thanks for confirming that.

I may not get to this for a while as some other priorities have come up. Feel free to work on the tests, folks.

I'm not sure this is the right place for this, and I might open a new issue for this instead, but I just wanted to chime in on using relative URLs.

My problem with using /relative URLs in the Menus is that it only looks for *node* aliases, not also View aliases. I had to explicitly use the absolute URL when pointing to a view while testing (before using the Menu settings in the view).

This is also the case where a second menu needs to link to the same pages, and if they're Views, a relative URL won't work; it completely breaks the site.

Nevermind, it was a different problem.