Thread

Thanks for the assist, narration. We’ll continue to look into this as well.

Ok, I have a fix that tests to work for you, eeart. Until Ellis can get it done.

What appears to be the problem is that there is actually no code to set the search_on from form elements, as the advanced_form is supposed to allow you to do. They are only taking care of the case where I did get it to work by setting search_on in the tag parameters.

Your source is probably the same—I am working on 2.1.4beta where I doubt this area’s been touched. If it’s been altered, you can identify where to place the following by looking for the comment below which and source above which I’ve placed this new code, as it will surely be nearby.

The addition is in system/expressionengine/modules/mod.search.php, below line 776:

/** ----------------------------------
            /**  Search in Searchable Fields
            /** ----------------------------------*/
            
            // fix so advanced_form search_in set by form inputs will be obeyed,
            // not colliding with any setting in the tag params for simple_form
            if ((!isset($this->_meta['search_in']) OR $this->_meta['search_in'] == '') 
              AND isset($_POST['search_in'])) 
            {
                  $this->_meta['search_in'] = $_POST['search_in'];
            }
            // end fix
            
            if (isset($this->_meta['search_in']) AND ($this->_meta['search_in'] == 'entries' OR $this->_meta['search_in'] == 'everywhere'))
            {
                if (count($terms) > 1 && isset($this->_meta['where']) && $this->_meta['where'] == 'all' && ! isset($_POST['exact_keyword']) && count($fields) > 0)
...etc.

You’ll just copy the original file for safety, then edit the fix with its comments in, and save the file.  EE will just use it.

Now, here is an example search form that tests to work, using radio buttons instead of the checkboxes as explained were needed. You name them the same to get the expected only-on-checked behaviour, and you can see which one I initialized to be checked.

This version uses the system lang data for labels - you can substitute your text labels when you’re ready, but I thought these were rather explanatory. Otherwise, I copied back the top part of your form so you should be able to just paste this in for test:

{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="radio" name="search_in" value="titles">{lang:search_in_titles}

<input type="radio" name="search_in" value="entries" checked>{lang:search_in_entries}

<input type="radio" name="search_in" value="everywhere">{lang:search_everywhere}

{/exp:search:advanced_form}

eeart, I hope that gets you on your way. I checked your ordering and date inputs, and they appear already to work.

I’ll update to show what’s been done in the bug report for Ellis. They still have to find the fix for the initial problem which we worked around, and also agree or make some other method to fix this one.

Bug report is still 15075.

Regards,
Clive

Thank you SO much, narration! Your fix in mod.search.php has solved our search_in problem. We are now able to search in descriptions again.  😊

‘where’ has the same problem. I’ve added the following fix for this:

// start fix
if ((!isset($this->_meta['where']) OR $this->_meta['where'] == '' OR $this->_meta['where'] == 'all') AND (isset($_POST['where']) AND $_POST['where'] != 'all')) {
    $this->_meta['where'] = $_POST['where'];
}
// end fix

/** ----------------------------------------
/**  Pulldown Addition - Any, All, Exact
/** ----------------------------------------*/

meta[‘where’] seems to be always ‘all’, so I have it override this if $_POST[‘where’] is set and not ‘all’. This way when where is set to ‘exact’ it will be used.

The checkboxes for titles, descriptions, comments has always worked for us, and it seems to work now too.

Thank you for looking into this. You rock!  :coolsmile:

Well, ok 😉.  And great job on extending it, eeart. I hadn’t noticed that one. I presume you had your reason for the logic on ‘all’.

I’ll pass the note you’ve done that on the bug report.

It’s great if your template works as intended, as is. I think that’ll be because of a fortune in the order of arguments - which one wins as far as PHP reporting on an input like that is probably the last one checked. I doubt that whatever affects ordering in PHP will change.

Now the Ellis people have solution examples for this area, and can combine those with a fix on the caching/search identity failing bug. Then search will be healthy, I think.

Glad you’re on the air, and will have to look at what Erwin and all your crew have been advancing with more carefully now.

Best regards,
Clive

Clive and eeart,

Thank you very much. Now that the bug report has been submitted and updated shall I close this thread now?

Cheers

Greg

Greg, normally would agree to close, but in this case it might be best to leave open longer, until we’re sure there are no more buried symptoms, and especially until the bug report (15075) is acknowledged and on its way to repairs.

I suspect thats particularly important here, as 2.1.4 really needs resolution before it goes out of beta. Having searches produce errors due to normal template caching is not a good thing, nor is disturbing advanced form logic people have in their templates, and these are the issues here, likely not much more trouble involved to get the job fully done.

Regards,
Clive

Sure, we can keep this open a little longer, no worries. Let us know how it goes.

I’m not sure if my problem is the same or different.  It started off like grrramps—I’m getting the same errors he got:

A PHP Error was encountered
Severity: Notice
Message: unserialize(): Error at offset 0 of 32 bytes
Filename: search/mod.search.php
Line Number: 388

The following errors were encountered
The search path contains an error. Please contact the system administrator.
Return to Previous Page

But also another error:

A PHP Error was encountered
Severity: Notice
Message: Undefined index: meta
Filename: search/mod.search.php
Line Number: 370

In addition, none of the solutions described worked.  Even when I’m not logged in at all, the search path error prevents the site from returning any search results—it just sits on that page with that message.

I’ve tried clearing cache, which does nothing.  The link to the site is http://test.studentaidcalculator.com/index.php/media

The code for the search is:

{exp:search:simple_form channel="news" result_page="media/search"}
                <input type="text" name="keywords" id="keywords" value="" maxlength="100" class="text-input" /> 
                <input type="submit" value="Search by Keyword" class="button" />            
{/exp:search:simple_form}

The code for the results is:

{exp:search:search_results}
                <div class="article-detail-wrapper">                    
                    <span class="article-date">{Date format="%F %j%S, %Y"}</span><a href="http://{auto_path}">{title}</a>
                </div>
{/exp:search:search_results}

Caching is disabled on the search page and result page.  I’ve set the Search Results URL to http://test.studentaidcalculator.com/index.php/media/search

Also, I’m on EE v2.1.3 as a fresh install (didn’t upgrade)

Any suggestions would be greatly appreciated.

xiik, have you tried uninstalling Search from Modules, then installing it again? Clear caches after this and see if you get good search results, right afterwards. If memory serves, the two steps are necessary so that you clear database search temporaries, which Clear Caches doesn’t affect, but which are linked to values cached for the page.

That’s just a check that we’re talking about the same problem, which is likely anyway.

The thing you can do to work around here, until Ellis fixes an issue, will be to isolate the search tag portion of your page from caching.

You can probably most easily do this by cutting the search code and putting it in another template, to use as an embed. Then call that embed from the position this search code came from. For example, from a working site:

Original search position in your template:

{embed="{my_template_group}/.search"}

Content of new template named .search (so it is not directly accessible from web)

exp:search:simple_form channel="{my_channel}|forward" search_in="everywhere" status="open" 
  result_page="{my_template_group}/results" no_result_page="{my_template_group}/noresults"}

<h2 class="sidetitle">Search</h2>

<input type="text" name="keywords" value="" class="input" size="18" maxlength="100" />
  <input type="submit" value="submit"  class="submit" /></p>

{/exp:search:simple_form}

That’s obviously got a few local things in the search code; use your own of course, and be sure you’ve one way or another identified the proper template group each place it’s used.

Then be sure you’ve set Enable Caching to No, and saved, for that .search template, from Preferences either on its own edit page or on its line in the Template Manager.

This will work, and without any appreciable performance loss, unless somehow you have a different problem from the one we were troubleshooting in the first part of this thread.

We went on to others, but they won’t affect unless you are using a form_advanced search tag. In any case they don’t cause PHP errors, only control omissions.

Meanwhile, we are waiting for this reported search bug set 15075 to get attention that will repair the underlying cause, which looks to be in use of Session information which internally connects the search results to the separately templated results page.

Let us know your situation in trying the above, and hope it makes clear for your case, what’s important from this otherwise long thread above.

Regards,
Clive

Thanks so much for the fast response, narration!  I apologize; I’d meant to mention that I’d done the uninstall/reinstall too.  I tried it again, twice, with the uninstall, reinstall, clear all cache and then running the search and I’m still getting the same error message.

Should I still go forward with the other steps you mentioned?  It should be noted that both pages have Enable Caching set to “No” already, so I would’ve thought that would prevent caching from being an issue, but I really have no idea (only my second EE site).

Yes, I was going to mention that email from forum entries is a pretty quick connection sometimes 😉.

Hmm. I was actually listening the first time, and what you say now has me wondering. Indeed you should have cleared the problem by assuring caching was disabled on everything—after enough clearing of cache and database above for a fresh start.

Now that I look more carefully, that error on line 370 seems to say that the meta information wasn’t passed on the form post—but when I try your site links, indeed it is there on the call to show the results page, and looks as healthy as far you could tell with encoded information. Being there healthy or not, line 370 shouldn’t have failed.

Let’s check about a few things:
- you are running a recent version of EE, right? 2.1.3 or the 2.1.4beta?
- I notice you’re not taking out the index.php at least for this test: very good.
- But, do you possibly have any .htaccess code running? What I would be looking for is anything that would cause the ACT code URL line arguments to not be passed into EE fully, even though we see them in the original results URL. Thus, if you have any .htaccess, could you post the contents as code?
- Better yet, test the search with the .htaccess renamed so that it is not active at all, and see if that line 370 error still shows. You’d probably still have to do the clearing steps to get search working again, if thats the issue.

I have a few things to do this Sunday night, but we are collecting good clues.

Regards,
Clive

Thanks again!

We’re running 2.1.3, not the 2.1.4 beta.  I also confirmed based on the info at the bottom of the admin screen. 

I have not added an .htaccess file.  The last EE site we did, we didn’t add one either.  I copied the code from there, so it’s pretty baffling that it’s not working.

I should also mention that I’m running MySQL 5.5.  Not sure if that makes a difference.

Ok, good to have verified on that. The support crew would ask you to remove it, for the reasons, anyway.

I was thinking about this on the way home. I am pretty drawn to suspect the problem is with the server, not EE, based on what we’re seeing. In which case, there’s a way to easily look at it without EE being used.

- if you don’t have one, make yourself a PHP info mini-app. Just put the line as follows in a file, and give it a name like abc_phpinfo.php, just to keep it semi-safe from prying eyes. Later you’ll remove it to avoid sitescanners doing discovery.

<?php phpinfo(); ?>

- from your web browser, address it with a URL like this:

<a href="http://yoursite.com/abc_phpinfo.php?this=that&those=other">http://yoursite.com/abc_phpinfo.php?this=that&those=other</a>

- search in the big listing that’s returned for query_string. There and nearby, you may find some of the following: QUERY_STRING, REDIRECT_QUERY_STRING, REQUEST_URI; and possibly others - all of which should contain the this=that&those=other information. Please post the values each you find has here.

- [edit - the ACT= phase is where receiving the query string and it’s ‘meta’ variable is breaking down, so it is still very much in there, au contraire to a moment’s mistaking between the broken server and results on my own where I make parallel checks.]

So let’s see what you’re getting, as this listing will say what’s making it in through PHP for EE to see. EE has configurability to deal with odd servers, and there are some. I should ask where you’ve got this project hosted, by the way.

Regards,
Clive

_SERVER[“QUERY_STRING”]  this=that&those=other

_SERVER[“REQUEST_URI”]  /abcphpinfo.php?this=that&those=other

I didn’t have a REDIRECT_QUERY_STRING

This is being hosted by our client.  It’s on a Windows box running PHP.  Windows Server 2008 R2 Standard.

I’ve also removed the file, as you suggested.

Ok, let’s take a little jump here, and see if we can get something going this late.

Can you please go to your CP Admin>System Administration>Output and Debug Preferences, and set Force Query Strings to Yes?

Then see that your site obeys its menus and links.

Then see if search now works.