Jump to content

[Solved] Admin search in custom fields not working as expected


rash
 Share

Recommended Posts

Hi guys,

I tried to customize the admin search by adding more fields to be searched, following this older thread. Modules/Core/ProcessPageSearch promised to be an easy thing, as you just select the (text/textarea) fields you want to include. Sadly, content in this additional fields doesn’t get found at all. I cleaned the module cache, saved a few test pages etc. but there’s nothing found beside text in the title field. Am I missing something?

Link to comment
Share on other sites

This doesn't help you much, but I can confirm that adding fields as you describe works fine for me.

Is it possible that there's some problem with searching in the additional fields – for example, some hidden formatting that's interfering with the search? It might be worth setting things up to search in one of those fields only (and not in the title field) to see what happens.

And have you checked that the default search operators (as defined in the module settings) are suitable?

Link to comment
Share on other sites

Thanks for yor reply @BillH, while it didn’t help me in a direct way, it did so indirectly. If A works on B  but not on C, it’s a good idea to investigate the differences between B and C. Although I don't know your environment, I found one thing I suspected to be possibly specific and this first trial already brought the little devil on stage: all included fields reside in Repeater Matrix fields. As soon as I take them out and keep them as fields of the page itself, everything is running smooth.

So I redefine my question: Is it possible to include text or textarea fields of Repeater Matrix fields into the admin search scope? (I guess the problem will be the same with simple Repeater fields.)

Link to comment
Share on other sites

As far as I can tell, the answer to your question is no, not directly. And it would be useful for me too if this could be done!

If you include a text field in a repeater field, the site search doesn't seem to construct the correct selector. I tested this by selecting "View all" with debug turned on in config.php so that the selector appears at the bottom of the results on the Page Search page.

For example, if (in addition to title) we add a field named text_in_repeater which is used in a repeater field named my_repeater, and if we search for "foobar", the relevant element of the selector would be:

title|text_in_repeater%=foobar

This doesn't work. To get the result we want, it would need to be:

title|my_repeater.text_in_repeater%=foobar

I don't know if this is something in PW that could be improved, or whether it must be this way for some reason. Or perhaps I'm missing something.

Anyway, I can think of a couple of ways of dealing with this.

The first would be to set up a field of type Cache, and include the fields you want to find in that. I haven't tested this for the purposes we're discussing, but my guess is that it'd work - but I could be wrong!

If a Cache field doesn't work, another method would be to set up a text field, and then hook on Pages::saveReady (probably in ready.php) to add the searchable content you want to that field.

 

 

  • Like 1
Link to comment
Share on other sites

I agree with your problem assessment and know the repeater.field construction from several front end searches/selectors. It’s probably a limit of dragging and dropping fields instead of setting up selectors manually. As fields inside a repeater stay ordinary fields with sort of a virtual framework around them, the field select lists only the basic fields without any knowledge of their repeater context. (If I remember it correctly, there is a similar limitation at FormBuilder’s drag & drop field mapping.)

Your first solution proposal sounds very interesting, though I’ve never even recognized the existence of the field type Cache before. So I did what you suggested and got pretty excited, but only until I tried to include my astonishing new Cache field to the search list: it’s not offered as an option. Obviously the select is restricted to text and textarea fields with no exception.

As long as I don’t find anything better, I will solve it with your proposal #2. It might not be the most elegant thing on earth, but definitely a sturdy workaround and therefore a very good idea. Thanks a lot for it!

  • Like 1
Link to comment
Share on other sites

@BillH Meanwhile the hook is working. All data is collected in one textarea that I’ve set to hidden. It still is a workaround in the sense of not going the direct way, but it does what I wanted to achieve without any noise or bad smell, so  I would call it an excellent solution. Means: my efforts on searching for something different declined dramatically. Here is the complete hook – less for you as the "inventor", but for others that may get stuck at the same point. I keep the code in /site/templates/admin.php as it is admin related only, but /site/ready.php would work as well.

<?php

$wire->addHookAfter("Pages::saveReady", function($event) { 
	
	$page = $event->arguments(0);
	$page->of(FALSE); // disable page formatting
  	$cache = ""; // string collecting the single fragments
	
	if ($page->template == "invoice" || $page->template == "standard") { 
		// blocks is a Repeater Matrix field with the types item and text
		foreach($page->blocks as $block) {	
			if ($block->type == "item") {
				$cache .= $block->title." ";
				$cache .= $block->body." ";
			}
			else if ($block->type == "text") {
				$cache .= $block->body." ";
			}
		}
		// notes is a direct child of $page
		$cache .= $page->notes." ";
	}
	else if ($page->template == "customer") {
		// cust_base is of (pro) field type Combo, it stores data different
		// from Repeater Matrix fields but shares a similar syntax 
		$cache .= $page->cust_base->street." ";
		$cache .= $page->cust_base->city." ";
		$cache .= $page->cust_base->shorthand." ";
		$cache .= $page->cust_base->phone." ";
		$cache .= $page->cust_base->email." ";
		$cache .= $page->notes." ";
	}
	else if ($page->template == "contact") {
		// cust_contact is a Combo field too
		$cache .= $page->cust_contact->prename." ";
		$cache .= $page->cust_contact->surname." ";
		$cache .= $page->cust_contact->phone." ";
		$cache .= $page->cust_contact->email." ";
		$cache .= $page->notes." ";
	}
	// searchcache is a simple Textarea field that can be included
	// as a searchable source in Modules/Core/ProcessPageSearch
	$page->searchcache = $cache;

});

?>

 

  • Like 1
Link to comment
Share on other sites

  • rash changed the title to [Solved] Admin search in custom fields not working as expected

Looks good. And the way you've used a "type" field in the blocks repeater has given me a really good idea for how to deal with a completely different issue on a site I'm developing!

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...