Enis

It doesn’t work for me either.

Please, reopen the issue.

Sweet. Thanks!

Thanks

There you have it.

I noticed you’ve rolled out an update.

The plugin broke again and I had to re-edit that line.

Can you please patch this bug as I suggested, in order to provide at least a temporary solution, until you find a more permanent one?

I would say something like “Replace search result with glossary terms” or something like that but, hey, I’m Italian. Don’t rely on my fluency ??

I think the wording used there are deceiving.

Add Glossary Terms post type in the website search

“Adding” implies that what was there before would remain, whereas everything else disappears, if I activate that option.

Anyway, that fixed the problem.

Thank you very much ??

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.

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.

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.

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 />";
 }
}

@daniele and @igenius, yes, it’s totally insane indeed: I’ve just discovered that the wp-testing plugin injects ‘wpt_test’ post_types in the main WP query virtually everywhere (besides few exceptions), thus breaking the archives of your glossary entries, the archives of every other glossary entries I’ve tried, the archives of
any polugin with a basic implementation of CPTs
and also the Genesis Framework builtin breadcrumbs.

After a week or so on this matter, with the developer blame-shifting his way out of dealing with this issue, I finally discovered where the problem was.

He ended up blaming WP and CPTs developers -_-

Thanks for your support! ??

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.

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.

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.