Problem/Motivation

In the entity_mesh module we implemented logic (in the context of issue #3556625) to detect and skip “bad build” URLs before processing them.

The current URL format check is too strict. Some URLs that actually work in the browser are being detected as invalid, mostly because they contain spaces or other characters that are not strictly RFC-compliant but are still accepted by the target site or by upstream systems.

When a URL is identified as “invalid format” by this logic, the corresponding item is skipped and its URL is not processed at all. On sites where there are many links with spaces or similar formatting quirks, this creates a large number of effectively broken links within the entity_mesh processing result: the links exist and work, but they are not analyzed or included because they were filtered out too early.

We therefore need to relax the runtime “bad build URL” check and move strict validation closer to the moment when URLs are stored in the database.

Steps to reproduce

Enable and configure the entity_mesh module.

Create or import content that contains links with spaces or slightly malformed formatting, for example:

A node with a link field pointing to https://example.com/page with spaces.

A URL imported from an external source that is not fully URL-encoded but is still reachable in the browser.

Run the entity_mesh analysis/build process (e.g., via the module’s UI or Drush command, depending on how the project is set up).

Observe the results:

  • URLs containing spaces are flagged as “invalid format” by the current logic.
  • These URLs are skipped and not processed further.
  • The resulting mesh/link graph is incomplete, and many links that actually work in the browser appear as missing or “broken” from the module’s perspective.

Expected result:

  • All URLs that resolve correctly in the browser are processed by entity_mesh, even if they contain spaces (or similar issues), or at least they are not silently skipped.

Actual result:

The strict format validation marks these URLs as invalid and prevents them from being processed, leading to many unprocessed (effectively broken) links in the module’s output.

Proposed resolution

Relax the runtime URL format check (“bad build” logic)

Adjust the validation that currently rejects URLs based solely on strict format (e.g. presence of spaces).

Options:

  • Automatically normalize/encode URLs before checking them (e.g. convert spaces to %20) instead of rejecting them outright.
  • Treat non-encoded spaces and similar minor issues as “warnings” rather than hard errors, so the URL is still processed.
  • Only treat clearly malformed URLs (empty, missing scheme, obviously invalid patterns) as fatal and skip those.
  • Separate “storage validation” from “runtime analysis filtering”
  • Introduce validation when URLs are stored (e.g. when saving the entity, when importing links into the entity_mesh table, etc.).
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

lpeidro created an issue. See original summary.

lpeidro’s picture

To avoid false broken links caused by spaces or special characters in the URL, we sanitize the URL before running the validation.

// Encode problematic characters before validation for all URLs.
    // Replace spaces with %20.
    $href_to_validate = str_replace(' ', '%20', $href);
    // Encode non-ASCII characters.
    $href_to_validate = preg_replace_callback('/[^\x20-\x7E]/', fn($m) => rawurlencode($m[0]), $href_to_validate);

Additionally, we manage the URL length to prevent issues when inserting it into the database if it is too long.

It is now ready for validation.

lpeidro’s picture

Status: Active » Needs review
albeorte’s picture

Status: Needs review » Reviewed & tested by the community

The behavior has been checked and is working as expected!

lpeidro’s picture

Status: Reviewed & tested by the community » Fixed

Issue merged.

Now that this issue is closed, review the contribution record.

As a contributor, attribute any organization that helped you, or if you volunteered your own time.

Maintainers, credit people who helped resolve this issue.

Status: Fixed » Closed (fixed)

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