Possibility to deactivate functionality for extension when editing records on storage folders (pages type 254)?
josefglatz opened this issue · 10 comments
Hi,
I have the situation, that a backend_layout is inherited to a page with type storage folder (254). I don't find the actual reason why the content defender "works" on a sysfolder (storage folder). Maybe since an update of the extension.
Background of my question/issue: I use a storage folder with news records and using settings like described here does not work. I have to explicitly create a dummy backend_layout with the allowed content elements and activate it on the news storage folders.
Is this something know? A known issue/feature? Is it on purpose? is it a side effect of anything?
Hi @josefglatz
content_defender doesn't care about the page doktype. According to the linked news documentation the same configuration key "allowed" is used for the configuration. This is why content_defender uses this configuration for the validation. But to be honest I still don't get the problem from reading your descrption. If you restrict the content elements for news, you should still be able to create news records and use those allowed content elements inside. Don't you?
I've noticed a strange behavior which sounds related or similar to the issue described here.
We're using inline (IRRE) tt_content elements for a custom table and override the colPos with an arbitrary value (e.g. -1 or 999) to distinguish them from "normal" page content elements. The records of this custom table are stored in a sys_folder page. It seems content defender retrieves the corresponding backend layout configuration (which is derived from backend_layout_next_level on the root page) and somehow uses the allowed and disallowed settings of the backend column which has colPos = 0 set, although the processed records have colPos set to a different value (e.g. -1 or 999 etc.).
In other words, content defender seems to apply allowed and disallowed settings to the inline content elements, although it shouldn't in case where the record's colPos does not match any backend column configuration.
A potential workaround would be (as @josefglatz mentioned) to create a custom backend layout just for sys folders to circumvent this behavior.
This happens with TYPO3 v10 for us.
Hi @thasmo
Would you mind to provide your TCA configuration for testing purpose? Furthermore I fear to have some issues understanding the current problem. content_defender only works on tt_content records. According to your description, I understand that you store records of a completely other (custom table) on the sys_folder page? Where is the relation to content_defender and tt_contentn then?
Where is the relation to content_defender and tt_contentn then?
We have a table tx_app_vacancies which defines an inline field for tt_content records:
'elements' => [
'label' => 'Elemente',
'config' => [
'type' => 'inline',
'foreign_table' => 'tt_content',
'foreign_field' => 'parent',
'foreign_table_field' => 'parent_table',
'foreign_sortby' => 'sorting',
'appearance' => [
'collapseAll' => true,
'showSynchronizationLink' => false,
'showPossibleLocalizationRecords' => true,
'showRemovedLocalizationRecords' => false,
'showAllLocalizationLink' => false,
],
'overrideChildTca' => [
'columns' => [
'colPos' => [
'config' => [
'default' => -1,
],
],
],
],
],
],The default backend layout looks like this:
mod {
web_layout {
BackendLayouts {
default {
title = Standard
config {
backend_layout {
colCount = 1
rowCount = 3
rows {
1 {
columns {
1 {
name = LLL:EXT:app/Resources/Private/Language/locallang_tca.xlf:colpos.header.label
colPos = 1
maxitems = 1
allowed {
CType = app_header,app_hero
}
}
}
}
2 {
columns {
1 {
name = LLL:EXT:app/Resources/Private/Language/locallang_tca.xlf:colpos.content.label
colPos = 0
disallowed {
CType = app_header, app_hero, app_footer_link
}
}
}
}
3 {
columns {
1 {
name = LLL:EXT:app/Resources/Private/Language/locallang_tca.xlf:colpos.footer.label
colPos = 2
maxitems = 1
allowed {
CType = app_footer_link
}
}
}
}
}
}
}
}
}
}
}
What seems to happen is that the value of mod.web_layout.BackendLayouts.default.config.backend_layout.rows.2.columns.1.disallowed.CType = app_header, app_hero, app_footer_link is applied to the inline tt_content records (although the records have colPos set to -1 by default, as defined in the TCA) and so the three content element types do not show up in the CType select field.
Hi @thasmo,
Thanks for sharing your information. I was able to find and fix two problems here. First it seems content_defender needs to care about the default value of the colPos configuration itself as it's not applied directly to the internal processing row of the FormEngine. Secondly I excluded inline elements of being processed at all by the CType processor - means as soon as an IRRE relation to a tt_content element is found applying any backend layout configuration is denied.
@thasmo and @josefglatz I would be very happy if you could check #117 and tell me if this solves your problems.
@IchHabRecht, this seems to do the trick! 👍 Thank you!
The pull request is merged and will be available with the next release.
@IchHabRecht, do you have an estimation for when the next release willl most likely be published? We're eager to integrate this into our projects. Thank you!
@IchHabRecht Any chance? :) Thanks!
Hi @thasmo,
I released a tag but due to TYPO3 restapi issues I'm unable to release the ter version. Hope this helps. Its always a pleasure to spend my spare time ;-)