[Plugin: Custom Post Widget] Correction for properly invoking the_content()

Hi Hari,

Could you please post your code to pastebin so I can investigate this?

Many thanks,

Johan

Hi Johan,

https://pastebin.com/PgzGPn1g

Basically, I just declare the global $post and assign the query result. Otherwise other hooks which may affect the widget will be given the wrong post as the context (either the first or last post in the main loop if I remember correctly).

I then added wp_reset_postdata() afterwards as per what I read upon doing some research.

I couldn’t find a cleaner way of setting the global post without affecting other things…

Hi Hari,

I finally found some more information about this: https://www.mydigitallife.info/retrieve-and-get-wordpress-post-id-outside-the-loop-as-php-variable/

It seems that it is only necessary to use global $post; when trying to get post->ID. Since this is not used in the Custom Post Widget plugin, it should not be necessary to declare the global variable.

Also, get_post_type() == 'post' is not working for the content block, because the custom post type is content_block.

Sorry, it’s been a while, but let me see if I can remember…

The issue is that the plugin code runs the ‘the_content’ filter which executes other plugins’/hooks’ code. These other hooks might have a dependency on the global $post (perhaps indirectly via get_post_type()).

In order words you call apply_filter(‘the_content’, $content) on custom $content but the resulting filter code might check the global $post to get the post_type, leading to an inconsistency. This isn’t necessarily bad practice for plugin/theme devs. They may wish to process different post type’s differently.

Since you have no control over what the_content filter executes, the only way I can see to prevent this issue is to resolve the inconsistency by setting the global $post and then reset it when done. It’s pretty safe to do I think. Check out this post: https://club15cc.com/code/wordpress/wordpress-sub-queries-the-many-options-and-best-practices-wordpress

The only question then is whether you set the post_type to ‘content_block’ or to the original post’s content type. The former would prevent custom processing of content blocks emanating from different post_types. The later prevents theme hooks from distinguishing content blocks from posts. Perhaps a hybrid? post_type=’content_block_myposttype’

Hope this helps…