Drupal 7 to Drupal 8 migration. I've migrated terms in the source language, but I'm unable to migrate term's translations (i18n) - name and description.
I've created a custom source plugin, where I create new fields with translations for taxonomy name and description.
So how to migrate term translations? D6 example doesn't work.
Thank you.
You could perform these steps after a full migration of your taxonomy (without translation):
Install the language - https://www.drupal.org/docs/8/multilingual/install-a-language
Create a module for migration (example for node): https://github.com/evolvingweb/migrate_example_i18n
Write a Migration Source Plugin (example for node): https://github.com/evolvingweb/migrate_example_i18n/blob/8.x/src/Plugin/migrate/source/D7NodeEntityTranslation.php
Write YUML file with "mapping" (example for node): https://github.com/evolvingweb/migrate_example_i18n/blob/8.x/config/install/migrate_plus.migration.example_dog_i18n.yml
At a command-line prompt, in the project folder, execute the following: drush mim module_name
My yuml snippet of process term without trans:
# to_db_value : from_db_value.
# d8_db_value : d7_db_value
tid: tid
vid:
plugin: migration_lookup
migration: your_vocabulary_migration
source: vid
langcode:
plugin: default_value
default_value: en // your und lng
my i18n trans yuml snipped:
source:
plugin: taxonomy_terms_i18n // custom source plugin to get translations
translations: true
destination:
plugin: entity:taxonomy_term
translations: true
process:
# to_db_value : from_db_value.
# d8_db_value : d7_db_value
tid:
plugin: migration_lookup
migration: // name of your previous migration of terms
source: tid
langcode:
plugin: default_value
default_value: es
vid:
plugin: skip_on_value
source: machine_name
method: row
value:
- // terms vid that you don't need
name:
plugin: skip_on_empty
method: row
source: translation
source file snipped of query for i18n translate:
$query = $this->select('taxonomy_term_data', 'term_data');
$query->join('taxonomy_vocabulary','vocabulary', 'term_data.vid = vocabulary.vid');
$query->leftJoin('i18n_string','i18n', 'term_data.tid = i18n.objectid');
$query->leftJoin('locales_target','locales', 'i18n.lid = locales.lid');
$query
->fields('term_data', [
'tid',
'vid',
'name',
'description',
'weight',
'format',
])
->fields('vocabulary', ['machine_name'])
->fields('locales', ['translation']);
More info:
https://events.drupal.org/sites/default/files/slides/Migrating%20Multilingual%20Content%20to%20Drupal%208.pdf
You can import Taxonomies, Nodes, Users, Products, Custom Blocks, Paragraphs, Custom Menu Links with FEEDS MODULE.
For importing field's multiple values you also need module called
FEEDS TAMPER.
Related
I just started playing around with strapi using it for my next project with nextjs and i got stuck a little bit on the slug part.
I have installed the slugify plugin in the strapi admin panel, restarted the server and in the roles(permissions) section i enabled it for both authenticated and public roles.After this i created a collection type name Blog. I added some fields to it title, content, cover, slug(short text).
After this i created some blog posts and listed them out on the page. The problem began when i tried to access the blog post using the slug:
`${process.env.NEXT_PUBLIC_STRAPI_URL}/slugify/slugs/blog/${slug}?populate=*`,
The url is ok as the slug part is populated and is the value that i have given the slug field when created the blog post. The error that i get is the following:
blog model name not found, all models must be defined in the settings and are case sensitive.
The problem is that the slugify plugin is trying to match the model name to the existing ones and its not finding it so throws this error.
I started to dig a little bit deeper and began to console log in the slugify plugin inside strapi node_module:
module.exports = ({ strapi }) => ({
async findSlug(ctx) {
const { models } = getPluginService(strapi, 'settingsService').get();
const { modelName, slug } = ctx.request.params;
const { auth } = ctx.state;
console.log(getPluginService(strapi, 'settingsService').get());
isValidFindSlugParams({
modelName,
slug,
models,
});
As you can see it should container a models param aswell that should contain all the current models created in strapi. However the model paramateres comes back as an empty object, its like the plugin does not see the created collections.
The collections were created after the instalation of the slugify plugin.
I am developing on localhost using sqlite with strapi v4.
Any ideas why is this happening? Anyone else encountered this error?
Thanks,
Trix
Firstly, you have to install Slugify plugin.
After that you have to do some config steps.
To do all of that:
As you mentioned, you found Slugify folder in node_modules so you can skip first step:
npm install strapi-plugin-slugify
in the ./config/ folder create a file named plugins.js
./config/plugins.js
Paste this code there it will let you see the endpoint path in the right side of the screen:
module.exports = ({ env }) => ({
// ...
slugify: {
enabled: true,
config: {
contentTypes: {
blog: { //write what your collection type's name is this case we should use "blog"
field: "slug",
references: "title",
},
},
},
},
// ...
});
The endpoint example
fetcher(`${API}/slugify/slugs/blog/${slug}`)
I'm migrating a bundle, that add a link button on the product page, from akeneo 2.3 to akeneo 3.2. With 2.3 we have a parameter defined on parameters.yml as
#CUSTOM
magento_base_url: http://mymagento.com/
then in the form_extensions
extensions:
pim-product-edit-form-magento-link-frontend:
module: pim/product-edit-form/magento-link
parent: pim-product-edit-form
targetZone: buttons
position: 90
magentoBaseUrl: "%magento_base_url%" <-- MY CUSTOM ATTR
type: frontend
then in js i will have
define(
[
'underscore',
'oro/translator',
'pim/form',
'pim/template/product/magento-link'
],
function (_,
__,
BaseForm,
template) {
return BaseForm.extend({
template: _.template(template),
render: function () {
let linkPath,
linkLabel,
sku = this.getFormModel().get('identifier'),
baseUrl = this.options.magentoBaseUrl; <-- THIS
where baseUrl contains http://mymagento.com/
After upgrading to 3.2 the value on baseUrl is exactly %magento_base_url%
What i should do to pass this parameter to the js stack?
Seems that from version 3.2 akeneo use a node engine to parse form_extensions yaml and you can't access anymore these parameteres. As workaround i wrote a controller and retrieve the value via ajax
I'm trying to add custom domain into the project.
I have regions.locale.yaml file.
I'm trying load it in twig:
{{'united.kingdom'|trans|raw}}
But this doesn't work.
I think it has to be somehow declared that this file exists.
I found this in documentation:
// ...
$translator->addLoader('xlf', new XliffFileLoader());
$translator->addResource('xlf', 'messages.fr.xlf', 'fr_FR');
$translator->addResource('xlf', 'admin.fr.xlf', 'fr_FR', 'admin');
$translator->addResource(
'xlf',
'navigation.fr.xlf',
'fr_FR',
'navigation'
);
But where should I put this to declare my regions.locale.yaml files globally?
Thanks
If you are using Symfony Standard, you don't have to declare your translation files, you just put them in app/Resources/translations.
The key is that when you want to translate using your custom domain, you just specify your domain, like this :
{{'united.kingdom'|trans({}, 'regions')|raw }}
or somewhere else in your code :
$translator->trans('united.kingdom', [], 'regions');
I want to use some of the builtin symfony2 extensions(e.g:humanize,yaml_dump) for twig for a website not developed in symfony but using a twig engine.how can I do that?
The symfony/twig-bridge package provides the symfony-specific twig extensions.
These include i.e. the YamlExtension that provides the yaml_dump filter and the FormExtension that provides the humanize filter.
The extensions can be found in the Extension folder.
I strongly advise you to install the package via composer to get the package's dependencies automatically.
composer require symfony/twig-bridge:~2.3
Further composer will automatically register the classes in the autoloader (vendor/autoload.php) for you.
Now you just need to add the extensions to twig as described in the documentation.
$twig->addExtension(new \Symfony\Bridge\Twig\Extension\YamlExtension());
// ...
A complete example, with an extension class and a quick extension (a new filter) :
<?php
require_once("vendor/autoload.php");
$loader = new Twig_Loader_String();
$twig = new Twig_Environment($loader);
// here we add the extension class (taken from #nifr answer)
$twig->addExtension(new \Symfony\Bridge\Twig\Extension\YamlExtension());
// here we add a new filter quickly
$filter = new Twig_SimpleFilter('paragraph', function ($argument) {
return "<p>{$argument}</p>";
}, array('pre_escape' => 'html', 'is_safe' => array('html')));
$twig->addFilter($filter);
// demo
echo $twig->render('{{ "hello" | paragraph }}');
I use silverstripe 3.1
I would like to limit the languages (To only German and English) which are available in the drop down in the CMS. Therefore I put
the following code in my mysite/_config.php
i18n::set_locale('de_DE');
$allowed_locales = array(
'de_DE' => array('Deutsch', 'Deutsch'),
'en_EN' => array('English', 'English')
);
i18n::$common_locales = $allowed_locales;
Afer a flush=1 i get the following error:
Fatal error: Cannot access private property i18n::$common_locales in ... _config.php
Any ideas what goes wrong?
Thank you
as of 3.1 most of the static php variables are private. this means you can no longer access those.
the reason for this api change is that they are now cached by the config layer (this is also why you have to ?flush=1 now after changing private statics in classes like for example with private static $db)
if you want to update something in the config layer, you can do this with:
Config::inst()->update('CLASS', 'FIELD', $value);
you could use use the config update to overwrite the common locales (class would be 'i18n', and field would be 'common_locales'):
Config::inst()->update('i18n', 'common_locales', $array);
Note: if you want to completely overwrite an existing configuration, you have to do a remove() first.
Config::inst()->remove('i18n', 'common_locales');
Config::inst()->update('i18n', 'common_locales', $array);
however, if you are using the translatable module and you want to limit the number of translatable languages, there is a much better way already built in:
// in your _config.php
i18n::set_locale('en_US');
Translatable::set_allowed_locales(array(
'de_DE',
'en_US',
));
Config it through YAML:
i18n:
common_locales:
nl_BE:
name: Dutch (Belgium)
native: Nederlands
fr_BE:
name: French (Belgium)
native: Francais