TYPO3 9.5.15 with gridelements and t3sbootstrap not working - typo3

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.

Related

TYPO3 11 Sitepackage Tutorial expected template file Standard/1.html

TL;DR:
The Backend Layouts of the site package tutorial (Default/Standard and Two Columns) do not show up for new pages in Appearance -> Backend Layout. The error message in this thread (1.html) is an artefact of prior Backend Layouts which came from the original old site setup.
Solution:
To make the Backend Layouts of the site package tutorial show up there, I had to edit the root page of the site: Resources -> Include static Page TSconfig (from extensions) and add site-package from the Available Items list.
This can also be achieved without "Resources -> Include static Page TSconfig (from extensions)" but via file ext_localconf.php in the root of the site package extension (gpcf_theme):
<?php
defined('TYPO3_MODE') || die();
$boot = function (string $_EXTKEY): void {
\TYPO3\CMS\Core\Utility\ExtensionManagementUtility::addPageTSConfig('
<INCLUDE_TYPOSCRIPT: source="FILE:EXT:'.$_EXTKEY.'/Configuration/TsConfig/Page/Page.tsconfig">
');
};
$boot('gpcf_theme');
unset($boot);
Original Question:
I'm still trying to bring an existing (older) web page into Typo3 11 following the TYPO3 Sitepackage Tutorial.
Currently I get an
"Oops, an error occurred! Code: 202111161210589c32f8c0"
and can't get rid of it whatever I do.
The corresponding entry in the log files is (line breaks added by me):
../../var/log/typo3_61306f633c.log:Tue, 16 Nov 2021 12:10:58 +0000 [ALERT] request="30cc4e082c853"
component="TYPO3.CMS.Frontend.ContentObject.Exception.ProductionExceptionHandler":
Oops, an error occurred! Code: 202111161210589c32f8c0- InvalidTemplateResourceException:
Tried resolving a template file for controller action "Standard->1" in format ".html",
but none of the paths contained the expected template file (Standard/1.html).
The following paths were checked:
/var/www/html/typo3_11/public/typo3conf/ext/gpcf_theme/Resources/Private/Templates/Page/,
in file /var/www/html/typo3_11/vendor/typo3fluid/fluid/src/View/TemplatePaths.php
I can't find the reason of this error, because I have no idea, where the needed template Standard/1.html is requested from.
Is this some kind of hard coded default if nothing else is found?
If this is the case, the real problem is, that my customizations to the Sitepackage Tutorial source code seems to be wrong, but it never produced any different error despite the above one, which isn't really helpful. Ok, this is speculation, because I don't know.
As you can see, the site package was renamed to gpcf_theme, it's available in the backend and applied as root template to the site. No other template is active (AFAIK). A simple newly created test page creates above error.
If I uncomment in Configuration/TypoScript/Setup/Page.typoscript the lines so that:
page = PAGE
page {
typeNum = 0
10 = TEXT
10.value = Hello World!
}
same error, no hello world.
Any idea how to locate the reason for my misery?
Maybe the fix is really simple. Try to go into the backend:
Edit the homepage
To to the "Appearance" tab
Set the Backend Layout for this and subpages
Save your change
There is a good chance that it is working now.
Whats going on?
You can cast this query on your database:
SELECT
uid, pid, title, backend_layout, backend_layout_next_level
FROM
pages;
Here you get a list of pages, some with backend_layout and backend_layout_next_level filled. Most likely your home pages has some values in this fields?
The value of this field is generated by the TSConfig for backend layouts you set in:
https://docs.typo3.org/m/typo3/tutorial-sitepackage/11.5/en-us/ContentMapping/Index.html#dynamic-content-rendering-in-typoscript
This column is then read and processed in your TypoScript:
https://docs.typo3.org/m/typo3/tutorial-sitepackage/11.5/en-us/TypoScriptConfiguration/Index.html#part-1-fluid-template-section
It is explained below the code snippet.
If the 4 steps from the beginning of my answer did not solve your problem, then this are the places to look.
In TSConfig is the definition of the backend layouts, columns, labels and what is written in the pages.backend_layout db-field
DB columns if the value makes sense pagets__<yourTemplateName>
The TypoScript that reads this db-field cuts of the pagets__ takes the rest, adds .html and searches in the paths defined in the TypoScript below.
check if the Folder and Filename of your Template file are correct.
the error message states that the file 1.html is expected in the folder /var/www/html/typo3_11/public/typo3conf/ext/gpcf_theme/Resources/Private/Templates/Page/
as you noted that you have renamed the site package you may have missed some occurrences of the original package name and so some configuration is missing or pointing to nirvana.

TYPO3 - Gridelements and nested flux content elements not visible in backend

Extension versions:
Flux: Fluid Integration - 9.3.2
Gridelements - 8.6.3
During an upgrade from 6.2 to 8.7.32, a website uses gridelements extension and Flux. We have some gridcontainers created with the gridelements extension and flux (CE's) nested inside these. Now the content elements are created but they don't get set properly inside the gridelement containers. Unless I create the flux elements outside the gridelement and then drag in inside.
In the database I can see that the fields are not properly assigned when created inside the gridelement:
Don't mind the typo, "Created outside parent container"
So that element with 0|0 on tx_gridelements_container and tx_gridelements_columns respectivly is not displayed in the backend and only visible in the list mode.
Now, this is strange because I checked the data types on the database and it seems alright. I had other similar pages that I've upgraded as well and no one had this issue after migrating to 8.7.32, since this issue only occurred in 6.2.x versions.
The allowed elements are set to all, as well as in the other TYPO3 where this issue is not occurring. Does anyone know what could I try to fix this? I'm running out of options and I couldn't find much at TYPO3 Slack, stack overflow and similars.
Are the necessary fields displayed in the editing form of those Flux elements?
To make Gridelements and their children work properly, you will need the Gridelements backend-layout, container and column fields defined for those elements. Otherwise they will get their default values, which is 0 in case of Gridelements.

After updating from typo3 7 to typo3 8 several invalid values in page contents

I updated a typo3 site from version 6 to version 7 and now to version 8 heading for 9 or 10. Now some contents on my page are missing. When I look in the page editor all elements have errors like [INVALID VALUE ('ce_head-image')] or [INVALID VALUE ('ce_product')]. What does this mean?
Your content elements (CEs) have no rendering definition.
the rendering definition can be missing because of:
the basic rendering extension is missing
EXT:CSC leaves the core and is an TER extension
the names of the CEs is changed inside the basic rendering extension (there should be an upgrade wizard)
the same for CE types defined by additional extensions
extension is no longer supported for the newer TYPO3 version
changed names in newer versions (upgrade wizard?)
the registering of additional CEs does not work any longer as it has been changed in the core
As the names you have sounds unfamiliar my firsst guess would be the last reason.

Manage hierarchy / enforce priority of TS-templates

Well, there is actually another guy with exact the same problem. But until today, they didn't come up with a solution, that's why I'm asking it once again.
My entire TS is included by an extension in TYPO3 7.6.8. This works fine except with indexed_search. The TS inside my resources EXT get overwritten by the indexed_search default TS.
This is the order of the TS inside the Template-Analyzer:
SYS: TYPO3_CONF_VARS:FE:defaultTypoScript
EXT:fluid_styled_content/Configuration/TypoScript/...
... a bunch of other third party extensions ...
EXT:indexed_search/Configuration/TypoScript
EXT:templates_ext/Resources/Private/TypoScript
extbase
fluid
extensionmanager
belog
beuser
felogin
indexed_search
sys_note
realurl
So #7 is the extension which includes all my TS but it gets overwritten by #14. The only way to configure the indexed_search is inside the setup of the page template (which comes after all those above). But I want to avoid that to keep things clean.
Is there a way to prioritize a certain TS so that it doesn't get overwritten?
Open the TypoScript record, switch to the tab "Includes", at the bottom you will find the field Static Template Files from TYPO3 Extensions:. Select the value Include before all static templates if root flag is set.
Try putting the TS from your template extension inside the root page Setup field like this (adjust the path if necessary, your example says Resources/Private/TypoScript?):
<INCLUDE_TYPOSCRIPT: source="FILE:EXT:templates_ext/Configuration/TypoScript/setup.ts">
This should make sure that it is included AFTER all the other includes (I assume you included those via the includes tab?)

TYPO3: Duplicate content elements and fields after Flux 6.0.x update

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.