adrian

@sirhc - you can already export system fields, include the page ID. There are two ways to do this: 1) Make the parent page separately configurable and then visit the BCE settings on that page's Settings tab and choose the fields you want included in the export. 2) In the Module's CSV export settings, allow the user to override the CSV settings and then when they export, they can choose exactly the fields they want on each export.

Just out of interest, I recently removed cleanBasename from Custom Upload Names because it was doing weird things with filenames. It's much better without it ?

Actually @teppo - I might have found a bug. If I specify a 'results_list_group_heading' then I find that when there are more than one page of results, that heading sometimes appears twice on a page. I've changed to appending the heading I want to 'tabs_tablist' and that avoids the issue, but obviously it would be nice to 'results_list_group_heading' if possible. Let me know if you can't reproduce and I'll set up an example for you.

Thanks for the thoughtful feedback @teppo I used the Renderer::renderTabLabel hook which works great for modifying those tab labels. Regarding the heading stuff, I went with: 'results_heading' => '' and then modifying the group labels and adding those to: 'results_list_group_heading' Now I've got everything looking the way it did before but with the benefit of your core group_by code! Thanks again - this is brilliant.

A red bug icon indicates that the site is definitely in debug mode. I think perhaps you aren't having issues with turning on debug mode, but rather debug mode doesn't allow the PW Upgrade module to download modules. Did you try the $config->moduleInstall('download', true); option to see if that works for you?

Has anyone checked 3.0.174 to see if this is now fixed?

Thanks for the quick fix @teppo I set up a test search page on that site and everything works great. I am not seeing a noticeable speed difference between the tab grouping of the module vs my custom ->has() checks to exclude tabs with zero results. Still, I would like to switch over to core method, except that it doesn't seem to be possible to specify the label for tab buttons as different to the template label. In my case, it seems to be more correct to use the label for the template's parent template label - does that make sense? For example, I would prefer to see "Blog Posts", rather than "Blog Post" or "Publications" vs "Publication". The only other issue is that I like having the "results_heading" string below the tabs, rather than above and I also like having it match the currently selected template, eg: https://ian.umces.edu/search/?q=seagrass&type=media - this of course might be totally personal - not sure what others think of it, but I can't see an easy way to insert a heading between the tabs and the "results_summary_xxx", strings.

@teppo - on another note, I just got this logged error overnight: PHP Warning: preg_match(): Compilation failed: missing closing parenthesis at offset 62 in /site/modules/SearchEngine/lib/Renderer.php:388 It came from this query: https://ian.umces.edu/search/?q=Ferocactus+wislizeni+(Fishhook+Barrel+Cactus It looks like someone was trying to find that exact cactus symbol by name, but left off the trailing close parenthesis. Currently I am using: $query = $searchEngine->find($input->get->q, $findOptions); as my search query. I assumed that SearchEngine would sanitize the input, but even using selectorValue or text sanitizers don't work in this case, because they both allow parentheses. Do you think this is a situation that we should manage, or SearchEngine should take care of?

I have the same in mine, although perhaps your approach is more efficient. I went with this when outputting the tab buttons, using a ->has() to see if there are any results for the template/tab. I thought given the performance of PW's has() that this would be the best approach, but I didn't dive into it too much. I should go see what you did. foreach($types as $name => $label): if($name != 'all' && $pages->has('search_index'.$findOptions['operator'].$query->query.', template='.$name) === 0) continue; ?> <a class="button small<?=((!isset($type) && $name == 'all') || (isset($type) && $name === $type) ? ' buttonactive' : '')?>" href="<?=$page->url?>?q=<?=$input->get->q?>&type=<?=$name?>"><?=$label?></a> <?php endforeach; Those do sound like they would do the same thing. I think I'll set up a test with the module's core approach and see what happens. Thanks again.

Hey @bernhard - just resave Tracy's settings and this will go away. It only happens when updating quite old versions.

Thanks @teppo - everything looks great now. Now I guess I need to figure out if there is any advantage to using the inbuilt grouping vs my approach. Obviously it handles all indexed templates automatically, but then mine gives the flexibility to include the results from some templates under "All", but not have a dedicated tab for them which can be handy in some cases. My question for you then, is there any performance gain in using the inbuilt grouping? I haven't explored the code, but my instinct is that you're not really doing anything different to me, except for the big convenience factor of having this work so easily.

<?php $searchEngine = $modules->get('SearchEngine'); echo $searchEngine->renderStyles(); echo $searchEngine->renderScripts(); $findOptions = [ 'group_by' => 'template' ]; $renderOptions = [ 'results_grouped' => 'template.label' ]; $query = $searchEngine->find($input->get->q, $findOptions); echo $searchEngine->renderResults($renderOptions, $query); {"SearchEngine":{"version":"0.29.2","settings":{"indexed_fields":["title","summary","body"],"indexed_templates":["basic-page","home","license","licenses"],"find_args__sort":"sort","find_args__operator":"~=","index_pages_now_selector":"has_parent=1","index_field":"search_index","override_compatible_fieldtypes":"","compatible_fieldtypes":["FieldtypeEmail","FieldtypeFieldsetPage","FieldtypeDatetime","FieldtypeText","FieldtypeTextLanguage","FieldtypeTextarea","FieldtypeTextareaLanguage","FieldtypePageTitle","FieldtypePageTitleLanguage","FieldtypeCheckbox","FieldtypeInteger","FieldtypeFloat","FieldtypeURL","FieldtypeModule","FieldtypeFile","FieldtypeImage","FieldtypeSelector","FieldtypeOptions","FieldtypeRepeater","FieldtypeRepeaterMatrix","FieldtypePageTable","FieldtypePage","FieldtypeTable","FieldtypeTextareas"],"indexer_actions":[],"render_args__themes_directory":"","debugger_page":0,"debugger_query":"","debugger_query_args":"{}","uninstall":"","submit_save_module":"Submit"}}}

