The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Link fields using the link module (drupal.org/project/link) are not being checked (both internal and external links).
When the function linkchecker_parse_fields() is called, the link markup added to the $text_items[] array doesn't seem to be valid for later checking in _linkchecker_extract_links().
Here is an example of what ends up being added:
<a href="<a href="http://drupal.org/a/broken/link/example">http://drupal.org/a/broken/link/example</a>">http://drupal.org/a/broken/link/example">http://drupal.org/a/broken/link...</a>
Instead of calling _filter_url() and then _linkchecker_check_markup(), would it make sense to call Drupal's l function instead? That way, both internal and external links are converted into valid markup which can be read by _linkchecker_extract_links().
Comments
Comment #1
hass commentedComment #2
hass commentedLet's try it this way: http://drupalcode.org/project/linkchecker.git/commit/76d2272
It seems difficult to re-use a formatting function like
theme_link_formatter_link_default()from link module.This fix also change logic; if urls are extracted compared to past code. In past all the link module fields have been forced to full qualified urls and therefore became "external", nevertheless it may was an internal link (e.g. "node/80") only. Now the internal/external url extraction is detected as in all other code.
Internal Drupal URLs with params like
node/80?foo=barhave also not been loaded with alias/drupal7/node-80-foo?foo=barproperly. This is required, because url() does not support relative URLs containing a query string or fragment in its $path argument. Instead, any query string needs to be parsed into an associative query parameter array in $options['query'] and the fragment into $options['fragment'].May should get a backport for consistency reasons...
Comment #3
hass commentedComment #4
ccarigna commentedTested the latest build and it works as expected. Thanks!