Thread

This question may be related to a resolved thread.

According to the docs, the no_result_page parameter of the simple search tag should allow one to set a template_group/template for displaying a message indicating that no results were found. EE’s current code, however, will never permit this to happen. Thus either the docs or the code is buggy. I argue that the code is at fault.

The glitch lies inside mod.search.php inside search_results(). On line 1285 (and again at line 1300) a lack of search results results in this:

return $this->EE->output->show_user_error('off', array(lang('search_no_result')), lang('search_result_heading'));

show_user_error() completely bypasses the template parser, so the desired template_group/template is ignored. Based on the docs that’s clearly a bug.

Fortunately there a couple simple fixes. The one I chose: simply replace the show_user_error() line with:

return $this->EE->TMPL->no_results();

And in my template I have something along the lines of:

{exp:search:search_results}
{if no_results}
Sorry, we didn't find any results matching your criteria.
{/if}
{/exp:search:search_results}

So I suppose my tech support question is this: Am I wrong that this is a bug? It appears others are having the same problem so I think not, but perhaps we’re all missing something.

Mr. Wilson, this is possibly a chance to return on your identity premise (and website manner) which I’ve enjoyed more than once over the years.

I’m not sure exactly what you’re running into yourself, but the prior posting set you referenced is about a very specific concept: they are trying to collapse to using the same template for no_result_page as for result_page—hoping that conditionals will allow different execution.

The key to understanding why this is difficult is that in the search module code, the no_results_page is presented by asking the user’s browser to redirect to it. A set of data is made available for that page by saving it in the database under a unique key.

You can see the setup and no_results_page redirect being arranged from line 254 through 272 in mod.search.php, in 2.4.0, and I don’t imagine it’s much different in earlier versions.

To answer your direct point, the template parser _is_ called, because this browser redirect is resulting in an EE response for the no_results_page just like it would for any other.

A similar method is used from line 280 to 317 to load and redirect for the results_page, when there actually are results.

What’s happening where you looked at code around lines 1285-1300 occurs once the results page has been loaded, and only in the case that the search_results tag is used—which would not be the case in a no_results_page, as there would be no data for it. Then EE is working around this coding error by presenting a hard-coded no-results message.

The answer, then is to work within EE’s design, and have separate templates for search_results_page and no_results_page.

If one wants to write the general part of results page layout once only, then in the old days embeds, and these days snippets or globals are appropriate choices, I think you’d probably agree.

As a practical matter, my long term validating site shows search working well as it always did, including presenting the no_results_page as expected when there no results.

I did once take apart search pretty thoroughly in the forums when it turned out to have a number of advanced features wedged in early days of the EE2 development, but this part always worked correctly even then.

Hope this helps—and thanks again for the regional culture. I did quite appreciate it 😉

Clive

The answer, then is to work within EE’s design, and have separate templates for search_results_page and no_results_page.

Yes.., but why use a CMS and templates when you’re going to differentiate and use a template for each function?

I still find this a weird way of working, especially since a no result page is not something which is very complicated.

Well, think of it as idiosyncratic neighbors, who have personality, and probably a reason for it, if one knew what that reason was?

Seriously, though, l suspect it’s a matter of frame of view.

A no results page really has content quite different from a page listing out results. The only likely shared information element is the query. It’s like a 404 page that way.

The liberal employment of boilerplate, via snippets, etc., makes a tight design, and then you have only to write the differences: one line only for this page.

No conditional to figure out either, not ever one of EE’s strong points; and if there are any layout differences, a clever image for example, the framework makes it very easy to provide.

At least for me, this way of thinking suits the iterative aspect of design well. And you do want to remember that EE was originally developed by advertisers, looking for a mistake-tolerant way to get web sites up quickly, and concentrating on their visuals.

The addition of things like snippets makes this easier yet, and it seems a good way to go, again at least here.

Glad you found this, bottleboot, in spite of the ‘closing’ of discussions, and cheers, Mr. Wilson,
Clive

Hello Mr. Wilson,

Great persona by the way. 😊

I’m sorry for your frustration about this. While this is not a bug, I can tell you would like things to work differently. This is the way the search results tag has been coded, so it is operating as expected.

I see you commented on the feature request, thank you for doing so. If there are any updates to that thread you will be notified if you selected “Notify me via email when someone posts in this thread”.

Is there anything else I can help you with?

Cheers,

Great persona by the way.

Thanks!

This is the way the search results tag has been coded, so it is operating as expected.

Except it’s *not* operating as expected. What’s expected is that it behaves as documented:

You may specify a particular Template to display in the case when there are no results. This takes a standard “Template_Group/Template” as input.

As currently coded, that parameter does not work as described. That’s the very definition of a bug, either in the code or in the documentation. There are two ways to fix the bug:

* Update the documentation to explain that you may NOT use the same template for result_page=”” and no_result_page=”“.
* Fix the two lines of code in mod.search.php as described above.

You /could/ settle for the documentation fix, but considering how easy the code fix is I strongly recommend the latter route. The current requirement for separate result/no result pages is arbitrary and bizarrely inflexible with no payoff for either the end user or the code. On the contrary, permitting {if no_results}{/if} right on the regular search results page brings the Search module in line with standard EE operating procedures.

And if that didn’t persuade you, then perhaps a simple Pretty Please! would help?

I’m going to make one more comment here, after some hours in attempting a solution for what Mr. Wilson emphatically wants (of Dennis).

Summary: it’s really not a good idea to go against the intended design of EE, most especially where this is old design, from back where many things were automatic to help designers who were not particularly developers.

Corollary: EE is not a computationally complete language system, which would allow free use of logic (“programming”), unless you want to go to using embedded PHP. You are much better off considering it a declarative language, and using its features as intended.

I attempted to find a way to use conditions to form a single template for both search_found and no_results cases. In the end, this is very messy no matter what avenue you try, and doesn’t work. Here are the most relevant attempts.

1. I tried simple if statements. Failed because of parse order. Would fail anyway, as later discovered that even though the general rule is that false conditioned statements don’t get parsed, apparently in the search tags case they do, and you run then into what Mr. Wilson doesn’t want, the protect-new-users system search not found screen.

2. I tried simple if statements in an embed, passing across the available value of total_results. This fails: runs into the same problem that somehow the search_results tag is parsed, even though it’s provably conditioned out (using flag strings to identify that the if statement works)

3. I put the if statements, zero and some results, back in the top level, and put the search_results tag in an embed. Now I get the correct output from template in either found or no results case. However, here, there is a pretty impossible situation with the system lang tags. They are automatically correlated to the presence of their matching tag, exp:search_results in this case. You have then to have them in the embed template, to get them parsed and proper strings on screen. At this point, you’ve written just what you don’t want to: a second page.

My thinking then is this. It’s a lesson how this doesn’t work, and the lesson is to use EE with its best face showing. That means collapsing your DRY work at much higher levels, using the improved parsing snippets etc. to write the layout for all but the data on your page. Then in a case like search, use the anciently written search tag as it was intended. Produce the two results pages, which have identical full page layout from snippets, and only the content area changed. You can do it in a moment if you write one of them first, then create a new template copying the first, followed by a quick edit.

As mentioned before, you have the chance then to put in any other nice layout you want, on top of basics. A search not-found often benefits quite a lot from a gentle or humorous graphic. As in the conversation here, people react a lot better if they don’t think you’re telling them they’re wrong.

I can’t really see a case for changing the original search tag, as it protects anyone who doesn’t get into the intricacies, giving the system no-results if you don’t do it right. That’s good for someone new to EE, and then they can learn to do something more attractive.

If such a change were made, I would suggest it be done with an extra parameter, defaulted to present behaviour.

I find the documentation correct about the main matter here. In fact, it suggests which tags you can use in the no-results page, if you read that far. I did find one separate error, in definition of {exp:search:total_results}. It’s actually a single tag, rather than a value on a double tag. I’ll report that.

Why do this work? I wanted to be sure of practice that works, for this kind of thing. Good practice goes a long way, with a powerful system floating above very complicated, complex systems, which well used lets even experts achieve a lot more than they otherwise would.

Regards,
Clive

Here’s the promised doc bug report: 17575.

Mr. Wilson- long time no see!  I need to hang on the forums more.

Looks like you guys have worked this out- to be clear, the no_results parameter is working like expected.  But yes- I can see how it does not shake out like you might want when trying to conditionally use the same template for both results and no_results. 

And between Narrations reported bug and Mr. Wilson’s linkages with the feature request, I think we have this covered.  In keeping with most tag behavior, I can see expecting the no_results conditional to work.

If anything else comes up?  Just let us know!

Hey, I just spent some time coming up against the same bug/issue/feature here before googling my way to this thread. It would be damned useful if you could just alter the documentation to say:

You may specify a particular Template to display in the case when there are no results. This takes a standard “Template_Group/Template” as input, and may not be the same template as is used in the results_page parameter.

Thanks!

Hey Castlegate IT,

I am glad that you were helped!

The documentation is being addressed and I will pass this request on to the documentation team.

Is there anything else I can help with?

Cheers,