Entry status not honored when set as element query criteria

[ryanfoote]

Describe the bug

Plugin, by default, pulls all entries regardless of status, ignoring Craft's default of only displaying "live" entries. Explicitly setting the status as an element query criteria does not seem to change the behavior.

To reproduce

{% set entryQueryCriteria = craft.entries.limit(10) %}
{% set moreProperties = craft.similar.find({
    element: entry,
    context: entry.category,
    criteria: entryQueryCriteria
}) %}

☝️ This snippet will pull all entries, regardless of status, ignoring Craft's default of pulling only entries with the "live" status.

{% set entryQueryCriteria = craft.entries.limit(10).status('live') %}
{% set moreProperties = craft.similar.find({
    element: entry,
    context: entry.category,
    criteria: entryQueryCriteria
}) %}

☝️ This snippet will pull all live, disabled, pending, etc. entries although we are specifying in the element query criteria that only "live" entries should be returned.

Expected behaviour

Expectation is that, without specifically defining the status of the elements that should be returned, only entries with the "live" status would be returned. If the status is defined as an element query criteria, the specified status values should be respected.

Versions

• Plugin version: 1.1.4
• Craft version: 3.6.15

[khalwat]

hmmmm I'm not sure why that'd be the case, given that we ask for the default query, and the configure it with whatever criteria you pass in:

https://github.com/nystudio107/craft-similar/blob/v1/src/services/Similar.php#L226

Have you tried doing:

{% set entryQueryCriteria = craft.entries.limit(10) %}
{% dd entryQueryCriteria %}

...to see what status is set to going in?

[ryanfoote]

I hadn't, but here's what status is set to:

[status] => [
    0 => 'live'
]

[khalwat]

Yeah so if that's part of the query... I don't see how this could be happening. Nowhere in the code that I can see from glancing it over do we change the status passed in at all.

https://github.com/nystudio107/craft-similar/blob/v1/src/services/Similar.php

Will have a bit more of a look.

[khalwat]

So I'm unable to reproduce this locally -- are you sure there isn't a plugin or module that might be modifying these queries in some way?

[ryanfoote]

I don't think so. The only plugins I have installed are:

"aelvan/inlin": "^2.1",
"craftcms/postmark": "^2.1",
"craftcms/redactor": "2.8.7",
"misterbk/mix": "1.5.2",
"nystudio107/craft-minify": "^1.2",
"nystudio107/craft-similar": "^1.1",
"superbig/craft3-mobiledetect": "1.0.2",
"vaersaagod/dospaces": "^1.1"

I'll move this into our staging environment, too, to see if I can duplicate it there. If it makes any difference, I'm running on Nitro 2.x (PHP 7.4) and using MariaDB in lieu of mySQL since it doesn't run on M1 Macs, yet.

[khalwat]

Well, MySQL does run natively on M1 Macs, but you have to use the official Oracle image.

Anyway that's really weird, I don't see any plugins there that should affect anything. Maybe we can do a screen share or you can drop me a database or such?

[ryanfoote]

Sorry it took me a few days to get back to this.

So, I have it up in our staging environment and the original bug isn't an issue there. The only notable difference between my dev environment and staging is that dev uses mariadb and staging uses mysql. Outside of that, I've been using nitro locally and it is plagued with a litany of issues, so maybe there's something going on there. Or, maybe it is some sort of issue between Craft and mariadb?

All supposition, but long story short, seems that the original issue I reported isn't an issue that affects the plugin itself.

[khalwat]

@ryanfoote very likely local dev related.

As for your Nitromare, you could also roll your own Docker setup for local dev: https://nystudio107.com/blog/an-annotated-docker-config-for-frontend-web-development