Repository navigation
Search result shows hidden content parts #377
Description
We updated flowpack/elasticsearch-contentrepositoryadaptor to 7.0.6 (from 6.0.6). In the search result there are now content-parts (elements from the content tree) shown which are hidden in Neos (Before that the result did not show the hidden parts).
These elements are part of the indexed fulltext.
Activity
mariofischer commentedon Mar 22, 2021
Additional clarification: The problem seems to be that the content of a node is being indexed into the page fulltext even if the parent node is hidden.
dfeyer commentedon Apr 9, 2021
This issue duplicate this one:
#214 (comment)
kdambekalns commentedon Feb 21, 2022
Am no longer sure this is a duplicate. Even though #214 is quite old, I am seeing this issue now after an upgrade of ESCR from 6 to 7 – now hidden nodes are returned that were not found before.
Fact: Both indexes (old and new) do contain data about the nodes, and the data itself does not differ (both are not marked as hidden in the index.)
The question thus is: Did the code fetching the nodes from the ES result change in that regard? It does not look like it for me: 6.0.6...7.0.9#diff-5310f1e603b84f1f7463df8670be1896e0cf5f7c3a32b4aa0a8f2a374c5eb6c4L833-L872
Does that mean the CR changed it's behaviour? But I did not update that… 🤔
daniellienert commentedon Feb 23, 2022
Hey @kdambekalns, thats quite interesting. Obviously we have several related problems here:
I am also pretty sure, that this can be solved with current CR as somehow flowquery is also capable to handle it correctly.
Wat do you think about a brainstorming session to discuss some approaches?
kitsunet commentedon Feb 23, 2022
I would also be interested then :)
kdambekalns commentedon Feb 23, 2022
It would be a pleasure. Suggest a date/time starting this Friday that suits you. :)
TheLalaMan commentedon Oct 25, 2022
Any news on this? Our editors also noticed this recently...
mficzel commentedon Nov 10, 2022
I wonder wether the issue is in the elasticsearch or in the
convertHitsToNodesmethod.In older versions we often had the issue that we wanted the first 10 results but only got 8 because during mapping of the elastic result to a list of nodes the nodes with hidden parents were thrown out. This was a problem aswell but way harder to spot.
Checked further ... the method used internally is the
$contextNode->getNode($nodePathFromElasticSearch)... imho getNode should return null for nodes that are not accessible and am pretty sure it did in the past.mficzel commentedon Nov 10, 2022
As a hotfix the aspect here https://gist.github.com/mficzel/292d6dab09ea0ef9017b804ad49f97a2 removes the items with hidden parents from the results. Totally not nice but it kinda works ...
dlubitz commentedon Mar 23, 2023
Is there already some solution discussed? Our customers also complain about "hidden (by parent) content nodes" which appear in search results.
I had another look into the diff 6.0.6...7.0.9#diff-5310f1e603b84f1f7463df8670be1896e0cf5f7c3a32b4aa0a8f2a374c5eb6c4L833-L872 as @kdambekalns already had. It might be the case that before these changes the hidden nodes never were indexed, because the context was using the default of
invisibleContentShowninstead of (now) setting it toinvisibleContentShown => true.See:
I guess this was necessary to handle the time controlled visibility of nodes. But then IMHO it misses some check if some node in the parent path is hidden.
BUGFIX: Skip content with hidden parent nodes in fulltext index
BUGFIX: Skip nodes with hidden parent nodes in index
BUGFIX: Skip content with hidden parent nodes in fulltext index
BUGFIX: Skip nodes with hidden parent nodes in index