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';
Related
We have changed the primary language for our site https://staging.venicexplorer.net from English to Italian. But the problem is it is showing English text when we selected Italian and vice versa. We are now altering the languages of the content. But this is a very time consuming job. Can anyone please tell me whether there is any shortcut method?
Thanks
Prasun
Here are some hints for updating the language of content and pages in the database:
Content
The language of a content element (table tt_content) is in the field sys_language_uid. Default language is always 0, "all languages" is -1.
Each translated record (sys_language_uid NOT IN (0,1)) can (aka "connected mode") have a link to its default language counterpart. This is set in the field l10n_parent.
Pages
First of all for TYPO3v9 this depends on the feature toggle unifiedPageTranslationHandling. I will assume that your instance is already fully migrated to not use pages_language_overlay any more.
The same rules as for tt_content apply: sys_language_uid is the language, l10n_parent the default language record.
Other records
The same applies to all other translated records in TYPO3 or its extensions.
Technically, these fields are defined for each table in TCA in [ctrl][languageField] and [ctrl][transOrigPointerField] but sys_language_uid and l10n_parent are used mostly.
Notice
This is not an exhaustive list. There are fields that are only set in the default language (e.g. access restrictions). Make a backup first! But that should cover most bases.
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 need to get a list of elements linking to a specific TYPO3 page or element (all IDs oder pages, that link or refer to a this element). I thought this was at the Info module, but I can't find it.
I have spent hours finding this info on the web and even in my oldschool TYPO3 manual book... nothing, but I know that I once had this list.
Thanks a lot in advance! (version is TYPO3 4.6, I am preparing an upgrade right now)
You could search your database manually to find such links. I will start to give you a list where you could search for.
Find tt_content headers which link to a page, element or any url:
SELECT * FROM tt_content WHERE header_link NOT LIKE '' AND deleted = 0;
In RTE fields, you could manually check.
Go to backend modul 'Configuration', choose '$TCA (Tabel configuration array)' and search for 'RTE'.
Then you schould get all RTE fields, which could have links set to any TYPO3 pages or elements.
Like fx: tt_content.bodytext.config.wizards.RTE...
These fields you could search for any links vis MySQL
SELECT * FROM tt_content WHERE bodytext LIKE '%<link%' OR bodytext LIKE '%<LINK%' AND deleted = 0;
Maybe someone can add more default fields not listed above.
I think you have seen the references of a record normaly seen in the list module.
If you hover your mouse over the count you get a list of origins.
That list is not always up to date and the usability of the origins differs from version to version. Sometimes you can use the origins as direct link to edit the origin record.
Maybe you had an extension which enhances the usage.
In gerneral: if records are used with TYPO3 (TCA group fields which build relations to other records with uid-lists, or mm-records) this is also stored as refrence.
As links are also relations they are not always stored as referenes, espeacially if the link is inside a textfield.
I'm working on a project based on Laravel 5.3 and Backpack CRUD. My project has about 8 different content types (news, page, portfolio, events, team, video, gallery, jobs).
I need to be able to add tags to every content type (n-n), and every content type has its own specific tags, so tags are NOT shared between the content types.
If I want to use the select_multiple or select2_multiple field type, I would need 8 tables for the content itself, 8 pivot tables, and 8 tables for the tags(!).
Obviously I would like to have just one table for the tags, but if I use the select_multiple or select2_multiple field type, I get all tags in the edit-form of every content type.
So, my question is: Is there an elegant way to filter the results of the select_multiple or select2_multiple field type?
I have created a simple schema with two content types:
http://dbdesigner.net/designer/schema/60412
In this example I want to be able to filter the tag list on content_type_id, when I'm editing the content of news or page. So I just want to see the news tags in the news-edit form, and just the page tags, in the page-edit form.
Or maybe I should just use the select_multiple field type as intended, and accept the 8 tag tables(?)
Any help or advice would be greatly appreciated.
I think a clean way would be to:
create different models for each tag use, so NewsTag, PageTag, PortfolioTag etc. that would only extend the Tag model and use a global scope to filter the results after content_type_id;
use backpack select2_multiple fields with NewsTag, PageTag, PortfolioTag etc; anything you set on the Tag model will be used (including the table attribute, mutators, accessors, etc);
Cheers!
I have some messed up values for tt_content.sorting in TYPO3 6.2 for translated records (sys_language_uid=1).
That means that styles.content.get displays the right order (as visible in the backend) in the original language, but not in the translated language (where in the backend everything looks fine, as it follows defLangBinding but in the frontend, the wrong values from the sorting fields are used, so the sorting is messed up.
We did modify some settings in the last few weeks
// before
// config.sys_language_mode = content_fallback:1,0
// config.sys_language_overlay = hideNonTranslated
// currently
config.sys_language_mode = strict
config.sys_language_overlay =0
but I am unsure if that is connected. The sorting in the DB is really wrong for some fields. It is correctable by moving individual CEs in Page or List module.
There are many related ancient bugs on forge.
My questions:
Is there a script that fixes the sorting for the translated CEs for the entire site in accordance to the main language?
Is there something like defLangBinding for the frontend - that would help as well, as the wrong sorting values would become meaningless. Or a modification for the styles.content.get query?
Why don't you just try to bring your content records in sync again? This could be done by pure SQL if there are no or only a few exclusive records in the second language. If not, you are going to mess it up even more.
This query will give you a table with the default language and the translated record side by side, including the sorting value:
select a.header, a.uid, a.sorting, b.sorting, b.uid, b.header from tt_content as a inner join tt_content as b on a.uid=b.l18n_parent where b.l18n_parent > 0 and a.sys_language_uid = 0 and not a.deleted and not b.deleted;
You could then adapt this query to an update query that sets the sorting value of table b to the one in table a.
To check if you have records without a parent in the default language, you can use this query:
select * from tt_content where sys_language_uid > 0 AND l18n_parent = 0 AND NOT deleted
As for your configuration, have a look at the manual for sys_language_overlay:
If set, records from certain tables selected by the CONTENT cObject
using the “languageField” setting will select the default language (0)
instead of any language set by sys_language_uid / sys_language_mode.
In addition the system will look for a translation of the selected
record and overlay configured fields.
So this seems to be connected to your problem: Before, TYPO3 was (maybe - you didn't post the setting for sys_language_overlay) configured to first fetch records in the default language, try to overlay them with a translation and then output it.
Now that sys_language_overlay is deactivated, the records are fetched in the translated version right away and their sorting is considered.