I’ve been trying to use this with the {if no_results}{/if} tag, but can’t seem to get it to work - I’ve tried putting the no_results tag in the search_fields tags, and in the weblog tags, but neither seems to return a result.
Is there a way to get that to work, or is it not compatible with no_results?
@SierraBravo
That’s great, thank you! I’ll add it to the next version.
@Frank Harrison
no_results will work, but will get overwritten if exp:search_fields is wrapped by another tag. Try using an embedded template for the tag, and inside that embed the exp:weblog tag.
This looks very useful. I added SierraBravo’s multiweblog code and it gets me closer to what I’m trying to accomplish but I still have an issue. I have multiple weblogs that I’m trying to pull entries from as I’ve detailed in this thread.
which is close but I’m getting results even when “body” field is empty.
This is a query someone else wrote that does what I want:
{exp:query sql="select d.entry_id from exp_weblog_data d inner join exp_weblog_titles t on d.entry_id=t.entry_id where d.weblog_id in ('10','11','12') and (ASCII(d.field_id_50) > 0 OR ASCII(d.field_id_55) > 0) And t.status='open' order by t.entry_date desc LIMIT 0,26;" backspace="1"}{entry_id}|{/exp:query}
but I was hoping to simplify it using a plugin. Is this beyond what you intended for this?
This is a great plugin and is currently working well for me. However, I’m just wondering whether you can advise me as to how I might do the following:
I’d like to pull out entries that ‘contain’ what’s in my search:title parameter, limit them to 500 and if there are less than 500 results, output whatever’s left (up to the 500 limit) with search:title=“title4”. Is that possible?
You could search for all 4 titles, set a limit of 500, and use a conditional within the exp:weblog:entries loop to attach a css class to rows where the entry title matches ‘title 4’; then use jquery (or your library of choice) to select these rows, remove them from their positions within the list, and bolt back on to the end of the list.
If you didn’t want to rely on client side javascript, I think your best approach (and the one I would take) would be to write a small plugin to do the same thing in PHP. This is how you could do it:
* add ‘title4’ to your search paramater.
* uncomment line 259 in pi.search_fields.php (echo $sql)
* look at the your page in a browser; you should see the sql output at the top of the screen - copy it.
* create a plugin that runs this query; iterate through the result set and create two arrays: array A would contain entires that match title1|title2|title3 and array B would contain title4 entries.
* concatenate array B onto array A (+ is the array concatenation operator)
* loop through the combined array extracting the entry ids and creating a pipe separated string of ids. Replace into your template (look at my plugin to see how I did this).
* wrap your custom plugin around exp:weblog:entries and set parse=“inward”.
Great plugin. Thanks for sharing it. Could you please give me some pointers as to how to use this plugin in conjunction with the simple or advanced EE search forms?
think of it as a way to filter entries in very specific ways using the exp:weblog:entries tag, rather than as a replacement or enhancement of the search module. Take a look at my site here: http://dev.lefroybrooks.com/ notab,ly the product section.
All of the ‘searching’, form filtering, tagging, the live search etc make use of the plugin in one way or another.
Thanks for posting that link. The question I had was really to do with passing the search_words input to the search results template. On your site you are using the following code:
I assume that the input named “search_words” is passed to your products/search results template. Are the results generated using code similar to the below?
The pagination links are meaningless because the ‘keywords’ POST variable does not exist once you click a link [Edit: which is to say, exp:weblog:entries will not return any results.]. Any ideas? Outside of writing {search_results} to a session variable, which might work, I’m not sure what to do here.
Another thing, is there any way for it to parse multiple search terms? The relevant part of your SQL I’m talking about comes out something like ( wt.title LIKE “%term1 term2%” ) . That might be called exact phrase matching. I think I’m looking for more like ( wt.title LIKE “%term1%” OR wt.title LIKE “%term2%” ) .
I guess in general, as feature request unless it’s in there but I’m missing it, I’m looking for support like the where option offers in the Adavanced Search Form.
Am having trouble with a site running out of memory, on a page that uses search_fields. I’m getting this error:
Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 806656 bytes) in /var/www/vhosts/sitename.com/httpdocs/system/db/db.mysql.php on line 405
The code on that page is a little complex, but I’m surprised that 32MB of RAM isn’t enough. Here’s what I’m guessing is causing it to run out of memory (this is the most complex bit of the template)...
{exp:search_fields search:title="<?php echo $keywords ?>" parse="inward"} {exp:weblog:entries weblog="my-weblog" entry_id="{search_results}" dynamic="off" paginate="top" limit="10" orderby="title" sort="asc" category="<?php echo $categories ?>"} <!-- DO STUFF HERE WITH THE RETURNED ENTRIES ... --> {paginate} {if "{total_pages}" != 1}<p class="pagination">{pagination_links}</p>{/if} {/paginate} {/exp:weblog:entries} {/exp:search_fields}
So, the keywords/categories are added in via PHP (they’re submitted by a form), and I’m Search Fields to search the titles first, then a normal entries tag to filter by category. The page crashes when $keywords==”” and $categories==”” (so it’s returning all results). It was working though until recently - don’t know if it’s because the client has added more entries.
Any ideas why this might be using so much memory? Obviously, I could just up the memory limit, but I feel like I should fix the problem rather than patch it…
P.S am posting this in “How to” as well as here - apologies for the double posting but wasn’t sure where was the best place for this, and need to find a fix asap!
I noticed it was using a query in the form SELECT * from T WHERE entry_id IN (1,2,3 ... n) . In my case the IN list was thousands of records long (my weblog had 75,000 entries), and so PHP couldn’t handle that. I’m not sure if it was the size of the query, or the result set. I doubled or quadrupled the memory limit and still had the problem. In the end I scrapped using the plugin and just wrote my own PHP and SQL (using subqueries and/or temp tables to achieve a similar approach to using IN); it got a little complicated but I found the custom solution worked better for me. I think it depends on your case.
Thanks for your reply. The site I’m working on has only around 500 entries in that weblog, which shouldn’t be too big a deal. The fact that it was working and now doesn’t suggests to me that it’s the increase in entries that has caused it, but I would have thought that searching 500 entries in this way (or even 1000) shouldn’t cause it to crash. I don’t know if this makes a difference, but I have a similar query just before it in the same page (I had to do 2 separate calls to display total number of results, then the paginated results). Any ideas?
<major_rant>
I just figured out today that ee’s built in search functions are <rant>woefully, fearfully</rant> lame. I am building my first ee based site, and I had put off until now figuring out the search functionality. When I realized that the weblog module doesn’t allow easy searching by title I was amazed. When I further realized that the integration of weblog module with the search module is a <rant>woeful, klunky</rant> mess I was dumbfounded. How is it that a content management system with as much going for it as ee has a flaw of this size right at the center?</major_rant>
Anyway, after staring at the problem for about an hour I figured I was going to have to write some custom code for handling standard searches. Then I had the bright idea of looking here on the message boards, and wallah! Took me about 15 minutes to get it functional and another half hour to get it configured.
I am truly amazed that EE doesn’t come with this functionality out of the box. I am further amazed that more people aren’t screaming about it.
