since i updated Typo3 from 6.2 to 8.7.13 i get the following error:
1438594406: No columns definition in TCA table tx_cmagnews_domain_model_news (More information)
UnexpectedValueException thrown in file
/kunden/211624_70794/rp-hosting/5056114/6056114/typo3cms/typo3_src-8.7.13/typo3/sysext/backend/Classes/Form/FormDataProvider/InitializeProcessedTca.php in line 48.
I already replaced all $TCA with $GLOBALS['TCA'].
Does anyone have some other ideas?
yes, the answer is that you have to delete everything in file ext_tables.php where
tables are defined like $TCA['tx_yourextensionname_domain_model_xyz'] = array() e.g.
Since newer Typo versions, control of TCA is taken by the replacement files you put in the directory Configuration/TCA or Configuration/TCA/Overrides
Related
I have a new TYPO3 9.5.15 installation and added gridelements 9.5.0 and t3sbootstrap 4.4.5 to make content elements with 3 columns in a own 1 column backendlayout which is defined in PageTsConfig.
In older TYPO3 versions, this is working fine (i.e TYPO3 7) but in TYPO3 9 I get the following error in FE:
Tried resolving a template file for controller action "Standard->three_columns" in format ".html", but none of the paths contained the expected template file (Standard/Three_columns.html). The following paths were checked:
xxx/typo3/sysext/fluid_styled_content/Resources/Private/Templates/, xxx/typo3conf/ext/gridelements/Resources/Private/Templates/, xxx/typo3conf/ext/t3sbootstrap/Resources/Private/Templates/Content/, xxx/typo3conf/ext/t3sbootstrap/Resources/Private/Templates/, ,
I've double checked and can confirm, that both, gridelements and t3sbootstrap are included in the roottemplate of the website.
As far as I found out, the templates are available in xxx/typo3conf/ext/t3sbootstrap/Resources/Private/Templates/Gridelements/
but are called ThreeColumns.html
Has anyone an idee what causes the error and how to resolve it?
Thanks in advance
At a first look it seems that there are 2 problems with your combination here:
The message "Standard->three_columns" points to a wrong static template, so I guess you included the new DataProcessing static of Gridelements, while t3sbootstrap depends on the old Plugin and USER based static.
The root path xxx/typo3conf/ext/t3sbootstrap/Resources/Private/Templates/Gridelements/ is missing in your setup.
At a second look it might even be enough to change the Gridelements static, since t3sbootstrap takes care of the root path based on that setup.
TYPO3 9.5.15
When I edit an existing category and than click the "+new" button inside the edit form, i will get the error:
#1534710048 TYPO3\CMS\Core\Exception\SiteNotFoundException
No pseudo-site found in root line of page 17
Page 17 in this case is absolute incorrect - this is the uid of the sys_category from which editing form I came from. the categories were saved on pid:6
I can do the same task from other category edit-forms, but not from all. I cannot figure out what is the difference of the categories where it doesnt work.
The basic site-configuration is configured and working, there is only one language, no workspaces.
Has anyone ever had a similar problem?
Side note: It still "works" for records which have the same uid as a pages record. It also "works" for L>0 records because they still fall back to 0.
However, this is not a core bug but a misuse of the internal DisplayCond by 3rd party extensions.
E.g. in the latest tt_address this is already fixed, see: https://github.com/FriendsOfTYPO3/tt_address/commit/4501d1f30f3381a235e447567018e6d5646ec069
So changing the TCA DisplayCond of the sys_category slug in my own extension did the trick in my setting
'displayCond' => 'VERSION:IS:false',
Extensions change TCA in ext_tables.php
Check for ExtensionManagementUtility and $GLOBALS["TCA"].
During upgrading typo3 version 7 to 8
How to solve this?
If you're the owner of this extension, it is recommended to migrate the TCA changes into the extensions' folder Configuration/TCA/ for new TCA tables, and Configuration/TCA/Overrides/ when adding fields or manipulating TCA.
This way, all changes from ext_tables.php should be moved in there, due to a better performance in frontend. See also this change:
https://docs.typo3.org/typo3cms/extensions/core/latest/Changelog/8.5/Breaking-78384-FrontendIgnoresTCAInExtTables.html
I looked at this Similar Question on here but I didn't understand half of what everyone is saying there as I'm not very familiar with TypoScript...
Let me start from my point of view: I got a backend tree in TYPO3 6.2 that looks like this:
Data is of type "Folder" where I want to store my records.
Userroles, Admins and Lawyer are of Type "Standard" while the last two contain the Plugin "Website Users".
Now I want to add a new fe_usergroup to page Userroles:
I get following error:
It's the same when I try inserting a new fe_user in Admins:
So in the other answers from mentioned question they're talking about Page-TS-Config - I looked at my Userroles Page and saw this:
and I went to the Template Analyzer and searched for allowedNewTables and deniedNewTables but no results. And to the comment: section ctrl which value has rootLevel - but those TCAs are from Extbase right? So why would they be wrong...
I must have done something wrong but I have no idea what it could be.
It worked before I think...although I don't know about the usergroups, didn't try to add a new one recently.
I placed
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::allowTableOnStandardPages('tx_myext_download');
into the ext_tables.php of myext to allow this kind of records.
Maybe that helps.
Add in Your ext_tables.php in Your Extension following code:
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::allowTableOnStandardPages('tx_your_extension_table_name');
In TYPO3, you have to define, which tables are allowed on standard pages. There is a method in the ExtensionManagementUtility, that does extacly that:
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::allowTableOnStandardPages('tx_yourtable');
If you have a look at the source, you'll see, that this method ist just one line of code that concatenates table names into the global configuration array, specifically at
$GLOBALS['PAGES_TYPES']['default']['allowedTables']
Its possible that something in your TYPO3 installation messes with this line.
Check the value of this configuration value in either the Install Tool or the Confuguration tab in the backend. If this line contains anything other than comma seperated table names, something is wrong. TYPO3 base table names like pages,tt_content,fe_users,fe_groups and so on should also be listed there by default.
Is the page that you are trying to add usergroups to of type "page" or "directory" (see "General"-tab). Probably it must be of kind "directory" or "folder"
Since updating from Flux 6.0.2 to the newest Flux TER-Release (7.0.0) I have the problem that all my defined flux:field.select items are switched. I have them defined as an array like this items="{0: {0: 'value shown as a CSS class in the frontend',1: 'value shown in BE'},}". But now I get the BE value in the frontend template.
Also all my content elements from my provider extension are shown twice (without a title) in the backend and the fields defined in the 'Configuration' section of my content element are shown twice.
There's also a RTE field shown at the bottom of my content element that has not been there before.
BE Output: view
Code on Pastebin: http://pastebin.com/CNcphn2k
Any help deeply appreciated.
EDIT:
I just set up a fresh instance of TYPO3 6.1.9 (blank package) and installed my extension with the above mentioned content elements. Dependencies were resolved automatically as it should (newest versions). Via the content wizard I tried to create a new element and I get the same result as in my existing install I first noticed this bug in.
EDIT2:
I was able to narrow it down to the flux:form.container tag. This duplicates the output in the BE. The select values are still switched though.
It is possible that you missed this official announcement:
http://fluidtypo3.org/blog/news/new-colpos-value.html
Failure to run the update script before letting TYPO3 change the type of the colPos value will result in the symptoms you describe. There is, unfortunately, no way to restore this (since your SQL will have cropped off all negative values and made them zero without any backup).
Restore from a backup and run the script and you should be fine.