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

  1. Set up a Drupal site where the base path is not the root (e.g., install Drupal in a subdirectory like public_html/corporative and configure the web server accordingly.
  2. Ensure the entity_mesh module is installed and enabled.
  3. Create content with internal links (e.g., links to other nodes or entities) using relative paths.
  4. Build the mesh and observe the Entity Mesh's reporting of broken links.
  5. 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.
Command icon 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

juanjol created an issue. See original summary.

juanjol’s picture

Issue summary: View changes
juanjol’s picture

Version: 1.0.x-dev » 1.x-dev

juanjol changed the visibility of the branch 1.x to hidden.

juanjol changed the visibility of the branch 3531237-false-positives-for to hidden.

juanjol changed the visibility of the branch 3531237-false-positives-for to active.

juanjol’s picture

Status: Active » Needs review
juanjol’s picture

I 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.

juanjol changed the visibility of the branch 3531237-false-positives-for to hidden.

juanjol’s picture

Status: Needs review » Needs work
juanjol’s picture

Status: Needs work » Needs review

Now tests are added and passing.

lpeidro’s picture

Hello 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.

lpeidro’s picture

Status: Needs review » Needs work
juanjol’s picture

Status: Needs work » Needs review

Hi lpeidro, I think the logic is in a much better place now, thanks for your suggestion! It's ready for another review.

lpeidro’s picture

I 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.

juanjol’s picture

Status: Needs review » Reviewed & tested by the community

I've tested the changes you made and everything is working as expected. I think this is ready to be set to RTBC

lpeidro’s picture

Status: Reviewed & tested by the community » Fixed

  • lpeidro committed f87be9fd on 1.x authored by juanjol
    Issue #3531237: Added base_path control on broken links inspection
    

Status: Fixed » Closed (fixed)

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