You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We've got a large TYPO3 v7 installation that has thousands of pages built with TemplaVoila. We're using https://github.com/alexanderschnitzler/templavoila/ as TemplaVoila-Extension. We're slowly switching to fluidpages+fluidcontent now, which means that both fluidpages and templavoila is used for page rendering.
New pages are built with fluidpages and get the page's "backend layout" setting set to "Fluid pages".
Problem
Every page (even if the backend layout is not set to "fluid pages") has the "Page Layouts" tab, and upon saving the tx_fed_page_controller_action field is saved. This is no problem for subpages because the empty-valued "Parent decides" section is there.
But for the root page misses this "Parent decides" page layout, and so the first fluidpages layout gets pre-selected. This means that simply changing the root page's title or TSconfig sets tx_fed_page_controller_action.
This leads to the problem that FluidTYPO3\Fluidpages\Provider\PageProvider::postProcessDataStructure (a hook called by flux flux' getFlexFormDS_postProcessDS) overwrites $dataStructArray even for pages that do not use the Fluidpages backend_layout.
In turn this means that TemplaVoila is unable to render the page content in "Web>TV Page" backend module.
Possible solution
FluidTYPO3\Fluidpages\Provider\PageProvider::getControllerActionReferenceFromRecord should check if the page's backend_layout (or parent pages backend_layout_next_level) is actually set to fluidpages__fluidpages.
I just see that PageService::getPageTemplateConfiguration should check that.
The text was updated successfully, but these errors were encountered:
cweiske
added a commit
to mogic-le/fluidpages
that referenced
this issue
Sep 29, 2017
When mixing both fluidpages and templavoila page layouts,
the page's backend_layout setting needs to be checked to
make sure that fluidpages is responsible for handling the
rendering.
Resolves: FluidTYPO3#366
When mixing both fluidpages and templavoila page layouts,
the page's backend_layout setting needs to be checked to
make sure that fluidpages is responsible for handling the
rendering.
Resolves: FluidTYPO3#366
When mixing both fluidpages and templavoila page layouts,
the page's backend_layout setting needs to be checked to
make sure that fluidpages is responsible for handling the
rendering.
Resolves: FluidTYPO3#366
Context
We've got a large TYPO3 v7 installation that has thousands of pages built with TemplaVoila. We're using https://github.com/alexanderschnitzler/templavoila/ as TemplaVoila-Extension. We're slowly switching to fluidpages+fluidcontent now, which means that both fluidpages and templavoila is used for page rendering.
New pages are built with fluidpages and get the page's "backend layout" setting set to "Fluid pages".
Problem
Every page (even if the backend layout is not set to "fluid pages") has the "Page Layouts" tab, and upon saving the
tx_fed_page_controller_action
field is saved. This is no problem for subpages because the empty-valued "Parent decides" section is there.But for the root page misses this "Parent decides" page layout, and so the first fluidpages layout gets pre-selected. This means that simply changing the root page's title or TSconfig sets
tx_fed_page_controller_action
.This leads to the problem that
FluidTYPO3\Fluidpages\Provider\PageProvider::postProcessDataStructure
(a hook called by flux flux'getFlexFormDS_postProcessDS
) overwrites$dataStructArray
even for pages that do not use the Fluidpagesbackend_layout
.In turn this means that TemplaVoila is unable to render the page content in "Web>TV Page" backend module.
Possible solution
FluidTYPO3\Fluidpages\Provider\PageProvider::getControllerActionReferenceFromRecord
should check if the page'sbackend_layout
(or parent pagesbackend_layout_next_level
) is actually set tofluidpages__fluidpages
.I just see that
PageService::getPageTemplateConfiguration
should check that.The text was updated successfully, but these errors were encountered: