Publisher does not support the Fluid field type. Please do not contact asking when support will be available.
If you purchased an add-on from expressionengine.com, be sure to visit boldminded.com/claim to add the license to your account here on boldminded.com.
Ticket: When a channel entries loop has a search in it, publisher is not joining the field it needs to
Status | Resolved |
Add-on / Version | Publisher 3.1.5 |
Severity | |
EE Version | 5.3.2 |
EEHarbor Testing
Sep 28, 2020We’re having an issue where we are using search on a channel entries loop, which looks like this:
{exp:channel:entries channel="resources" limit="5" search:feature_homepage_slideshow="=Yes" orderby="date" sort="desc" disable="categories|member_data|pagination"}
...
{/exp:channel:entries}
If we remove this it works fine:
`search:feature_homepage_slideshow=”=Yes”`
This is the query it generates:
SELECT `ct`.*, `t`.*, `channel_title`, `c`.`channel_name`, `c`.`channel_url`, `c`.`comment_url`, `c`.`comment_moderate`, `c`.`channel_html_formatting`, `c`.`channel_allow_img_urls`, `c`.`channel_auto_link_urls`, `c`.`comment_system_enabled`, `username`, `m`.`email`, `m`.`screen_name`, `m`.`signature`, `m`.`sig_img_filename`, `m`.`sig_img_width`, `m`.`sig_img_height`, `m`.`avatar_filename`, `m`.`avatar_width`, `m`.`avatar_height`, `m`.`photo_filename`, `m`.`photo_width`, `m`.`photo_height`, `m`.`group_id`, `m`.`member_id`, `ct`.`url_title` AS default_url_title, `ct`.`status` AS status, `t`.`title` AS title, `t`.`site_id` AS entry_site_id FROM (`exp_publisher_titles` AS t) JOIN `exp_channel_titles` AS ct ON `ct`.`entry_id` = `t`.`entry_id` JOIN `exp_channels` AS c ON `c`.`channel_id` = `t`.`channel_id` JOIN `exp_members` AS m ON `m`.`member_id` = `t`.`author_id` WHERE `t`.`entry_id` IN (32988, 29248, 23315, 22165, 18634) AND `t`.`status` = 'open' AND `t`.`lang_id` = 1 AND ( exp_publisher_data_field_50.field_id_50 = 'Yes' )
The issue appears to be that it adds the publisher query, but never joins on the table. If I manually run that query it doesnt work, but if I add this to the list of joins:
JOIN `exp_publisher_data_field_50`
ON `exp_publisher_data_field_50`.`entry_id` = `t`.`entry_id`
it does work.
I should also mention that this is an EE2->5 upgrade and I have run the migration scripts and the table exp_publisher_data_field_50 does exist and has data in it.
BoldMinded (Brian)
Sep 28, 2020
Thanks for the detailed report. It’ll be a couple days until I can look into this. If you wanted to poke around though the issue is probably in the EntryQuery.php->generateSearchFieldSql() function.
EEHarbor Testing
Sep 28, 2020
Awesome, thanks for the quick reply and pointing me in that direction. Looking into that section of the code, I am seeing that line 309 does set the $joins variable, and it has the correct join in it.
It then checks to see if the join is not empty, and I think this is where the issue happens. It is trying to str_replace ‘WHERE’ with $joins . ‘WHERE’ in the $sql variable. The issue here is that $sql is initialized as an empty variable right before this, so it never uses the data from the joins:
I’m honestly not sure where to get this join back into the query, but this is definitely where the issue stems from.
EEHarbor Testing
Sep 28, 2020
Hey Brian,
I dug a little further and did find a pretty good solution for this. Up to you how you want to implement a fix, but this seems to work well. First I passed $sql into the generateSearchFieldSql() function, and assigned the entire output to the $sql variable. I then removed the $sql = ‘’; line. From there, everything seems to work.
I also searched my entire EE site (including all of the publisher code) to see if anything else uses that function, and luckily that is the only place it’s used.
Here’s my patch for the fix:
Thanks,
Matt
BoldMinded (Brian)
Sep 28, 2020
That is actually pretty similar to what I have in my local environment. I might have already fixed this recently? Try this:
BoldMinded (Brian)
Sep 28, 2020
EEHarbor Testing
Sep 28, 2020
I think that’s what I started with. The issue is here:
Since $sql is empty there, there is no WHERE to replace, so the join never makes it past that point.
BoldMinded (Brian)
Sep 28, 2020
I totally ready your diff backwards (the -/+ lines). I see the issue and fix now 😊
Thanks for catching it and providing the fix! I’ll make sure this is in the next release.
EEHarbor Testing
Sep 28, 2020
No problem! Unfortunately I did just discover an issue with doing it this way (at least the fix wasnt released yet lol). If that join is already in the query, it will be in there twice, which is obviously a mysql no-no… Just generated this query:
Where we have two identical joins on exp_publisher_data_field_94. I guess it has to check if its in the query first before replacing…
EEHarbor Testing
Sep 28, 2020
FWIW, this was my workaround for the double join in the query:
BoldMinded (Brian)
Sep 28, 2020
I was just looking at something similar, could add it to the previous conditional though:
EEHarbor Testing
Sep 28, 2020
Yeah I thought about adding it there, but added a new conditional because I was testing different things; it’s all the same thing in the end.
BoldMinded (Brian)
Sep 28, 2020
Ok, I’ll go with this combined conditional for cleanliness. Thanks again for testing and fixing this 😊
I’ll go ahead and close this out, but if you find something else just re-open the ticket.