Conflict with watu pro exam plugin

Watu developer here, just to suggest the solution:

https://pippinsplugins.com/playing-nice-with-the-content-filter/

We plan to replace apply_filters with our own code in the next version to avoid issues like this. But it’s much better if other plugin developers follow the advice on the link rather than filtering the whole content ignoring the fact that other plugins might be working with the_content filter.

You’re more than welcome to suggest an actual solution to any bugs you find. Even reporting just the bug itself without a solution is great too.

After taking a quick scan of the Watu (not pro) plugin, I noticed that the plugin is calling the_content filter hook in a couple of different places. I imagine that’s where the “conflict” is. The problem with this is that the plugin is calling a WordPress hook that has very specific “definition” (for lack of a more appropriate word) in WordPress. Basically, plugins like Members and others expect this hook to be executed within The Loop with all the post-related functions available to us.

My guess is that Watu has this hook so that it can execute filters that normally are on the_content hook for some custom data it’s pulled from the database (outside of The Loop and without any post-related functions returning the correct data). Instead, Watu should be using a custom hook here and applying those filters to its custom hook. A simple example of this is something like the following:

add_filter( 'watu_custom_hook', 'wptexturize' );
add_filter( 'watu_custom_hook', 'convert_smilies' );
add_filter( 'watu_custom_hook', 'convert_chars' );
add_filter( 'watu_custom_hook', 'wpautop' );
add_filter( 'watu_custom_hook', 'shortcode_unautop' );
add_filter( 'watu_custom_hook', 'do_shortcode' );

I’m assuming the same issue is with the pro version of the plugin. I’ll be more than happy to take a look at it if you email me the code.

prasunsen, would you be willing to send Justin the WatuPro code?

We don’t apply custom hooks to the code. Watu/pro uses the_content because of the default WordPress filters – wpautop, do_shortcode etc.

As said above we plan to replace this with custom call in the future because too many membership plugins apply filters to the_content without limiting their filter to the main query. This will happen in few days.

We don’t apply custom hooks to the code. Watu/pro uses the_content because of the default WordPress filters – wpautop, do_shortcode etc.

We’ve already established that the plugin doesn’t do this. However, it should be doing it instead of using the the_content hook. The data in the plugin has nothing to do with post content.

As said above we plan to replace this with custom call in the future because too many membership plugins apply filters to the_content without limiting their filter to the main query. This will happen in few days.

The use of is_main_query() in the tutorial you linked to above is incorrect. is_main_query() will *always* return true when used like that. You can read a more in-depth explanation of the purpose of the conditional tag here:
https://core.trac.www.ads-software.com/ticket/23329#comment:3

Nevertheless, the_content is a hook used on the post content. The purpose of the *Content* Permissions feature in the Members plugin (and I’m sure in other membership-type plugins) is to actually filter the content regardless of whether it’s the main post query or any other post query. The Watu plugin isn’t actually querying any posts. Therefore, the_content should never be called.

I’ll be more than happy to help explain this in further detail if needed and help you with any corrections in the Watu plugin.

“We’ve already established that the plugin doesn’t do this. However, it should be doing it instead of using the the_content hook. The data in the plugin has nothing to do with post content.”

Well, no. Users want formatting, filters, and shortcodes they use in posts to be available in the output that Watu generates (questions AND results/final screen). So the_content is exactly what we need.

This is not going to go anywhere so I am out of the discussion.

If you’re not willing to listen to my advice and take the free help that I’m offering you, I suppose it’s not going anywhere. Feel free to get in touch with me any time you want if you need help. I’ll be more than happy to discuss this further and explain it in more detail if you want.

Yet in the first message I wrote “We plan to replace apply_filters with our own code in the next version to avoid issues like this”. I will be applying the filters one by one exactly like in your example (or almost). I don’t need help with this. I just disagree that it’s OK to apply filters to the_content without checking what is this content first. But it’s OK, your plugin is not the only one that does it so we’ll have to live with this and change our code. Maybe I’m wrong, it doesn’t matter. I know how to solve it don’t need help. Thanks for your offer.

Thank you both for your time on this question. I greatly appreciate both plugins, and I am disappointed that they don’t play nicely together. Will look forward to Watu update.