Thread

Thanks for adding your details, eeart. I wish we could replicate what’s causing this. But I can make sure the testing staff adds this to their regression testing for the next version of EE.

This error caused by the latest version 2.1.3 keeps popping up. Each time I have to uninstall and install the Search module and then clear the cache.

Are you still not able to replicate the problem?

I hope you’ll be able to provide a solution to this as soon as possible.

Ok, I have traced this far enough to make repeatable results, which also contain a good pair of clues after looking at the search code.

To show the problem:

- be logged out of any membership, including admin/CP
- refresh a page with a search on it, probably your index
- make a search that will find something. It will work normally. Unless you need to do the clearing set of instructions below, to get it to work right at first.

- now, log in. Make it to the CP the first time for a convenience below
- refresh your page with the search on it, and make a search
- the search will fail with the ‘search path contains an error’ message. That’s the bug.

- now, clear all caches in the CP
- log out of the CP
- refresh your page with the search in it
- make the search, and now it will again be working

This same sequence will also generate the failure if the login is an ordinary Member, rather than the CP adminstrator. However, then you’ll need to log out as the member, then log in to the CP and clear the caches, then log out of the CP and refresh the page with search, to get back to a working search.

Two clues:

- The database definitions are subtly different between last July’s EE and present EE. I’m not sure this can cause issues, but it probably should be updated by the updater, if it isn’t. The clearing of the search error problem that occurs if you deinstall and reinstall the Search module is because you recreate the search table from scratch, clearing out all contents as well as making the slight upgrade.

- The clearing-contents issue plus a brief look at the search code, plus that the issue is actually triggered by a login, suggests that Sessions are the culprit. Something subtle there, and I will leave it to someone who’s worked out familiarity with the code to locate the issue. Should be straightforward now that we have a solid way to trigger it.

eeart, note that you can clear your EE problem without reinstalling Search, but it’s about the same number of steps.

I’ll put a note in the bug for this, which has existed a while but is yet to be assigned: 15075

Regards,
Clive

Thank you Clive, this should help them narrow down the problem.

You’re right that clearing the cache fixed the problem and it’s not necessary to reinstall the module.

We thought of running a cron job to clear the cache, but how often? I would have to find a way for the script to detect when the problem occurs. If it is triggered by members logging in then it can happen at any time.

I could spend a few more minutes with this, and have some more information for the kettle, along with a temporary workaround that I think works.

The workaround is to set the section of the page where the search form appears not to be cached. That’s easy on a setup I am testing, as the sidebar where the form appears is in an embed. I simply turn off caching for that embed, via the Preferences dropdown on it in the Template manager. The calling page itself is still marked as cached, which I presume still does the parts which are not the sidebar embed. I’m not using other forms of caching. There is a performance hit, but it is not significant.

With this setting, as long as the page is refreshed before searching after either a login or a logout, searching works properly.

In most cases this containing page refresh will be automatic, as you have to return from a login page. Exceptions would be where login is done from another browser window, tested to fail without a manual refresh; or likely where a login occurs on a pop-up div as in the Agile demo.

I think this sheds some further light regarding where this problem is. As far as I am aware, it didn’t exist in EE1, or in early versions at least of EE2. Again, Sessions have the feel of being the concern. Just not time here to fully trace it down.

I don’t know if it will get you on the air, eeart, but you can try it. If you aren’t using an embed for the search, it should be straightforward to isolate the search form in one.

Regards,
Clive

Our search form is on an embedded template that was being cached. I turned this off and I cannot replicate the error anymore. Thanks! 😊

Just to mention the bug Report link again here

We are no longer getting the error message, but we have now noticed that searching is not working properly:

1. “search_in” doesn’t work in “entries” anymore (everything only searches in “titles”)

2. “where” doesn’t search “exact” anymore, it is always “all”.

I think that this has also happened after the upgrade to 2.1.3 because we never had this before.

eeart,

