Conflict with "Glossary"

I made some further tests.

Namely, I tried several other plugin that create custom post types and I coded a simple plugin that creates a CPT myself.

Then, I added some dummy posts of a custom type and none of them showed up in the glossary page.

I temporarily solved it in this ugly and inelegant way:

function my_exclude_category( $query ) {
    if ( is_post_type_archive('glossary')) {
        set_query_var( 'post_type', array('glossary') );
    }
}
add_action( 'pre_get_posts', 'my_exclude_category' );

I hope it helps

@enis, you can try to play with this function: https://github.com/garex/wp-testing/blob/7b2ef2ce8b5e8366c722da08827c82725ff0ffaf/src/Doer/PostBrowser.php#L14

May be something there will help.

But good fix should not know anything about polylang or glossary plugins.

@alexander, I don’t think the problem is there.

<blockquote> if ($query->is_archive() && !$this->isTaxonomyOf($query, 'wpt_test')) {
            return;
        }</blockquote>

In the glossary case, that function exits without doing anything.

The glossary plugin archive is absolutely standard and the same problem happens also with different plugin with CPTs.

How does wp-testing alter the standard wordpress loop?

I did more debugging.

The query in the glossary archives gets a ‘wpt_test’ post type injected, I don’t know where.

Here’s the post_type in the $wp_query:
Array
(
[0] => glossary
[1] => wpt_test
)

I cannot imagine how a plugin other than wp_testing could possibly inject such a thing.

Please, review your code, because this is not an issue that comes from another plugin.

Found the problem: your plugin tries to put its custom post type in more places than it should.

I modified this line: https://github.com/garex/wp-testing/blob/7b2ef2ce8b5e8366c722da08827c82725ff0ffaf/src/Doer/PostBrowser.php#L16

