[Plugin: Live Blogging] How to avoid the_content of live_blog_entries

Actions to be unhooked when displaying live blog content

You’re sure that this is not a sign of bad coding quality from yourself?

Anyway… It doesn’t seem to work for filters…

I add a filter in my plugin

add_filter('the_content', array($this, 'injectIntoTheContent'),11);

and have it say “injectIntoTheContent” In your advanced settings… The filter still get’s executed. Might have something to do with the $this reference?!?

You’re sure that this is not a sign of bad coding quality from yourself?

It’s a workaround because people seem to want to use the_content to append things to the end of a post, and when a single page contains lots of short blog posts (which is what a live blog is – lots of very short posts on a single page), then this assumption that they’ve made falls down.

I strongly resent the accusation that the quality of the live blogging plugin code is bad, indeed applying the_content filter on content to be displayed to a user is almost certainly the right decision to make (otherwise people won’t be able to use plugins or shortcodes in blog posts, etc)

But yeah, there’s a bug there as the matching for filters to be unhooked only works on functions, not instance members.

What exactly are you trying to do – only filter the content of the first post on the page or something? the_content gets called exactly once for each post displayed – however there may be more posts on a page than you expect. If you only want to have the hook trigger once per view, then unhook it after the first time it’s been called.

The plugin I write attaches some text to the end of each post/page/attachment (read: user selectable post-type entity). If a user decides to attach this text on an entry from type “post” and this entity is also a liveblogging enabled item (read: contains the [liveblog] shortcode) the text is also applied to every liveblogging-entry that appears on this page. (because you invoke apply_filters on the_content)

My filter queries get_post_type() to check current post type and compares it to it’s stored values. When you execute apply_filters the post type is “post” and never your custom post type. So inside the filter it’s impossible to determine if it’s applied to post/page or a liveblog entry.

To unhook my filter would be no solution because it would apply to the first (liveblog)-post and wouldn’t be where expected. (Usually at the beginning or the end of each post/page that is not a liveblog-post)

people seem to want to use the_content to append things to the end of a post

What’s your suggestion on this? How would you append content to a post if not as a filter to the_content? I mean, It’s your concept of “nesting” posts or to be more precise, of nesting apply_filters that’s breaking it.

Actually why do you call apply_filters at all? You run it once for every liveblog_post and then it runs again for the complete post prior to display. That sound very unnecessary to me.

My filter queries get_post_type() to check current post type and compares it to it’s stored values.

That’s your problem – that isn’t guaranteed to give the correct results when using subloops.

What’s your suggestion on this? How would you append content to a post if not as a filter to the_content?

I normally edit the templates to accomplish this – appending to the end of every “the_content” call is far too blunt an instrument (especially on complex sites that uses subloops)

Actually why do you call apply_filters at all? You run it once for every liveblog_post and then it runs again for the complete post prior to display

Not always – when the AJAX or COMET updating is used, then it doesn’t get called on the complete post – only on the individual live blog.

Chris

Not always – when the AJAX or COMET updating is used, then it doesn’t get called on the complete post – only on the individual live blog.

Why can’t you enable this behavior for the non-AJAX/non-COMET part? That would solve all your compatibility issues with every other plugin at once!

I normally edit the templates to accomplish this – appending to the end of every “the_content” call is far too blunt an instrument (especially on complex sites that uses subloops)

Edit the templates to accomplish this is far too blunt an instrument (especially with the comfort and ease of the user in mind) So this discussion doesn’t get any further. Besides, the user already has the option to disable automatic injection of the code and modify it’s theme, but the majority of users are unfamiliar with this or simply want the one-click-does-it-all magic button.

Why can’t you enable this behavior for the non-AJAX/non-COMET part? That would solve all your compatibility issues with every other plugin at once!

Until the first time the JS goes off to poll the server (happens after about 5 seconds), or it connects to Meteor and gets the most recent updates, and rerenders the post and we’re back to square one.

Edit the templates to accomplish this is far too blunt an instrument

Want to run that by me again?

So this discussion doesn’t get any further

Please suggest to me a solution that works and I’ll consider it. Disabling the ability to use plugins, shortcodes, etc in live blog posts (which not rendering with the_content filer would mean) isn’t really an acceptable option.

As far as I see it, there are two solutions here:

* I fix the bug that stops instance members not being able to be excluded from rendering when rendering the_content for liveblog_entries (which I’ll probably do at some point)
* People who use our plugins together do a tiny bit more work by modifying the theme

Ultimately it comes down to the inflexibility of the WordPress API – if you could reliably run get_post_type when used in subloops (for example, if you could detect the loop my plugin uses to get the posts from the database), then this shouldn’t be an issue.