Fatal Error in search filter

You still have the issue assigned to yourself ;)

That's not as easy to solve as you think. Currently you can comment out this line but

SearchQuery uses form_set_error('keys') which will fail on exposed filters for some cases
=> we have to extend this class?

Alternatve we copy the function from d6 and uses it here.

You know there are no many bugs around it's hard to fix every of them at the same time :)
For the most people it's freetime in the issue queue

Any news?

This issue would be marked as fixed if there would be any news.

Just some updates.

Now query has to be converted.

Setting appropriate status.

i think this needs review no?

No it doesn't work at all yet.

my bad resetting the status

subscribe

subscribe

subscribing

Here's a patch that expands on the patch from #10. I was able to get basic search working with exposed search filters (basically single/multiple search terms). Type searching does not work and neither does OR and Negative operators. There's still a lot to be done; I had to comment out a lot of the code to get it to run and the code is riddled with todo's.

I actually ran into a couple of very odd problems:

      $this->query->add_where($this->options['group'], "$search_index.type = '%s'", $base_table);

This conditional gets rewritten somewhere to: search_index.types (notice the "s" at the end). Bizzare.

      $this->query->add_having($this->options['group'], 'COUNT(*)', $this->matches, '>=');

This having clause get's rewritten to: COUNT >= :db_placeholder. The "(*)" is stripped off of the clause.

Hopefully this will be a start towards getting search filters in views working.

I general i think it's bad that views has a big part of the search.module in it, just to support it.

There is a alternative approach to this.

* Create a object of searchQuery and execute it's helper functions.
* Get the results back by extending searchQuery and use some getter's.

This would allow a much smaller code change than currently.

Subscribing

@dereine I'm currently looking into the feasibility of rolling a patch based on your comment #19. Could this be achieved by replacing the call to search_parse_query() with an instance of SearchQuery and the parseSearchExpression() function? I'm not able to locate any other modules that use SearchQuery object to uses as reference.

That's the problem when working on views. There are often no other modules fighting with this kind of problems :(

Already worked many hours on this problems without any success.

The price to pay to be on the forefront of technology :).

dereine, thank you for work on this! Can you post up what you've got so far? (This is where the git issue sandboxes would come in very handy)

As i said i managed to do nothing, at least nothing which can't be achieved in some seconds.
See #19

Found something from my backup.

Never said that this is something useful

Thanks dereine! I'll see what I can do with this patch (@ngmaloney if you want to try too, be my guest).

Thanks @dereine and @duellj. I'll post any progress I'm able to make. I think the #25 patch provides some good next steps to look into. The searchQuery() is so heavily abstracted I wasn't sure how to create a useful object instance that views could use.

subscribing

Applied patch from #25, new error message is

Fatal error: Can't use method return value in write context in /path/to/drupal/sites/all/modules/views/modules/search/views_handler_filter_search.inc on line 75

This message shows up after hitting submit on an exposed form for all filters (which work without this patch), even if search is left empty.

I have some budget to get this fixed, is anyone interested? How much would we need to raise?

This will perhaps be fixed during the dev days in bruessel because

a) there are people which want to hack
b) there are people which understand search.module/dbtng (berdir)

What was needed for this patch

* A full package of cookies
* no fear against this issue.

So here is a patch. It works for me on the preview and in the interface fine.
Both with simple ("searchword") and complicated queries("searchword -butnot).

Just a single quote why there are things which complicates the whole thing.

  public function publicParseSearchExpression() {
    return $this->parseSearchExpression();
  }

How cool is that! :) This works for me for simple searchwords, but not for the "searchword -butnot". The error for the latter is:

Fatal error: Cannot access protected property DatabaseCondition::$conditions in /path/to/drupal/sites/all/modules/views/modules/search/views_handler_filter_search.inc on line 136

Okay hacked core to see the variables better :(

Awesome, now it works as intended!

Let's get it in then :)

Thanks for the testing.

Commited to the 7.x branch.

Thanks for getting this in.

One problem I found, there is a fatal error for complex search queries, which you can see if you give it a query that mixes AND (or just multiple words, as the AND is implied) with OR: Recoverable fatal error: Method DatabaseCondition::__toString() must return a string value in views_handler_filter_search->query() (line 141 of /views/modules/search/views_handler_filter_search.inc).

There are places where dbtng really stands out and makes things easy.

Here is a new version.

Sorry, probably a simple question here... first time running a patch..... what directory should i place these patches and after I run the patch command on the command line, which file should we be patching?

ty

See http://drupal.org/patch/apply

The directory is the views module..

The patch at #39 seems to fix complex queries for me, thanks.

One other thing though... what about the search argument handler, views_handler_argument_search.inc? That will need to make use of viewsSearchQuery class as well.

@mfb
Thanks for testing the patch.
Commited to 7.x branch.

Would it be okay to create a new issue for this? Would be cool.
This is not that hard to fix, because we already figured out this problem here.

ok, #1055602: Fatal error in search argument