I'm in the process of migrating a TYPO3 7 LTS latest site from ext:tt_news to ext:news.
The data migration is working flawless. But when I'm running ttnewspluginmigrate:run, all new plugins are textmedia content elements (should be news content elements).
What I tried solving this issue:
Updated tt_news to latest version on TER
Used dev:master of news_ttnewsimport
Used dev:master of news
Used ^5.0 for news
The site is heavily reliant on tt_news plugins, so manually replacing them would rather be unpleasant.
Data migration working, plugin migration failing
Additional Information:
Template uses fsc, csc extension disabled
The migration is not that complicated to debug and I wonder why that could happen. See https://github.com/ext-news/news_ttnewsimport/blob/master/Classes/Service/Migrate/TtNewsPluginMigrate.php#L84-L85
Can you check the database what is wrong with the new elements? The field CType should be list and the field list_type should be news_pi1.
Can confirm exactly the same problem. Same conditions – 7 LTS, fsc, no csc. So I tried to investigate. UPDATE query for this textmedia record was generated, but without any effect.
Then i tried it manually and i got following error: "Unknown column 'header_position' in 'field list'". So it is obvious – tt_content table with FSC (Fluid Styled Content) used instead of CSC, doesn't contain "header_position" field. The same goes also for fields "spaceBefore", "spaceAfter" and "section_frame". So these fields should be excluded from "$fieldToCopy" in case of using FSC.
Related
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.
Every time I click on any page in the backend I get 6 DB Errors, that look very similar to this one, in total 3 different SELECT errors for the table lawyer and 3 for the table student:
caller TYPO3\CMS\Core\Database\DatabaseConnection::exec_SELECTquery
ERROR Table 'db_lawclinic47.tx_lcapp_domain_model_lawyer' doesn't exist
lastBuiltQuery SELECT uid FROM tx_lcapp_domain_model_lawyer
WHERE pid=24 AND tx_lcapp_domain_model_lawyer.deleted=0
AND (tx_lcapp_domain_model_lawyer.t3ver_state <= 0 OR
tx_lcapp_domain_model_lawyer.t3ver_wsid = 0) LIMIT 1
debug_backtrace require(25/typo3/sysext/recordlist/mod1/index.php),25/typo3/mod.php#32 //
TYPO3\CMS\Recordlist\RecordList->main#31 //
TYPO3\CMS\Recordlist\RecordList\AbstractDatabaseRecordList->generateList#332 //
TYPO3\CMS\Core\Database\DatabaseConnection->exec_SELECTgetSingleRow#410 //
TYPO3\CMS\Core\Database\DatabaseConnection->exec_SELECTquery#406 //
TYPO3\CMS\Core\Database\DatabaseConnection->debug#305
Those tables really don't exist because I renamed some and deleted some...and my webpage is working fine, so somehow those new tables are used, but there seems to be something old that is trying to select from the old tables and I have no idea what it could be and how to find it and get rid of it. Any clues?
You have an extension installed (probably with key lcapp) that requires these tables. If you don't need that functionality any longer, you should uninstall that extension in the Extension Manager.
Also, if the database was manipulated by some other tool than TYPO3 itself, you should check the database structure in the Install Tool. It can tell you about missing tables, fields that are not as specified and so on.
The database definitions for an extension are stored in the file ext_tables.sql in root of the extensions install directory, the Install Tool compares against these definitions.
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.
Is it possible to make formhandler records editable and even show and sort by
- lets say - name and lastname in TYPO3 BE?
Thanks in advance.
I lately made a dummy extbase extension for a customer. Formhandler stores its data in these tables. Thus they are accessible as usual in the backend. They are sortable and editable and anything you like.
Have a look at http://typo3blogger.de/newsletteranmeldung-mit-formhandler-turchen-14/ There I have created an example how to create records in TYPO3 with formhandler and Finisher_DB. In newer versions please use Finisher\DB
Here are all properties of the Finisher\DB of formhandler:
http://www.typo3-formhandler.com/documentation/finisher/finisherdb/
Use ifIsEmpty to fill up fields with a default value. F.e. if you don't have this field in your form.
at http://pi-phi.de/formhandler.html I documented (in german) how I used formhandler to generate tt_news records with categories.
the tt_news records needs a confirmation of an admin, so the admin gets a mail
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';