Problem/Motivation
When Drupal is served from a subdirectory (i.e., the base path is not /, for example, /corporative), the Entity Mesh module incorrectly reports broken links for internal URLs. The module seems to be including the base path in its URL processing, leading to false positives when validating links that are inherently correct relative to the site's root.
Steps to reproduce
- Set up a Drupal site where the base path is not the root (e.g., install Drupal in a subdirectory like
public_html/corporativeand configure the web server accordingly. - Ensure the
entity_meshmodule is installed and enabled. - Create content with internal links (e.g., links to other nodes or entities) using relative paths.
- Build the mesh and observe the Entity Mesh's reporting of broken links.
- Notice that links that are valid when accessed directly in the browser (considering the base path) are flagged as broken by
entity_mesh.
Proposed resolution
The proposed resolution is to modify the way entity_mesh processes URLs. If the Drupal base path is not /, the module should strip or ignore this base path segment when resolving or validating internal links. This would ensure that the module's link validation accurately reflects the actual accessibility of the links within the Drupal installation, preventing false positives.
Specifically, when working with a URL, first determine if the site's base path is present at the beginning of the URL string. If it is, remove that base path segment before proceeding with link validation or entity resolution.
Remaining tasks
- Create a MR with the proposed solution.
Issue fork entity_mesh-3531237
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
juanjolComment #3
juanjolComment #8
juanjolComment #9
juanjolI just realized I haven't added tests to the MR. I'm going to generate them and add them to the issue before it's reviewed.
Comment #11
juanjolComment #12
juanjolNow tests are added and passing.
Comment #13
lpeidro commentedHello Juanjo,
Thank you for your contribution; it is really great.
However, I have some doubts regarding the point where you implemented the logic to remove the base path. Before checking the link with the "router.no_access_checks" service, we try to use other, more efficient methods to retrieve the link data—for example, by checking directly in the alias table.
Perhaps the correct place to remove the base path is when the path property is set in the Target object, specifically in the "processHrefAndSetComponents" method of the "Target" class.
This is just a question, as I am not sure what implications this change might have.
Comment #14
lpeidro commentedComment #15
juanjolHi lpeidro, I think the logic is in a much better place now, thanks for your suggestion! It's ready for another review.
Comment #16
lpeidro commentedI have made some code changes to inject the RequestStack service into the target object, following the coding standard. As a result, I also updated the unit tests.
Comment #17
juanjolI've tested the changes you made and everything is working as expected. I think this is ready to be set to RTBC
Comment #18
lpeidro commented