How to prevent filter from decoding HTML

  • Resolved Gooly

    (@gooly)


    7 years, 6 months ago

    I’m busy writing a small filter plugin which should provide the WP tagline / blogdescription with some extra surrounding HTML.
    So
    ‘Just another WordPress website’
    could be changed to e.g.
    <span style=”color:red;”>Just another WordPress website</span>

    It works, however the problem is that the HTML is encoded to entities, whereas I need it ‘raw’ in order for the browser to executed the HTML.

    This is what I have:

    add_filter( 'option_blogdescription', 'add_html_blog_description' );

function add_html_blog_description( $option_value ) {
    $option_value = '<span style="color:red;font-size: 45px;">'. $option_value . '</span>';
    return $option_value;
}
Viewing 4 replies - 1 through 4 (of 4 total)
  • Thread Starter Gooly

    (@gooly)

    7 years, 6 months ago

    I tried to avoid decoding to entities with different hooks like option_blogdescription and pre_option_blogdescription
    PHP html_entity_decode(), wp_kses(),
    Getting the content directly from the hook parameter, getting the content with get_option, getting the content with $wpdb->get_results
    But whatever I try or do, in the end my HTML shows up as entities.

    Moderator bcworkz

    (@bcworkz)

    7 years, 6 months ago

    Yeah, WP really doesn’t like HTML in that description. There is not a single solution. You literally need to override WP both coming and going. Almost any reasonable WP function involving options is going to try to encode your HTML.

    You need to first override what is saved to the DB, or more accurately, rewrite what was saved. Hook “update_option_blogdescription” and decode the passed value. Save the decoded value directly to the options table with $wpdb->update(). This avoids any attempts by WP to encode your HTML again.

    You also likely need to alter how your theme gets and outputs the description. If get_bloginfo() is used, switch to get_option(). Surprisingly, get_option() doesn’t try to encode HTML. Any good theme will run the value gotten from options through esc_html() or similar before output. This of course encodes HTML and would need to be removed.

    But we still need to escape output. If esc_html() is removed, something should be used to properly escape description output. wp_kses() is good for this. See the Plugin Handbook for more on using this function. You can essentially whitelist acceptable HTML and attributes. Any other potentially bad HTML is stripped.

    Thread Starter Gooly

    (@gooly)

    7 years, 6 months ago

    Thanks bcworkz.
    Yes, it’s hard to work around WP’s HTML fobia But with good reasons 🙂 I like WP’s security.
    Someone pointed me (elsewhere) to the fact that the tagline is used on several places, not only as tagline in the frontpage, but e.g. also with page <title> generation. This made me realize that it might not a good idea to work around it.

    So I decided to create a new custom field for it in Settings/General named: ‘Alternative Tagline’. This setting is also being ‘entitied’ before going to the database, but that is no problem. A simple PHP html_entity_decode() didn’t look too secure for me, so I decided to create a function to only decode ‘anchor related tags’

    finally the function needed to be implemented in header.php, so that was the point where the plugin changed to a child-theme.

    • This reply was modified 7 years, 6 months ago by Gooly.
    Thread Starter Gooly

    (@gooly)

    7 years, 6 months ago

    Resolved

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘How to prevent filter from decoding HTML’ is closed to new replies.