\FluidTYPO3\Fluidpages\Provider\PageProvider::loadRecordTreeFromDatabase does not check if returned record from recordService is null

[wazum]

If
$record = $this->recordService->getSingle($this->getTableName($record), '*', $record[$parentFieldName]);
returns null (e.g. one of the parent records is set to deleted), this leads to an exception.

[NamelessCoder]

This isn't exactly related to the patch you did, but if you're experiencing this problem that would indicate you're trying to view or edit a page that does not exist anywhere in the page tree. Additionally it indicates that the page actually wasn't deleted with TYPO3 because it would have restricted deletion if there were active sub-pages (and if recursive deletion was allowed in user settings, it would've deleted the child pages first afaik).

There might be something more to explain why you're actually experiencing this issue. Technically, it shouldn't be possible to experience this if you manage the pages in normal ways through TYPO3.

That said, the code does return null from this method and this has to be handled. Just be aware that something else is probably broken on your setup ;)

[wazum]

@NamelessCoder Certainly possible, it's a large installation with some upgrades already, and the problem occurs when running the reference index check/update … (actually prevents it from running …)

[bahammes]

@wazum I get an error at the same line when opening pages in the frontend (TYPO3 8.7.22, flux 9.1.0 + fluidpages 4.3.0). The page definitely exists in the page tree. The error occurrs if i open a page in the frontend whose parent page is marked as hidden.
I get the error message Argument 1 passed to FluidTYPO3\Flux\Provider\AbstractProvider::getParentFieldName() must be of the type array, boolean given.
The documented return type of \FluidTYPO3\Flux\Service\RecordService::getSingle is not correct, the actual return type is array|null|boolean because the reset returns false if the array is empty.
Your commit only checks for null !== $record. Since this is the same issue, can you please update the condition in your pull request to !empty($record)

[wazum]

@GertHammes I updated the pull request

[NamelessCoder]

Fixed via 74f5fdf.

[franzkugelmann]

For me the change in 74f5fdf does not fix the issue, but just result in a different error:

Tried resolving a template file for controller action "Page->default" in format ".html", but none of the paths contained the expected template file ().

If the parent page is hidden, and the current page tries to get the PageLayout from higher up in the rootline, the Layout cannot be found because in RecordService::getSingle() the enableFields (hidden, startTime, endTime) are taken into account and the rootline is broken. Always using BackendUtility::getRecord() fixed that.
Not sure if that triggers problems at other locations of the code where the record of a hidden page should really NOT be loaded.

[NamelessCoder]

@franzkugelmann This is not the same issue. Two other issues are potentially related: 2a269ce (merged) and #411 (not merged, may be hidden by the other issue, only applies on certain setups).