Forum Replies Created

Viewing 3 replies - 1 through 3 (of 3 total)
  • Ah, thanks for the response… It turns out that using the arrow key to change the selected version number will not update the reported broken count. The broken vote count only changes with a mouse click event and not with the keypress event.

    I’ve worked with Raw HTML, Raw HTML Pro and Raw HTML Snippets plugins. Personally, I think Raw HTML Snippets is the sure way to work with embedded html scripts. What makes [Raw HTML Snippets] work is you save the embedded html scripts separate from the post record. The embedded html scripts would be referenced via a short code which is added to the post itself.

    The process is a bit disjointed. However, it completely eliminates the step where WordPress filters out embedded html scripts within the post content. I like Raw HTML Pro because it works with markup directly in the post itself. The problem is there are scenarios where the scripts gets stripped out when toggling between visual mode and HTML mode in the post editor.

    The tough thing is sometimes toggling editor modes works and other times the embedded html scripts is stripped out. Raw HTML Pro used to work more reliably. Not sure if Raw HTML Pro has issues with recent WP upgrades or with other plugins I’ve installed.

    Regardless, I was considering writing a more reliable version of this plugin myself and was hoping RawR (Raw Html Revisited) would be a good alternative. I’ll let you know my thoughts on RawR if I can get it to work. I haven’t yet tested if it works yet. I’ll let you know about that as well.

    Thanks Again,

    David Carroll

    Hi Michael,

    I just came across the RAWR plugin myself and will be testing soon. You mentioned you marked the plugin as broken. As of today, this plugin has 0 for people who have reported this as broken.

    Did you retract your “broken” vote? Is this still an issue for you?

    Thanks for sharing your notes.

    David Carroll

    Hi jfache,

    Although it’s been 10 months since you asked this question, you and others may still be interested.

    The issue with your code is the get_post_meta filter accepts 4 arguments, which needs to be reflected in your code. The following code example should work if your theme supports Featured Images.

    /* Description: Custom function to prevent post thumbnails from loading on search, category, and archive pages.
         * @param string|array $metadata - Always null for post metadata.
         * @param int $object_id - Post ID for post metadata
         * @param string $meta_key - metadata key.
         * @param bool $single - Indicates if processing only a single $metadata value or array of values.
         * @return Original or Modified $metadata.
         */
        function remove_post_thumbnail($metadata, $object_id, $meta_key, $single){
    
            //Return false if the current filter is that of a post thumbnail. Otherwise, return the original $content value.
            return ( isset($meta_key) && '_thumbnail_id' === $meta_key ) ? false : $metadata;
    
        }
    
        //Specify 4 arguments for this filter in the last parameter.
        add_filter('get_post_metadata', 'remove_post_thumbnail', true, 4);

    A good way to review how this works is reviewing the get_metadata() function in the /wp-includes/meta.php file.

    Look for the apply_filters line:

    $check = apply_filters( "get_{$meta_type}_metadata", null, $object_id, $meta_key, $single );

    Notice the second parameter is null. This is the first parameter ($metadata) in the custom filter function: remove_post_thumbnail().

    If the filter function returns anything other than null, the get_metadata() function will exit early. This is reflected in the conditional block immediately following the apply_filter() line.

    Hope this helps.

    David Carroll

Viewing 3 replies - 1 through 3 (of 3 total)