The com_finder layouts only support generating links to content with the search terms highlighted when the highlight system plugin is enabled. Should be relaxed...
Labels |
Added:
?
|
Status | New | ⇒ | Discussion |
Category | ⇒ | com_finder com_plugins |
We are not really using "assignments" but simply by offering as you have above then you kind of did it anyway
@mbabker I've looked at this long and hard and my proposal to solve this would be to send all search results through the onContentPrepare event with context com_finder.result and then the highlight plugin can react to that and do its thing. That would move the coupling from com_finder to plg_system_highlight. Would that be okay? Should we introduce a new event for this? Maybe onFinderResult? Better ideas?
We can kill the highlight plugin altogether and just replace the functionality with a custom element that will do the highlighting. So in essence if a layout needs something highlighted, pass some attributes (eg the word to be highlighted) to the CE and echo inside the CE the results of the com_finder. I think we can drop this
Whether the plugin exists or not, my main point is that generating a link with the highlight query var shouldn't be coupled to the fact that a plugin exists and is enabled. When library or component capabilities are tied directly to a single plugin, that means the capability isn't really pluggable to begin with (as in I can't replace the highlight plugin with something else and have the same functionality in core without at a minimum overriding the default_result.php
layout as well).
I've got no issue with ripping out the plugin and going CE, or making JHtmlHighlighter
, or whatever the case may be. But seriously, this if conditional just proves that there is an architecture problem.
The problem isn't to highlight the search term in the search results page. That is done via JS and the 'behavior.highlight' thingy. This feature highlights the search term (for example) on the original article page. For that we have to hand over the term to highlight in the URL, otherwise we would have to store that in the session and that brings up the question when that should be removed from the session again and you also can't hand over the URL with the highlighting. So I'm actually not really unhappy with that plugin, but I would indeed want to remove the coupling of finder to that specific plugin.
The longer I think about it, the more I like the idea of an event "onFinderResults", either in singular or plural, which then would allow to iterate through the results and in this case amend the route with the highlight parameter.
Well, considering the view fires zero plugin events in general, you're on to something to make that view hookable the same way most every other non-edit based view is.
Status | Discussion | ⇒ | Closed |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2018-05-24 17:47:47 |
Closed_By | ⇒ | Quy |
Closed_By | Quy | ⇒ | joomla-cms-bot |
Set to "closed" on behalf of @Quy by The JTracker Application at issues.joomla.org/joomla-cms/20252
How can I assign an issue to me? I would try to fix this in my finder efforts.