Ok to replicate this can you post your search tags here please?
Give us an example of content you are searching for too.
A link to your site would be helpful also

Are you using any add-ons?

The search tags are as follows:

{exp:search:advanced_form channel="channel|channel" result_page="directory/search_results" no_result_page="directory/search_no_results" results="20" status="open" show_expired="yes"}

<input type="text" name="keywords" class="search_box" />
<input type="image" class="search_btn" src="button.gif" value="Submit"/>

<input type="checkbox" name="search_in" value="titles" checked="checked" disabled="disabled" /> names
<input type="checkbox" name="search_in" /> descriptions
<input type="checkbox" name="search_in" value="everywhere"  disabled="disabled" /> experiences

<input type="radio" name="where" value="exact" /> sentence
<input type="radio" name="where" value="all" checked="checked" /> words

Filter on date
<select name="date_order" class="search">
    <option value="newer" selected="selected">newer than</option>
     <option value="older">older than</option>
</select>
<select name="date" class="search">
    <option value="0">oldest chatbot</option>
     <option value="1">yesterday</option>
     <option value="7">one week</option>
     <option value="30">one month</option>
     <option value="90">three months</option>
     <option value="180">half year</option>
     <option value="365">year</option>
</select>

and sort
<input type="hidden" name="orderby" value="date" />
<input type="radio" name="sort_order" value="desc" checked="checked" /> newest first
<label for="asc"><input type="radio" name="sort_order" value="asc" /> oldest first

{/exp:search:advanced_form}

eeart,
Give us an example of content you are searching for too.
A link to your site would be helpful also

This is on http://www.chatbots.org. The search is on the left-hand side on the homepage. Check ‘descriptions’ and search for words you see in the descriptions in the middle. We get ‘no results’ all the time now, which wasn’t the case before upgrading to 2.1.3

Thanks.

Did you change anything, or is that an intermittent issue? I just performed a search and it worked as expected.

What did you search for?

If I search for “sophie helps” (from the first post on the page) in descriptions and words I get no results.

eeart,

Can you confirm that the actual description custom field has search enabled for it.
Can you also create a blank template and add the example code from the docs to it and nothing else and link to that here please?

Yes, the fields are searchable. The field that contains “sophie helps” from the first entry on the page has “Is field searchable” set to Yes.

I’ve tried the example code from the docs and this gives the same result. On this page http://www.chatbots.org/sandbox/search_test/ search for “sophie helps” in Titles and Entries and there are no results.

It looks like advanced_form search is paying no attention to form setting of search_in, as a basic issue here. There are others, but EE has to solve that one as a bug.

- you can specify the type of search_in as a tag parameter, even though the doc doesn’t say so, for advanced_form search, and it is successful. You can find elements in title, body, etc..
- but if you make even a simple single <input> element for search_in, and remove the parameter from the tag, it is ignored. You will get title searches only. You can type other values into this field to alter it from whatever you set for default, but this will be ignored.
- That’s why you get the results you do, eeart. Try just ‘helps’ in your sandbox test. You’ll get Hanover Helps. Likewise for ‘hanover helps’, so you see search itself works.
- This is EE’s present bug, but also, eeart, I don’t think the form can work correctly as in your template code. Look at the example, and the documentation. search_in can take just one value, so a multivalue selector like a checkbox isn’t appropriate. You’ll want grouped radio buttons if not the example dropdown menu, and that probably means semantics change in your English labels as well.
- it’s not too relevant because of this issue, but there’s also an error in your second checkbox definition. It doesn’t have a value= specified, so would not be seen even if checked.
- I also found a nifty new bug in the CP, where it does not create templates as copies if asked, and will put that in the reporter separately: 15242.

Summary: I think EE Search itself still looks sound, but the Advanced Form functionality configuring it is partly not working, or perhaps not according to terms in the documentation. With that working, your design can be corrected and should operate in the senses you want it to.

The avatar-bots idea is looking more intriguing these days…

Regards,
Clive