codappix / search_core

TYPO3 CMS 8.x Extension with basic Integration of Elasticsearch
https://search-core.readthedocs.io/en/latest/
12 stars 9 forks source link

Relations are not resolved while adding new records #112

Closed DanielSiepmann closed 6 years ago

DanielSiepmann commented 6 years ago

If someone inserts a new record, relations are resolved with "N/A" due the fact that a hook is used which is triggered before relations are saved.

We have to check whether there is a later hook where relations are already persisted and should use that instead.

The relevant code is:

                    't3lib/class.t3lib_tcemain.php' => [
                        'processCmdmapClass' => [
                            $extensionKey => \Codappix\SearchCore\Hook\DataHandler::class,
                        ],
                        'processDatamapClass' => [
                            $extensionKey => \Codappix\SearchCore\Hook\DataHandler::class,
                        ],
                    ],

in ext_localconf.php. This is only relevant for TYPO3 Backend, not for Form-Integration as we recommend to use our finisher as last finisher after all database operations.

DanielSiepmann commented 6 years ago

@martinhummer tried the following: https://github.com/martinhummer/search_core/blob/develop/Classes/Domain/Index/TcaIndexer/RelationResolver.php#L53 His idea was to use dbAnalysisStoreExec.

And he has written a short test: https://github.com/martinhummer/search_algolia/blob/master/Tests/Functional/Connection/Algolia/ResolveRelationsTest.php#L41

DanielSiepmann commented 6 years ago

Datastructure in 7.6 LTS looks different then in test case:

array(1 item)
   tt_content => array(1 item)
      NEW5a8f261568349974965182 => array(30 items)
         colPos => '0' (1 chars)
         sys_language_uid => '0' (1 chars)
         header => '' (0 chars)
         header_layout => '0' (1 chars)
         header_position => '' (0 chars)
         date => '0' (1 chars)
         header_link => '' (0 chars)
         rowDescription => '' (0 chars)
         _TRANSFORM_bodytext => 'RTE' (3 chars)
         bodytext => ' ' (2 chars)
         layout => '0' (1 chars)
         spaceBefore => '0' (1 chars)
         spaceAfter => '0' (1 chars)
         section_frame => '0' (1 chars)
         hidden => '0' (1 chars)
         sectionIndex => '1' (1 chars)
         linkToTop => '0' (1 chars)
         starttime => '0' (1 chars)
         endtime => '0' (1 chars)
         fe_group => '' (0 chars)
         editlock => '0' (1 chars)
         categories => '3,4,5' (5 chars)
         tx_gridelements_container => '0' (1 chars)
         pid => '108' (3 chars)

Categories are provided as comma separated list of UIDs. Still looks like we can go with processDatamap_afterAllOperations.

I would try to not execute internal API of the DataHandler even if calling the provided method dbAnalysisStoreExec would not break anything as it looks.

martinhummer commented 6 years ago

There seems to be a problem with IRRE relations of type inline. The Uid is not substituted by Datahandler while using substNEWwithIDs and therefore a uid value like NEW5aa2a9d347783879505124 gets passed to Datahandlers processRecord

DanielSiepmann commented 6 years ago

The used extension is https://extensions.typo3.org/extension/store_hours/ with TYPO3 CMS 8. I'll check that out. We should already replace the string before calling processRecord, so I'm wondering but will check that.

DanielSiepmann commented 6 years ago

Also we should move shouldProcessHookForTable inside of processDatamap_afterAllOperations right at the beginning of the loop.

martinhummer commented 6 years ago

While digging into this issue again, i discovered an error in the TCA config of the store_hours extension.

After i resolved this problem, the indexing worked as expected. Therefore this issue can be closed.

But because of this error, the substNEWwithIDs is empty and the uid of the record is a string like ´NEW78672364`. Nevertheless search_core is/was overlaying the more detailed TCA exception, because it is strict about passing an integer uid to: https://github.com/Codappix/search_core/blob/ca5339fb314afc7dad5b842a977f4e21c40331e8/Classes/Hook/DataHandler.php#L120 and throws an exception which is misleading in this case. For integrators it can be difficult to find such TCA errors, while search_core is installed.