is it possible to have an alternative TCA-Configuration depeding on the ColPos value?
I was testing the cropVariants for CType Image. I want different cropVariants for several cols in tt_content.
That is not possible by default but you can take a look at https://github.com/sup7even/image_cropper_configuration how you can manipulate the configuration on the fly. The example however still needs to be adopted to fit your needs with the colpos.
Related
I'm using TYPO3 10.4.14
I believe, that I understood the relationship of pages and tt_content. But I have not figured out, how to get the tt_content elements and the order from the table pages.
From tt_content it is easy to get the page, but not from pages to tt_content.
What I finally want to do, is to mark a page (additional column), for display the beginning of the page in an overview.
For that I need the content elements of a page!
Edit:
I want to do t with database query.
One possible way would to use the uid of pages and go to the tt_content and search there for the pid. But this is a long winded way.
How is TYPO3 it doing, when display the pages?
you have multiple ways to render any output (typical HTML):
typoscript
PHP
FLUID
(in the end all is PHP, but regarding what you are programming or configuring)
If you want to render some regular content of the current page you will use the defined typoscript styles.content.get (with modifications), which is a TypoScript CONTENT object. This will do a query to get those tt_content records which belong to the current page in the default (or other) column. This results in a query like SELECT * FROM tt_content WHERE pid = current_page_uid AND column = 0 (and some additional conditions regarding visibility (hidden, starttime, endtime, workspace, ...)
This could be assigned to a FLUID variable or requested by a viewhelper (f:cObject).
If you want to get content from another than the current page you need to do a similar request and use another page uid. Either you build your own CONTENT object and use it like the default content. Or you build an own viewhelper in PHP which you can use in FLUID. You can modify the query by reducing the number of records you consider, you also can modify the rendering regarding which fields will be shown in what HTML markup.
Depending on the package you use it may contain already specialized viewhelper which gets you the content of other pages and/or other columns.
I think you want to build teasers for other pages with the content of that pages.
Consider to use a special field in the pages record which contains a clean summary for the page content. Not each page has relevant or recognizable information in the first paragraph.
It's the same as for search engines: if you provide search engines with a summary, that will be shown at the search results and the searcher can better decide if this page is relevant for him.
I have always used the extension Gridelements for my pages. Now I want to get away from using extensions for FCE. Is there a way with FLUID and Flexforms or similar to implement that as with gridelements?
For example, a bootstrap DIV "row" that contains a two-column element.
You could make a content element which contains 2 rows and which can have IRRE tt_content elements. I think there are enough examples how to make own content elements.
Additional for inline tt_content within tt_content records:
in SQL make a couple extra columns for tt_content 2 for the content and 2 for the foreign key
use a dataprocessor in typoscript to retrieve the IRRE tt_content records
use overrideChildTca in TCA/Overrides/tt_content.php to set the colPos to 99 or so for the inline IRRE record fields (else the content elements will appear double on the page).
set in the backend layout configuration of your main templates a fake column with colPos 99 to avoid TYPO3 9.5 warning that the inline content elements are not in a used column
Not sure if this is the best approach, but it will work. I guess you could also make it multidimensional by having inline in inline elements so you could make x columns. However I would just use Gridelements.
I want to create custom content elements. I know how this works basically. But I asking myself, if there is a way to store the configuration data of this elements in a decent database table?
I only know the way to extend the tt_content table and store my data there. But with a bigger amount of elements and fields the tt_content would be become bigger and bigger too. I would like to prevent this.
And just before you ask: I don't want to use FluidTYPO3. ;) I just would like to do it with basic TYPO3 functionality.
Don‘t know if there is a nicer way, but maybe you can create your elements with no field definition but with IRRE and min:1 and max:1 - but this is not really a nice way.
The better way is to reuse the fields given in tt_content as often as possible and only add more fields if really needed.
Maybe you should have a look on EXT:mask and EXT:mask_export - those two are very powerful tools to create custom content elements (EXT:mask) and export them as an own extension (EXT:mask_export) so there is no need for these two extensions in production but only in development.
As you create a content element you will always need to use the database table tt_content. Of course it makes sense to use relations to custom records, e.g. if you create elements like tabs, accordions, ...
What you can do is to reuse existing columns as there are - as you said - a lot of those. So reuse fields like header, bodytext, image, ... Take a look at /sysext/frontend/Configuration/TCA/tt_content.php. The benefits are
a bit smaller table which is most of the time not really relevant to performance
well designed fields including a label whith translations into all languages
You can also reuse a field and its configuration and override it with overrideChildTca. See https://docs.typo3.org/typo3cms/TCAReference/ColumnsConfig/Properties/InlineOverrideChildTCa.html?highlight=overridechildtca in the docs.
I recommend you to have a look at the typo3 extension mask. You can create custom contents and map existing tt_content fields to your new elements. It makes sense to reuse the header, bodytext, media, image fields because the backend preview will adopt automatically.
I used it recently and it works really nice! Here is some resource to jump in (only german)
If you do not need to have indexes on your new fields it is not a big problem to blow up tt_content with new fields. It does not impact the performance so much.
If you need to have new 1:N relations from your content to some child-record (accordion, team-listing, etc), simply add them as inline elements (IRRE) and add the field to your types-string.
If you need to have a new kind of data, that should be filterable, sortable and so on, you should create a new type of record with its own table structure and use extbase plugins to display that data.
As long as you simply need custom contents, you are fine with extending/remapping tt_content.
You can use hooks for this.
In your ext_localconf.php:
$GLOBALS ['TYPO3_CONF_VARS']['SC_OPTIONS']['t3lib/class.t3lib_tcemain.php']['processDatamapClass'][] = \Namespace\Hooks\Classname::class;
And in Classes/Hooks/Classname:
<?php
namespace Namespace\Hooks;
use TYPO3\CMS\Core\SingletonInterface;
use TYPO3\CMS\Core\DataHandling\DataHandler;
class Classname implements SingletonInterface {
public function processDatamap_beforeStart(&$dataHandler) {
$datamap = &$dataHandler->datamap;
}
}
Here you have to modify the $datamap to your needs.
Documentation is here: https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ApiOverview/Typo3CoreEngine/Database/Index.html
Kind regards
It is explained here https://learn-typo3.com/blog/news-detail/how-to-create-custom-content-elements-on-typo3, however I prefer extending and reusing tt_content fields.
Using flux to create custom content elements for TYPO3, fields that are defined in a flux:form are stored in a flex field as XML by default. By the solution Claus Due pointed out here (Fluidtypo3 Flux - save in table field), they can also be stored as individual columns in tt_content.
Now, when creating page templates and defining template parameters as flux input fields, could those be stored as indiviual columns in the "pages" table?
The obvious approach to do this in the same way as described for content elements, i.e.:
<flux:field.text name="pages.extrafield" label="Content" />
did not work. (I created the field "extrafield" in the pages table using my extension's ext_tables.sql)
The format you used is the correct one, but in order to get the field saved it first must be 1) allowed for the user who saves and 2) shown somewhere in the form; types passthrough and none should also work.
The last requirement is a safeguard added in a recent major version and is there to prevent doing things that normally would be prohibited by access settings or field availability.
I had to import a few posts from one TYPO3 site into another, which lead into some exploring of the DB structure. A specific question arose:
In localised content elements (tt_content entries with sys_language_uid = 1), the fields t3_origuid and l18n_parent are redundantly filled. l18n_parent is required for the backend localisation view to work.
Do they always have the same value? Or is there a use case where the values of the fields can differ?
l10n_parent / l18n_parent
The field configured in TCA as transOrigPointerField (usually l10n_parent or l18n_parent) is used for localization.
It always contains an id of the record in the default language (even if the record was translated from a record in non-default language), see https://docs.typo3.org/typo3cms/TCAReference/singlehtml/#transorigpointerfield
t3_origuid
The field configured in TCA as origUid (usually t3_origuid) is filled when record is copied or translated, and contains an id of the source record, see https://docs.typo3.org/typo3cms/TCAReference/singlehtml/#origuid
The fields will have the same value in some cases (e.g. translating a record from default language), but in other will have different value. E.g. when copying a record on the same page t3_origuid will be different than the l10n_parent.
To allow localization it is required to have transOrigPointerField (l10n_parent). Having origUid (t3_origuid) field is not hard requirement but a good practice as as some additional features may require it to work. Especially in newer versions of TYPO3. For example the Translation Wizard is currently using t3_origuid field.
l10n_source (since TYPO3 8.6)
Since TYPO3 8.6 a new database field l10n_source for tt_content table has been introduced together with a new TCA ctrl configuration translationSource. The translationSource field contains an uid of the record used as a translation source, no matter whether the record was translated in the free or connected mode.
see more in the documentation on l10n_source field
Those fields can have different values.
t3_origuid is a generic field pointing to a record from which the current one was derived in some way. For example by copying or localizing it. Here is some documentation for it.
The field l18n_parent is reserved for localization purposes.
Just as a addition to Jost's post:
To determine which field you should use check the value of:
$TCA['tx_yourtable']['ctrl']['transOrigPointerField']
ie. for tt_content it's:
$TCA['tt_content']['ctrl']['transOrigPointerField'] = 'l18n_parent';