from
if (!$this->wp->isQueryMain($query) || $query->is_preview() || $query->is_attachment() || $query->is_search()) {

to
if (!$this->wp->isQueryMain($query) || $query->is_preview() || $query->is_attachment() || $query->is_search() || is_single() || is_post_type_archive() ) {

I suggest you refactor this part of code, because this is a recipe for disaster. You are forcing any other developer to deal with your custom post type and remove it deliberately from the main loop before it breaks their plugin—as it happened with me.

Instead of adding your post_type to the query everywhere, no matter what, regardless where you are, unless a limited conditions are met, do the opposite: do NOT add your cpt in the query anywhere but where it’s needed.

So, no

if($insufficient_conditions){
 return;
}

add_wpt_test();

but instead

if($I_need_wpt_test_here){
 add_wpt_test();
}

Come on, dude!

Don’t make people waste their time or shift blame towards other developers.

It’s your code that has a poor architecture.

@enis,

It’s impossible to do it’s in easy way as you suggest.

I disagree, that this is plugins poor architecture. Those piece of code is a try to add “custom post type” near usual posts. If you want to blame someone — blame wordpress and custom post type developers here.

I will research your suggestions. Please confirm, that conditions of issue is a combination of glossary + wp-testing + polylang.

No, @alexander, the problem is that you add “wpt_test” in the query of a “glossary” archive, and that should not happen.

Would you be pleased if the other plugin added ‘glossary’ cpts in ‘wpt_test’ queries and broke your plugin?

That’s why, in all these support threads, I see a lot of compatibility issues spawning from CPTs: as you do it for this plugin’s ctp archive, you do it for most of other plugins implementing CPTs in a standard fashion.

I also went ahead and coded a dummy plugin myself, in order to solve this issue, and got the same results.

Same happens with the other glossary plugins I’ve tried.

Same happened with other plugins I’ve tested.

Let me be perfectly clear on this matter: it’s your call, as a developer, to avoid messing around and keep your code play well with other plugins as much as you can.

If you mess with the standard wordpress loop everywhere, you are basically expecting every other developer to do backflips in order to clean up the mess you introduced in the wp query, and this is not acceptable, no matter how you try to convince me or our audience that it is.

Modify the query only when it’s sure that tests should be displayed, and nowhere else: not on single posts, not on archives of other categories, not on other taxonomies, nowhere else but where it’s needed.

You didn’t do it and you messed up with:

• wp-glossary
• glossary by code-at
• cm tooltip glossary
• Genesis builtin breadcrumbs
• a plugin I made ad hoc just for testing pourposes, using the most standard coding practice
• several other plugins with CPTs I tried
• a slay of plugins other people wrote about in this support forum

I suggest you take on this matter head on, because you have a compatibility issue so huge that also I could spot it, and I haven’t coded seriously for several years.

confirm, that conditions of issue is a combination of glossary + wp-testing + polylang.

I haven’t coded seriously for several years.

I also like simple solutions, but currently WP/cpt does not provide simple solution for the feauture, that this code tries to solve. Be patient ans start from the purpose of that code.

I can’t confirm that: even without polylang in the picture the Genesis Framework builtin breadcrumbs don’t work, as shown in the screenshots I provided.

The issues happens with wp-testing + a slay of cpts plugins I mentioned before.

If you cannot/don’t want to find a solution and prefer to blame other developers or WP, at least add a hook to that function, so other cpts plugins users can at least fix it elsewhere.

Allow me to repeat myself: the issue can be easily solved by using a different approach: instead of defaulting to add wpt_test to the main query post_args everywhere, devise where the tests should be displayed and then go with:

$condition_where_test_should_be_displayed = (is_home() && $test_must_displayed_on_homepage) || $is_a_test_taxonomy || $does_this_page_need_test_injected_into_post_args || $other_precise_and_strict_condition)
if($condition_where_test_should_be_displayed){
 add_tests();
} else {
 for($i = 0; $i < 1000; $i++){
  echo "I must leave the main WP query alone, because other developers are not required to take into consideration the fact that I inject my post_types into their archives! <br />";
 }
}

INB4: the genesis framework is the problem.

No: it’s arguably the best framework around. It costs a lot of money and it’s worth every single penny.

It works, it’s robust, well written, extensively documented, and the code has a lot of comments.

Now you know where the problem is and, let me tell you again: it is in your plugin. Not on wordpress, not on other people plugins, not on genesis, not on polylang. It’s really your plugin.

@enis, pls give me more clear issue conditions to play with.

Allow me to repeat myself:

It can not be solved in this simple way as WP dont’ give clear conditions for this. See how wp’s query works.

INB4: the genesis framework is the problem.

Now you know where the problem is and, let me tell you again: it is in your plugin.

Dont’ you think it’s a contradiction?

So I will not be able to repeat an issue without some paid framework? Don’t you think it’s strange?

Before you told me, that issue is in combination “wp-testing + glossary + polylang”, now you tell me it’s a “genesis framework” issue.

So can you finally confirm, that issue arise only in this combination: “wp-testing + glossary + polylang + genesis framework”?

My actual setup is polylang, + glossary + Psychological tests & quizzes running on Genesis.

The problem with Genesis happens regardless polylang.
The problem with polylang happens regardless the glossary plugin I use (glossary, wp-glossary, cm tooltip glossary).

I’m inclined to believe that you will experience the same problem with any breadcrumbs, not only genesis’, but this is a speculation.

In order to reproduce the problem, have polylang, + glossary + wpt-test deployed.

Set tests and glossary cpts and taxonomies in the polylang configuration page to be translated.

Create a couple of terms. Transalte them.
Create a quiz. Translate it.

You will see that the archive for the glossary terms displays tests, too.

You will also observe that, if you set the archive page to be in alphabetical order, it will still display the entries sorting them by date.

You don’t need genesis, in order to reproduce the error: it happens also on twenty sixteen.

The problem, as I told you before, is huge, therefore has several symptoms.

One of them is breaking Genesis breadcrumbs. It probably breaks other breadcrumbs.

The problem happens with glossary, but also with cm tooltip glossary or wp-glossary.

No genesis needed.