Paul Gregory

Your taxonomy happens to be named the same as your posttype, with the same slug. Not everyone will do that.

/products/fluid-purification is using “products” as taxonomy (so it uses taxonomy-ps_product).
/products/page/2 is using “products” as posttype (so it uses archive-ps_product).

I have a custom post type (job) with three custom taxonomies (sectors, locations, type). I had pages that filtered by the taxonomy but which weren’t using archive-job.php. Finding your reference here to taxonomy-[whatever] was actually very helpful! Now taxonomy-sector etc work great for me.

As my taxonomies and posttypes are named differently, it is more obvious what is going on: the page that filters by taxonomy isn’t actually filtering by post type, it’s just coincidence that all the results are from one post type (although not an unexpected coincidence given that the taxonomy is exclusive to that posttype).

So there *is* a point to archive-{posttype}, and it’s the point you’d expect it to have.

To reiterate, the relevant template is selected based on the requested information, not on the results – and pay close attention to what’s actually requested.

I hope this helps someone.

—

Now, if there is a flaw here, it’s that I can use
/taxonomy/
or
/posttype/
but
/posttype/taxonomy/
doesn’t work (for me at least; not yet sure whether I’m missing something or WP is).

Obviously stevecoy doesn’t actually want to be using
/products/products/
but by using /posttype/taxonomy/ all the items would use the posttype archive as expected.

I can totally see how people may expect /taxonomy/ to return a /posttype/ template when the taxonomy is unique to that post type, because I fell into that trap myself.

That code only checks for IE, not specific versions of IE. Everything may work in IE8, but it probably doesn’t in IE6 or IE7. Rather than spend time changing perfectly valid output to work with IE idiosyncrasies, many plugin developers prefer to just get their plugin out there. Often they’re sharing something written for their own use.

The reason devs don’t like IE is because stuff doesn’t work in it. I doubt many stop IE usage just because of personal preference – it will be because they suspect some part of it won’t work in some significant way. Perhaps they tried a warning in an earlier release, but still got lots of support requests from IE users anyway.

You don’t have to use the plugin, the plugin author doesn’t have to make it work for your choice of browser. Those are the real choices here.

Market share is only relevant on the frontend. Stop IE users from seeing something and they’ll go elsewhere. Requiring a compatible browser for the backend is no big problem – if you need to use it, you can use it.

But you’ve found that one particular plugin does work in IE8. Great. Rather than label this a stupid act and rail about the trend here, why don’t you instead take some positive steps:
* Tell the developer it works in IE8.
* Suggest that the developer changes the check so that it allows IE8 usage.
* Offer to beta-test future plugin releases in IE8.

And for plugins that don’t work if you comment out the check:
* Figure out what the problem is, and solve it.
* Double-check that your solution doesn’t affect users of other popular browsers.
* Give the developer the fixes.

And for plugins that work in IE8 and don’t have a “please switch” screen:
* Thank them, pointing out you’re an IE8 user. This will help motivate their future IE8 testing.

See
https://www.scriptygoddess.com/archives/2007/12/04/next-previous-posts-in-same-category/
and
https://codex.www.ads-software.com/Template_Tags/next_post_link