adrian

@fruid - the selector field is part of the PW core. You can limit the available fields with this setting "limitFields" => ["field_one","field_two"] Hope that helps.

Did you recently update the main Hanna module? @teppo's helper hasn't been updated to support that new version yet.

Try calling the function like: \ProcessWire\myFunction()

@teppo - sorry for the barrage. Again, don't worry about this if it's not important to you, but I noticed an issue with highlighting in the auto description if there is punctuation in the search, eg: https://ian.umces.edu/search/?q=bird's+head Note the last result: "Science communication training for West Papua, Indonesia" doesn't highlight "Bird’s Head" because it's not a regular single quote character used for the apostrophe. I wonder if highlight matching can / should ignore punctuation characters?

@ryan - also wondering what you think about supporting multiple operator options in the ProcessPageSearch settings? I am quite liking the *=~*= combination.

Hi @teppo - I've been playing around with multiple operators (https://processwire.com/docs/selectors/operators/#using-more-than-one-operator-at-a-time). I think you mentioned that these aren't supported, so please feel free to ignore this request, but what I discovered when using this operator combination: *=~= is that the grouping feature no longer works if PW fails to find any results via *= and moves on to ~= All results end up being listed under the All tab with no other tabs shown. For now I've gone back to my old approach to adding the tabs which works with this operator. I have also played around with the #= operator which I think will need some special handling to support because of the need to additional additional quotes and escaping. Just rambling out loud here - I also played around with adding basic support for swapping between *= and ~= depending on whether the user's search term includes double quotes. I almost stuck with that approach but I am honestly not sure how many non-tech users know about quoting search terms, so I thought the *=~= was probably better for most people.

@ryan - just playing around with some of the new options here and they are really awesome, thank you! I was initially confused about how to use this example: +(foo bar) or +"foo bar" indicates the phrase "foo bar" MUST appear My experiments showed this. Unless I am missing something, to use the double quote option, you need to have two sets, with the inner set escaped. This is OK, but I feel like perhaps it could be better documented. The other thing I have noted is a feature request to add support for excluding stopwords when doing partial matches. For example, "University of Queensland" is great when you're searching for the phrase, but if you are using multiple operators at a time, eg: *=~=~|= you really don't want that last operator (~|=) to match the "of" if the other words don't exist. Is there a way to do this already, or is it something that you could support fairly easily? Or, would you recommend that we do this at the server level using MySQL's "ft_stopword_file" setting?

How big is the DB for the site? The backup mechanism built into the upgrade process (and also via ProcessDatabaseBackups) doesn't handle large DB's very well at all. I actually recently requested that Ryan consider changing the latter to use native backup tools (ie mysqldump) to avoid this. Does the upgrade work OK if you just tell it not to backup? I don't honestly see the point in the backup while upgrading - PW upgrades almost never make changes to the DB anyway.

Thanks @Zeka - I wonder why I am not seeing the issue here? I understand your changes, but not really sure why they are necessary. Oh well 🙂 Anyway, thanks very much for the fix - I have made that change (and also changed it in the Tracy logs panel) and committed a new version. Thanks again for all your efforts and have a great weekend!

@teppo - I looked into the issue with truncation of entities a little more and it seems like there are a couple of different approaches to fix this. The simplest seems to be to simply remove any trailing bits of entity that is left over, eg: $value = rtrim(preg_replace('/(?:<(?!.+>)|&(?!.+;)).*$/us', '', $value)); as mentioned here: https://www.drupal.org/project/drupal/issues/2279655#comment-8843201 - there is some other useful discussion there about this issue. Another approach I've come across is to calculate the length by treating the entities as a single character like they detail here: https://gist.github.com/andykirk/b304a3c84594515677e6 and https://alanwhipple.com/2011/05/25/php-truncate-string-preserving-html-tags-words/ I tried the first approach and it seems to work fine. Hopefully this might save you a bit of time. This is where I've put it for now: protected function formatResultAutoDesc(string $match, string $index, string $desc): string { if ($match !== '') { $match_length = mb_strlen($match); $add_prefix = (empty($desc) || mb_substr($desc, -3) !== '...') && (mb_strpos($match, '...') === 0 || mb_substr($index, 0, $match_length) !== $match); $add_suffix = mb_substr($index, -$match_length) !== $match || mb_strrpos($match, '.') !== $match_length; // Remove scraps of HTML entities from the end of a strings $match = rtrim(preg_replace('/(?:<(?!.+>)|&(?!.+;)).*$/us', '', $match)); $match = ($add_prefix ? '...' . $match : $match) . ($add_suffix ? '...' : ''); } return $match; }

Ah, thanks for the help finding that. The only change I have made to that panel since 4.21.7 is this: https://github.com/adrianbj/TracyDebugger/commit/98fae74bcdb5e993d20f9fda37133c7979f39698#diff-2e20cde51fd606941fbeee53c0a07be98e04a3bd86e420f9fb5d10d54a28d0b1R56 But I can't see how that would break things. I am curious if there is something unusual in your PW logs that might be breaking the JS side of things somehow?

Hi @Zeka - there have been a lot of changes to both this module and also the Tracy core since 4.21.7 so I am not quite sure where to start but I think that is a JS error, correct? Is there any more info in the browser dev console about this error?

Thanks @teppo This exact text in a textarea with a HTML Entity Encoder textformatter should allow you to replicate the issue. After attending a former colleague's birthday party, Bill Dennison recounts fond memories of time he spent with Tony Larkum in Australia and the United States that spanned from the 80's through early 2000's. Yes, sorry about that 🙂

I just changed the $desc_max_length from 255 to 265 and that fixed it, so I think my last suggestion about it truncating in the middle of the &#039;s is correct. Here is the output of $value from ___renderResultDesc() which confirms it! <div class="{classes.result_desc}">Tony Larkum's 80th Birthday Party ... After attending a former colleague's birthday party, Bill <strong class="{classes.result_highlight}">Dennison</strong> recounts fond memories of time he spent with Tony Larkum in Australia and the United States that spanned from the 80&#0...</div>

@teppo - just took a better look at this and it is related to the HTML Entity Decoder textformatter that I have applied to the excerpt field. If I dump the content of $index in the Renderer::getResultAutoDesc method, I see this: 'Tony Larkum's 80th Birthday Party ... After attending a former colleague&#039;s birthday party, Bill Dennison recounts fond memories of time he spent with Tony Larkum in Australia and the United States that spanned from the 80&#039;s through early 2000&#039;s. What is interesting to me is that the &#039; in "former colleague&#039;s birthday" looks as expected, but the one in "the 80&#039;s through" is converted to that � icon. If I add this line: $index = $this->wire('sanitizer')->unentities($index); then it works as expected, although I don't think we want to do that. I feel like this is somehow related to one of the regexes and a " 's " right at the end of the autodesc. Maybe it's truncating the &#039;s to something like &#03 which it doesn't know how to display?