Szenario:
I have two extensions, which extend ext:news with some specific fields. Up to TYPO3 9 I had to configure the dependency to the news extension with the following TypoScript configuration:
config.tx_extbase {
persistence {
classes {
GeorgRinger\News\Domain\Model\News {
subclasses {
GeorgRinger\News\Domain\Model\News = Vendor\Extension\Domain\Model\News
}
}
Vendor\Extension\Domain\Model\News {
mapping {
tableName = tx_news_domain_model_news
}
}
}
}
}
The model Vendor\Extension\Domain\Model\News extends the model of the "base" extension:
class News extends \GeorgRinger\News\Domain\Model\News
In TYPO3 10 the TypoScript configuration was replaced with the following configuration in Configuration/Extbase/Persistence/Classes.php (Breaking: #87623):
\Vendor\Extension\Domain\Model\News::class => [
'tableName' => 'tx_news_domain_model_news',
'recordType' => 0,
],
This works as long, as you have just one extension which extends the news extension. If you have a second extension and enable the TYPO3 cache you will get an error, that the fields which are added in the first extension are not available in the templates of the news extension. The strange part is, that this problem only occurs, when enabling the cache!
So my question is:
What is the right way to add some fields to an existing extension in TYPO3 10?
As the changelog says, in TYPO3 versions below 10, your overriding configuration was located in typoscript. Since 10 LTS, it is located in a PHP class. As a consequence, the mechanism which controls loading order is no more the one for typoscript but the one for PHP.
Authoritative for the PHP loading order is the constraints section in the ext_emconf.php files of your extensions. They are parsed at first run and cached afterwards. The composer.json files do not control loading order - currently they only serve the purpose of resolving dependencies in composer itself.
In contrast to composer.json, the ext_emconf.php allows you to specify not only hard but also "soft" dependencies, which you can set using the suggests keyword. This way, you can specify loading order between extensions without them having to be installed in any case. This allows you to install each extension independently from the other, while you can still specify correct loading order in case they are both installed.
So, in your case, the second extension needs to have a soft "suggests" dependency to the first one:
constraints' => [
'depends' => [
],
'conflicts' => [
],
'suggests' => [
'news' => ''
'first_news_extension' => ''
],
]
See the complete explanation of constraints in ext_emconf here.
Related
When using webpack and babel together, one needs to configure both in order to use React CSS Modules. For example:
webpack.config.js will need a rule like this:
{
// Translates CSS into CommonJS modules
loader: 'css-loader',
options: {
modules: {
mode: "local",
localIdentName: CSS_CLASS_NAME_PATTERN,
},
sourceMap: true
}
babel.config.js will need a plugin like this:
[
'react-css-modules',
{
generateScopedName: CSS_CLASS_NAME_PATTERN,
filetypes: {
'.scss': {
syntax: 'postcss-scss',
plugins: ['postcss-nested']
}
},
}
]
Why the need to configure CSS Modules in two places? How the two work together? I.e. what happens in what order?
They don't. css-loader does its own thing: class name transformation in CSS, and replacement of CSS imports in JS code by mappings between original and generated names.
babel-plugin-react-css-modules works independently, and it replaces styleName attributes of react components by className with correct generated names. To do so it calculates class name mappings independently from css-loader, that's why it needs separate configuration matching that of css-loader, and that's why after a few years being abandoned by its creators it has compatibility issues with latest css-loader (css-loader changed internal class name generation logic).
Shameless self-promo: I maintain an up-to-date fork of babel-plugin-react-css-modules which solves compatibility issues with latest css-loader versions.
I'm a newbie in typo3. A friend of me asked, if I can upgrade his installation for him, because I'm a developer. So I checked if I can do it.
I did several steps to upgrade the installation from 7.6.9 to 8.7.3. Now I ended in the installation tool in the section important actions. There is a point TCA migrations.
There it says:
TCA migrations need to be applied Check the following list and apply
needed changes.
The icon path of wizard "link" from TCA table
"tx_myredirects_domain_model_redirect['columns']['destination']['config']['wizards']['link']['icon']"has
been migrated to
tx_myredirects_domain_model_redirect['columns']['destination']['config']['wizards']['link']['icon']"
= 'actions-wizard-link'. ...
Is this just informational or do I have to modify something in the things listed?
Sorry again, if this is a newbie question, but I am actually a newbie in typo3.
If the extensions that need to migrate the TCAs haven't been created by you, then no, you do not really need to change them. The author of the extension should do it, because if you change them and then the author releases an update, then all your changes will be lost.
If the extension is a custom extension, then it would be better to migrate them. Then you can avoid bugs and unwanted disfunctions.
If you have a sitepackage, you can override the TCA's and give them new definitions. This way, if the author releases an update, your TCAs won't be lost. In order to do that, you can follow these instructions:
Extending TCAs
An example would be:
your_sitepackage/Configuration/TCA/Overrides/tx_tablename_domain_model_modelname
$GLOBALS['TCA']['tx_tablename_domain_model_modelname']['columns']['columnYouNeedToChange'] = [
'label' => 'input_29 link',
'config' => [
'type' => 'input',
'wizards' => [
'link' => [
'type' => 'popup',
'title' => 'LLL:EXT:frontend/Resources/Private/Language/locallang_ttc.xlf:header_link_formlabel',
'icon' => 'actions-wizard-link',
'module' => [
'name' => 'wizard_link',
],
'JSopenParams' => 'height=800,width=600,status=0,menubar=0,scrollbars=1',
'params' => [
'blindLinkOptions' => 'folder',
'blindLinkFields' => 'class, target',
'allowedExtensions' => 'jpg',
],
],
],
]
This for example would solve the first problem of the image you shared. You just need to replace the table name. (That's TYPO3v8. TYPO3 v9 has more changes when it comes to TCAs)
If you are not sure how the path to the column look like ($GLOBALS['TCA']['tx_tablename_domain_model_modelname']['columns']['columnYouNeedToChange']) then follow this:
TCA Paths
#Thomas Löffler is right. It would be very useful to create an issue on GitHub and let the author know that some changes need to be made.
Best regards
This will show which TCA fields have been identified to have a legacy format and have been transformed while loading the configuration files.
While it is good practice to do these changes and keep this clean, strictly speaking it is not required.
Tip: I would rather look there before an upgrade because deprecated stuff might still have an upgrade path in an older version but none in the newest.
Currently I'm trying to create a module group in the typo3 backend module list on the left hand side. My group works fine for modules within the same extension. But when I try to add modules from other extensions to it, it simply doesn't work.
I have created this Module group (mainmodule) in the ext_tables.php file in one of my other extensions like this:
/**
* Creates a Backend Module Category
*/
$GLOBALS['TBE_MODULES'] = array_slice($GLOBALS['TBE_MODULES'], 0, 1, true) +
['mainmodule' => ''] +
array_slice($GLOBALS['TBE_MODULES'], 1, count($GLOBALS['TBE_MODULES']) - 1, true);
$GLOBALS['TBE_MODULES']['_configuration']['mainmodule'] = [
'iconIdentifier' => 'module',
'labels' => 'LLL:EXT:' . $_EXTKEY . '/Resources/Private/Language/locallang_myExt.xlf:mlang_key',
'name' => 'mainmodule',
];
I'm trying to use the mainmodule in a different extension as follows:
\TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerModule(
'VEN.' . $extKey,
'mainmodule', // Make module a submodule of 'mainmodule'
'randomkey', // Submodule key
'',
...
The module is always created inside its "own" mainmodule.
I have tried all of the solutions given here on stackoverflow and spent hours of trying to solve this issue. I just can't get it to work..
It seems other extensions are loaded before this extensions which defines the new backend module category. So \TYPO3\CMS\Extbase\Utility\ExtensionUtility::registerModule will fail because of the missing category. To check this have a look at the loading order of the extensions in typo3conf/PackageStates.php.
To resolve the issue, add this extension to the constraint in ext_em.conf and require in composer.json to force it's loaded before the other extensions with the dependency to the new backend module category. See https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ExtensionArchitecture/DeclarationFile/Index.html and https://docs.typo3.org/m/typo3/reference-coreapi/master/en-us/ExtensionArchitecture/ComposerJson/Index.html.
Other solution could be adding the new category in each extension if it does not already exist.
I'm using gedmo/doctrine-translations and a2lix/translation-form-bundle: 2.*#dev to translate my entities.
The translation form always renders a Field and Content but my entity itself doesn't contain a Field or Content field.
The form type
$builder->add('translations', 'a2lix_translations');
The 2.0 version of the TranslationFormBundle
isn't compatible with the current gedmo/doctrine-extensions version.
See the bundle's upgrade notes.
You'll need to use the currently unstable branches wip-v2.4.0 and .
solution:
Either update gedmo/doctrine-extensions ...
composer require gedmo/doctrine-extensions:wip-v2.4.0#dev
composer update gedmo/doctrine-extensions
... or downgrade your a2lix/translation-form-bundle version:
composer require a2lix/translation-form-bundle:~1.2
composer update a2lix/translation-form-bundle
important notice for the 1.x version of a2lix/TranslationFormBundle:
You need to use the a2lix_translations_gedmo field-type as described in the documentation.
Further you need to specify the translatable class in the options-array like this:
$builder->add('translations', 'a2lix_translations_gedmo', array(
'translatable_class' => "Your\Entity"
);
I'm developing a new extension using ExtBase in TYPO3 (4.7) for a client.
I have however the strangest problem. In the back-end, my possible, new record types are - as usual - listed in the Insert new record Backend List. Usually each of these record-types are preceded by the module name (actually they are grouped right after the module name).. However, in my case, 1 or 2 of the record-types of any other extension appear within my extension's list as well.. I've been trying to figure out pretty much all that I can, I even copied the extension over to an entirely different TYPO3 installation, but the same problem persists..
If of any extension some records appear just below my extension's title, and I delete that particular extension, just some other record-types appear of another extension.
What's going on here??
Short & late answer:
i guess you have defined the title of your models in two different ways or with a non-existent languagefile in your ext_tables.php. Something like this:
Model1:
$TCA['tx_aaext_domain_model_one'] = array(
'ctrl' => array(
'title' => 'LLL:EXT:bn_news/Resources/Private/Language/locallang_db.xml:tx_bnnews_domain_model_categories',
Model2:
$TCA['tx_aaext_domain_model_two'] = array(
'ctrl' => array(
'title' => 'Static Title',
and/or your extension-name has an underscore like aa_extension, then this error can happen.
Make sure that both title-definitions are dynamic and begin with "LLL:EXT:" and point to an existing translation. Everything should be fine now.
Long answer will be to long :)