Thanks @teppo - I am seeing the tabbed results now. The only thing that's weird is that on the "All" tab, it shows all the results, then it shows the results for the different templates below separated by template, so each result shows up twice. Viewing specific results (by clicking on a template tab/button), they are showing correctly. Hopefully this shows what I mean. Can you see this at your end as well?

@teppo - I think I am the one who was asleep - not sure how I ended up with 'group_by option' but if I change it to 'group_by' then I get this error (maybe also PHP8 related) SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ':pf19s0X IN BOOLEAN MODE)) ) )) \n LEFT JOIN templates AS pwse_t ON pwse_t.id=p...' at line 4

I'm actually not sure why I used that and then $args['operator'] instead of simply: $findOptions['operator'] I can't see any reason at the moment not to change to the simpler version.

Please ignore the awful zurb foundation markup - this was an ASAP conversion of a site from an unusable Drupal setup so I rebuilt using the old site's markup / css. At some point this will be redone as well, but at least it all works now ? You can see though that each button adds the type and then I use that like this: $findOptions['selector_extra'] = 'template=' . $type; You can ignore the hook on Renderer::renderResult at the top - it's just for adding the thumbnails to the results.

Thanks @teppo - all those errors are now gone. I am trying out the group by template options but not seeing any delineation in the rendered results, with them all being in the same <ul> block. Perhaps I am missing something. $searchEngine = $modules->get('SearchEngine'); echo $searchEngine->renderStyles(); echo $searchEngine->renderScripts(); $findOptions = [ 'group_by option' => 'template' ]; $renderOptions = [ 'results_grouped' => 'template.label' ]; $query = $searchEngine->find($input->get->q, $findOptions); echo $searchEngine->renderResults($renderOptions, $query); I am also curious how you have handled pagination of results in this tabbed results scenario (since I am not getting it working, I am not sure yet whether this works or not). What I actually ended up doing for my project that just went live is to return all results, but then have buttons that look like tabs, but each one is for a different template and I use them to add a "type" (template) parameter to the query string, eg: https://ian.umces.edu/search/page2?type=media&q=seagrass - this ensures that pagination works within the results for that template. OT, but I am also seeing errors with the Debugger. 1) The Debug Index, Debug Page and Reindex Page buttons always gives me this error: array_map(): Argument #2 ($array) must be of type array, null given in /modules/SearchEngine/lib/Debugger.php:628 2) The Debug Query always give me: PHP Warning: Undefined array key "active" in .../modules/SearchEngine/lib/Renderer.php:371

Well, in this case, it's Teppo who is amazing ?

v4.21.52 fixes an issue with uploading images to repeatermatrix fields. This fix might also take care of a few other randomly seen bugs, although only time will tell with those. Regardless, I think this is a pretty important update for everyone.

Hi @teppo - I am excited for these new features - thanks for you hard work. Unfortunately, when I install it I get this error: Deprecated: Required parameter $query follows optional parameter $args in /Users/ajones/Sites/ecoreportcard/site/modules/SearchEngine/lib/Renderer.php on line 615 Deprecated: Required parameter $type follows optional parameter $args in /Users/ajones/Sites/ecoreportcard/site/modules/SearchEngine/lib/Renderer.php on line 718 Deprecated: Required parameter $type follows optional parameter $args in /Users/ajones/Sites/ecoreportcard/site/modules/SearchEngine/lib/Renderer.php on line 755 and then when I try to do a search, I get: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ':pf19s0X IN BOOLEAN MODE) ) )) \n LEFT JOIN templates AS pwse_t ON pwse_t.id=pa...' at line 4 Reverting to the last version instantly fixes these. Note that for my testing I am using the simple: <?= $modules->get('SearchEngine')->render() ?> approach to handle everything. Let me know if you need me to dig a little deeper.

This sort of thing is possible, but you might find life easier with https://processwire.com/modules/search-engine/ - it will also be much more performant for the end user.

The only thing I know of is: https://github.com/apeisa/Discussions I used it once on a site that had a limited life. It worked OK, but it's very low on functionality. Not sure if it should really have a modules directory given it's state, but it's also listed here: https://processwire.com/modules/discussions/

There is also this new module from @BitPoet

The problem is that Ryan doesn't seem to update the docs on the website until he commits a new master version which is I why I always use the API panel in Tracy ?

I actually find the Debug panel > Selector Queries section more useful because it shows which selector calls result in which SQL queries.