I’m not sure what would cause you to be getting different results now, b/c the latest version of Publisher Low Search didn’t change any behavior, it was just an upgrade to change how it got the language and status variables from Publisher.

Can you please provide more details? Perhaps the template tag you’re using (without any extra html markup), the results you’re currently getting, and the results you expect to get?

It’s been awhile since I’ve done anything with the search: parameter. This may be one where I’ll have to replicate the issue locally so I can debug it properly. I’ll try to get back to you early next week, or sooner, if I can find time this weekend to take a look at it.

If it is working the way you just described, then it sounds like it is working correctly to me. An ignored field means it always uses the default language value, and in this case it is searching the default exp_channel_data or exp_channel_data_field_x field, not Publisher’s tables.

If it was working that way before hand then it was probably a bug b/c the current functionality is correct. An ignored field is meant to be ignored in every aspect.

Have you tried the search tag? http://docs.boldminded.com/publisher/template-tags

It can do similar searches and will return a list of entry_ids that you can then pass to an entries tag.

{exp:publisher:search field_name="keyword|another keyword"}
    {exp:channel:entries entry_id="{entries}"}
        {title}
    {/exp:channel:entries}
{/exp:publisher:search}

Are you saying that if a field is ignored it cannot be searched in {exp:channel:entries} loop?

It can be searched on, it’ll just always search the default language field value.

Shouldn’t the ignore field settings just make it so that the field value will be consistent across all translations? I think when someone writes search:field, the search will look for a match in channel_data table if the field is ignored and publisher_data if the field is not ignored.

That is exactly what it is doing. It’s consistently expected to be the default language value across all languages.

I don’t know how it was working the way it was in EE 2, but I don’t see how I can refactor this to work the way you’re wanting it to without breaking the concept of an ignored field (or break someone else’s site who is using search:field parameters).

Go to line 880 of mod.publisher.php, and change the line ->where(‘lang_id’, $this->request->getCurrentLanguage()->getId()) to ->where(‘lang_id’, YOUR_ID), and use the exp:publisher:search tag to see if you get the expected results. You may need to also use the publisher_lang_id parameter in the entries tag.

{exp:publisher:search field_name="keyword|another keyword"}
    {exp:channel:entries entry_id="{entries}" publisher_lang_id="ID"}
        {title}
    {/exp:channel:entries}
{/exp:publisher:search}

If adding the language ID in the query of the exp:publisher:search tag works, then I’ll add a parameter so it can be used as

{exp:publisher:search field_name="keyword|another keyword" publisher_lang_id="ID"}
    {exp:channel:entries entry_id="{entries}" publisher_lang_id="ID"}
        {title}
    {/exp:channel:entries}
{/exp:publisher:search}

I’ll try to take a look at that soon. I still think the behavior I described sounds logically correct knowing how the ignored fields are supposed to work, but if restoring it to the behavior you’re described is fairly trivial I will try to do that.

In my test I have 3 entries, all assigned to the “black” category listed at the url “/de/karten/category-de/schwarz” which is /de/cards/category/black in English. But only 2 of the entries have a field with the value of “fr” in it, so this query returns two results, as expected, b/c it’s matching the category AND the custom field value of “fr”. This is the new query generated from the build in the previous comment. If you’re expecting a different result then I’ll need an example of a working query that EE core generates returning the expected rows (e.g. reproduce the results without Publisher installed), b/c I’m pretty sure this is the same result that EE would produce given the search parameter and category. I’m not sure how this would work any other way to be honest, other than changing that last AND to an OR, which fundamentally changes the search query and I think would differ from what EE would generate itself.

SELECT `ct`.*, `t`.*, `d`.*, `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_publisher_data` AS d ON `t`.`entry_id` = `d`.`entry_id` AND t.lang_id = d.lang_id AND t.status = d.status
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_publisher_category_posts` AS cp ON `cp`.`entry_id` = `t`.`entry_id` AND cp.lang_id = t.lang_id AND cp.status = t.status AND cp.cat_id IN (4)
JOIN `exp_members` AS m ON `m`.`member_id` = `t`.`author_id`
WHERE `t`.`status` =  'open'
AND `t`.`lang_id` =  2
AND `t`.`entry_id` IN (90, 13, 12) 
AND `t`.`channel_id` IN ('3') AND ( d.field_id_21 = 'fr' );

While those 2 queries look different they are effectively doing the same thing. The second one (from EE’s mod.channel.php file) is fetching just they entry_ids, then it later does another query that very closely resembles the first one (from Publisher) Publisher just isn’t doing the extra query b/c it doesn’t need to.

Comment has been marked private.

They’re being removed b/c it doesn’t exist in the $entries array, which is populated by the query that the last update is supposed to fix.

Set line 850 to this:

$fieldsSql .= ee()->channel_model->field_search_sql($terms, $searchColumnName, $siteId);

Looks like I botched the code and somehow removed “ield_search_sql”

Can you create a new EE install with Publisher and the necessary entries and settings to re-create the issue, then I can install it locally and debug it. I can’t debug something this complex from your current site b/c I need to be able to step through the code execution to see what is happening and when. I can’t just remove a large conditional like that b/c it is going to have adverse side affects possibly to your site and other customer sites.

I don’t know why this was “working” for you in EE2, but based on what I’ve uncovered it feels like it is working correctly in it’s current state. Yes it is removing the item from the result b/c it is doing a category filter “AND cp.cat_id IN (4)” and it is also searching a custom field “AND ( d.field_id_21 = ‘fr’ )”, so both of those can’t be true. If it finds the right entries by category, 1 or more of them may be immediately removed by the query b/c of the custom field lookup. Seeing this in a clean EE environment they way you’re seeing it would help me dig into this further. Just please clearly indicate in the template you use what the expected results should be (e.g. exactly which entry_ids should or should not be returned in the result)

Can you package that site up with an SQL dump so I can debug it locally?

Gilbert, thanks for sending the files. This helps a lot. I have it running locally and will let you know what I figure out in the next day or two.