User tests: Successful: Unsuccessful:
Pull Request for Issue #12829.
This PR implements indexing of the custom fields for a component. This is controlled on a per field basis, where you can select if the content should be just added to the search index or handled as a taxonomy or both or actually none of the above. You can then implement this feature for your respective finder plugin with a single line of code.
Each custom field has a new option in its edit screen where you can select how the indexer should treat this field. The finder plugin then has to call Helper::addCustomFields($item, 'context');
and the rest is just magic. ;)
Right now this is implemented for com_content and com_contacts.
The documentation needs to be amended to contain how to implement this feature for third party finder plugins.
Status | New | ⇒ | Pending |
Category | ⇒ | Administration com_fields com_finder Language & Strings Front End Plugins |
Labels |
Added:
Language Change
?
|
Nice, how would the data be represented on the site part in a search result?
Nice, how would the data be represented on the site part in a search result?
If it is a taxonomy, it would simply use the given string in a dropdown. Otherwise it wouldn't display the custom fields by default. For output, you should create your own layout, maybe load custom fields again or similar stuff.
Labels |
Added:
?
Removed: ? |
I have tested this item
Tested with three different fields:
Great PR! Thank you Hannes.
We installed this PR with the prebuilt package and smart search does not work at all (even not with normal content)
Can you be a bit more specific? Does it return any search results or do you get a white screen in the frontend or backend? Since this only changes how stuff is indexed and doesn't do anything related to the actual searching, this might even be a new bug.
Article Content is for example cheeseburger and when you search for cheeseburger, the article can't be found at all. It says that there are no search results for that.
I think I found the issue and it is not related to this PR. I'm guessing that you wrote an article, saved it and then went to the frontend searching for it, right? We are storing the current time and date as publish_start date. In the SQL query to retrieve the results, we do compare that timestamp with the current time minus the seconds. That last part is done so that such a query doesn't change every second and the database has a chance to cache it. So if you wait a few more seconds until the next minute ticks around, the results should show up. I was able to recreate exactly that behavior. But: All of this is not related to this PR.
I have tested this item
testet with 3 different custome fields:
Content Field: tet and editor
contact field: text
Thanks a lot Hannes!
Status | Pending | ⇒ | Ready to Commit |
RTC
Labels |
Added:
?
|
Status | Ready to Commit | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2022-05-20 10:46:09 |
Closed_By | ⇒ | rdeutz |
@Hackwar Look like we attempted to index custom fields before already in fields system plugin https://github.com/joomla/joomla-cms/blob/4.2-dev/plugins/system/fields/fields.php#L512
However, look like that code is not working at all. With the feature introduce in this PR, what should we do with that existing code ?
That code is pretty much useless. We should delete it entirely.
This also solves #13338