Exposed filter search not working after upgrading from 7.x-3.0-rc3 to 7.x-3.1

Well if it's such important for you, maybe consider to pay people to fix your bugs.
Just by looking at the amount of reports in the views issue queue someone could spend the whole day answered support questions which were marked as bugs. Two days of response time is actually not that bad.

If you start with adidas and then prodder it's not possible to find something on prodder, though if you start with a total new tab and search for prodder it will find prodder, also if you type in adidas.

So something like the ajax here could cause the problem.
If you look at the actual request sent out for the second one, it's quite interesting because you will see adidas sent, but you do get prodder as result.

Maybe you have here some kind of too strict caching?

Did you tryed already the 7.x-3.x-dev version, they are probably always the versions with the fewest bugs, because you know there is time between 7.x-3.1 and now.

One small other thing written on http://drupal.org/node/add/project-issue/views

Before submitting an issue to Views, you are responsible for reading and understanding the Views issue submission guidelines. Failure to read and understand this page will result in your issue being marked "won't fix".

Doesn't work for me either. I have a forum view, with only two forum posts on it. I added the search keyword exposed filter. I exposed the filter in a block. In both of the posts I have the word "question" like four times. I do a search on the word--nothing. My site is 100% indexed.

Ok. I used to be blonde before bald. My search in post above wasn't working because the words are in the description of the Forum, not within the topics. Not sure if search would look there or not?

But here's an issue. I have a word--respectful in the topic content. I do a search for respect and get no results. When I search for respectful it works.

Is this search box doing an exact filter or a "like" filter? Views doesn't give the option to select what kind of filter it does.

Ok, I've done a little more testing and the filter definitely does a word=exact filter. I hope this isn't by design? It need to be a "includes, is like, contains, or at the least, a "starts with" in my opinion. I have a word-typos and when i search typo my view comes back empty.

I'm having trouble with some exposed filters that have worked through the Views betas and alphas, up to 3.0, but when I upgraded to Views 3.3, they broke. They only broke for AJAX views where the exposed form is in a block. I know the search is being done correctly, and I see the proper keyword in the $_GET array via my module's implementation of hook_views_query_alter(), but the view always shows an empty result after anything is entered :(

On the views UI page for the view, when editing the view, the Master display's exposed filters work fine. I might try -dev and see if this is still a problem there. I did notice that, when editing my view via the Views UI, Views thinks an edit to the view was made, and is saying I need to save changes; I haven't made any changes to the views, and I remember that Views auto-updates things from time to time...

I had the same issue with exposed filters and ajax. @ dereine is 35 days too short of a time for any of us to ask where we should find help for this issue? Do you have any suggestions. Thanks

I found that, on my site, when I was adding where clauses to certain queries inside hook_views_query_alter(), using the syntax $query->add_where(), I had to update the array index of the where clause (the first parameter of add_where()) and increase it by one, because somewhere along the line of Views updates, my Views' AND/OR clause groups were changed, and the array indexes were increased from 0 to 1, or 1 to 2, etc. (So, the problem is solved for me).

The 3.3-dev version as of today (June 18, 2012) fixes the issue for me. Although something is still strange, because the URL will still reflect the original search term upon further queries. But at least the page itself updates, which before it would not.

Altered the URLs to the correct ones.