I got this. This PR depend of other?

No, but there is another bug that is fixed in #20185. Looks like this strict query handling was disabled again in a later version of 4.0-dev. Idk. Maybe update your 4.0-dev branch to the current state? It works there...

I test now without this PR, and give the same error. So, is not this PR. And yes, the branch is up to the current state

Ok, the error I get is fixed here #20185. Beside code review will be good test this, but we need #20185 merged for that

#20185 has been merged in here. Happy testing. 😄

Got this:
Warning: Invalid argument supplied for foreach() in .....components\com_finder\tmpl\search\default_results.php on line 49

All work ok. Waiting for the fix of the error

This was a bug because of a conflict between the original code and #20185. In #20185 it was changed to "Items" and somehow that change was overwritten here. Should work now.

I have tested this item ✅ successfully on a52bd58

I've updated the PR and fixed some things. It would be nice if you could test this again and if we could get one more tester for this. 😄

The URLs don't match where the only difference should be the highlight query string.

http://localhost/joomla-cms-j4finder_highlighter/index.php/blog/5-your-modules?highlight=WyJqb29tbGEiXQ==

http://localhost/joomla-cms-j4finder_highlighter/index.php/component/content/article/5-your-modules

The issue here is, that FinderIndexerAdapter::getURL() returns the wrong URL. That method should actually be deprecated... We have to fix the finder plugins for that.

I've changed the way the URLs are produced, which should fix the issue that you had and also cleaned up the result layout. Please test again.

Please delay that. I made a mistake. I will report back when I fixed the issue.

Ok, I got this right now. I removed the FinderIndexerHelper::getContentPath() method, since we don't need that with the new router anymore. I also cleaned up the finder plugins and improved the comments there. Last but not least, I added a cleanURL attribute after unserialising the object in the model, where I simply copy the route attribute to this. That allows us to render the clean URL in the result layout and at the same time allow the highlighter plugin to add to the URL.

So please test and have a go. 😄

Since @infograf768 requested this, I also reviewed the highlighting of search words with utf8 chars in the search results page. It turns out that \Joomla\CMS\Filter\OutputFilter::stringJSSafe() is not utf8 aware and mangles all characters that are not ASCII. I rewrote that and now it should work fine for utf8. Looking for your test, @infograf768 😉

@Hackwar
Indeed, the issue was whether in js or the method ( #20562 (comment) ).

You solved it here and utf8 is now correctly highlighted. 👍

Remains an issue here with terms surrounded by doublequotes or singlequotes. If one does not search WITH the quotes, i.e. for example 'frontale (term in text is 'frontale') then we have no suggestion. If I enter frontale no suggestion and no result but I am proposed to search for 'frontale'.
(That issue does not exist in com_search although highlighting is broken for com_search in 4.0. Works on 3.x)

The suggestions have nothing to do with highlighting. I hope no one now gets confused and delays this PR because you are bringing up unrelated bugs here.

I sincereley hope not. As usual I test a few things when I test any of your PRs. Just consider it as a note about something to remember if it can be solved or not.

As I only tested the highlighting and not the hardcoupling issue, I can't set the my test as OK on issues.joomla.org

About search for specific phrases, we can continue this talk in #20384 , is where @Hackwar change this.

I have tested this item ✅ successfully on 9834dd9

I have tested this item ✅ successfully on 9834dd9

@laoneo @mbabker
This PR is fine concerning the highlighting of terms. But I have no idea about the decoupling.

Can you have a look at that aspect and set RTC/Merge if OK?

Since this is more or less broken code and potentially creates wrong URLs, this code will not work in 4.0 anymore. Plugins from 3.x can't use it anymore and shouldn't use it now already.Am 29.06.2018 07:56 schrieb Allon Moritz notifications@github.com:@laoneo commented on this pull request.

In plugins/finder/categories/categories.php:

@@ -304,8 +306,6 @@ protected function index(FinderIndexerResult $item, $format = 'html')
$item->route = ContentHelperRoute::getCategoryRoute($item->id, $item->language);
}

•   $item->path = FinderIndexerHelper::getContentPath($item->route);
  

Is this removal necessary then or can J3 plugins still work with that code in place?

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

Is it then deprecated in J3?

I'm going to create a depreciation PR soon.Am 29.06.2018 09:26 schrieb Allon Moritz notifications@github.com:Is it then deprecated in J3?

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

PR for deprecation: #20934

I have tested this item ✅ successfully on 55057f2

I have tested this item ✅ successfully on 55057f2

RTC. Thanks

Thank you!