Support » Fixing WordPress » Custom field in href attribute of target anchor becomes malformed

  • Resolved Tharkon

    (@tharkon)


    When using a custom field as href attribute in an anchor element that also contains a target attribute the custom field becomes malformed upon saving. I should note that this happens regardless of the contents of the target attribute.

    Example:
    <a target="_blank" href="$$custom_field:link1$$">example</a>
    becomes:
    <a target="_blank" href="link1$$" rel="noopener noreferrer">example</a>

    Some examples that are not affected by the bug, though may not be valid HTML:
    <img target="_blank" href="$$custom_field:link1$$">example2</img>
    <a id="_blank" href="$$custom_field:link1$$">example3</a>

    I understand the reasoning behind the addition of rel=”noopener noreferrer” but whatever mechanic is used to add this attribute also seems to be corrupting the contents of the href attribute.

    I have tested this problem using the 2020 theme with no plugins active to make sure that it was not caused by any plug-in.

    I can also add that this happens regardless of wether or not the rel=”noopener noreferrer” was already present.

    EDIT: It seems the bug also affects this support forum.

    • This topic was modified 1 month, 1 week ago by Tharkon.

    The page I need help with: [log in to see the link]

Viewing 4 replies - 1 through 4 (of 4 total)
  • Joy

    (@joyously)

    The code is in wp_targeted_link_rel(). https://developer.wordpress.org/reference/functions/wp_targeted_link_rel/
    Your original href is not valid HTML, so it’s not surprising that it would be messed up. The img tag is not a link, so it is not affected. (also not valid HTML) The link you gave that was unaffected is because it doesn’t have a target attribute.

    I do not think the href attribute has requirements to it’s content to be valid HTML.
    Even if it had, the link1$$ it resolves to probably is not valid either.

    And either way, WordPress should not try to fix invalid HTML, the img element was not valid, and it left that unaltered.

    I’ll dig into that function to see if I can find the cause, but I do still believe that this is a bug because that function should be changing the rel attribute and not the href attribute.

    Joy

    (@joyously)

    It’s not that WP is trying to fix invalid HTML, it’s that the function uses a regular expression to parse the link, so having characters in the href that don’t belong can mess up the result.
    The img element is not processed, because it’s not a link. The function only handles links that have a target attribute.

    Having dug deeper into the function you pointed me to I noticed two things.

    First, the functions as represented on
    https://developer.wordpress.org/reference/functions/wp_targeted_link_rel/
    and
    https://developer.wordpress.org/reference/functions/wp_targeted_link_rel_callback/
    are not actually how they are in the current version of WordPress.

    Specifically, the current version of wordpress includes a call to wp_kses_hair().
    And it this function that causes the problem.
    For it seems wp_kses_hair() uses list of allowed protocols, which you can find here:
    https://developer.wordpress.org/reference/functions/wp_allowed_protocols/

    So it is indeed not a bug, but a feature, though not because of it being invalid or because the regex can’t handle it, but because WordPress specifically only allows certain protocols, which are recognized by their colon, so in this case $$custom_field is treated as an unallowed url-protocol.

    Therefor the solution in my case was the following code added to functions.php, though I now probably should go and recommend the author of the plugin that makes uses of these custom fields to add it to their plugin’s code.

    add_filter( 'kses_allowed_protocols', 'dzb_allow_custom_field_protocol' );
    function dzb_allow_custom_field_protocol( $protocols ) {
    	$protocols[] = '$$custom_field';
    	return $protocols;
    }
    • This reply was modified 1 month, 1 week ago by Tharkon. Reason: Better name for custom function
Viewing 4 replies - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.