[BUGFIX] Check BackendUtility::getRecord before using it in array_merge

[mikelwohlschlegel]

This checks BackendUtility::getRecord before using it in array_merge to avoid an exception.

We had the following problem:
There seems to be a difference in processing a history rollback between v11 und v12.

Steps to reproduce:

• Add a new container to a page
• Add a new content element to the same page
• Move the new content element into the new container
• Go back to the history and rollback ALL this steps

v11 --> WORKS
v12 --> EXCEPTION

While step debugging, I found out that $datamap['tt_content'] in

content_defender/Classes/Hooks/DatamapDataHandlerHook.php

Line 34 in dab78e7

if (empty($datamap['tt_content']) || $dataHandler->bypassAccessCheckForRecords) {

is empty in v11 and not empty in v12.
My guess is, that v12 processes every single step in v12, while v11 just deletes the newly added elements (not proofed).

I'm not sure if this can maybe cause some side affects? What is the intention of merging the arrays here?

[IchHabRecht]

it seems you doing the same thing twice now?

[mikelwohlschlegel]

@IchHabRecht You're right. I forgot to delete the original line. The commit is updated. Thanks.

[Bunnyfield]

BackendUtility::getRecord() is typed to return array|null, so this call site needs the guard regardless of how the datamap ends up with an unresolved reference. We hit the same crash independently via a different workflow in L10nmgr, so this fix should be merged.

[moritz-ngo]

BackendUtility::getRecord() is typed to return array|null, so this call site needs the guard regardless of how the datamap ends up with an unresolved reference. We hit the same crash independently via a different workflow in L10nmgr, so this fix should be merged.

This PR works like charm, would be great if it could be merged