quilx → created an issue.
quilx → created an issue.
- The file development.sevices.yml is referenced with a path instead of its basename which can create confusion
- It is explained that the *services.yml files are loaded by the settings*.php files and it suggest what you have check if the twig configuration is not correctly loaded.
- I've added the section "Other ways to enable Twig debugging". It contains already existing information but that present in a section with an inappropriate name "Enabling Twig debugging via services.yml"
quilx → created an issue.
quilx → created an issue.
Here is my investigation:
- I've installed a fresh Drupal 7 site;
- I've created a simple content type containing an image field;
- I've created 3 instances of the newly created content type;
- I've tried to migrate this site to a Drupal 10 site which had installed all the modules that were necessary for the migration of my production Drupal 7 site.
The same error was generated again. The cause of the error was the module Media Migration 8.x-1.0-alpha16 (probably some bug in the alpha version).
Uninstalling this module solves the problem and the migration works: the newly created content type and its instances are migrated to the Drupal 10 site.
The intention of not creating media entities was to simplify things. I thought that by avoiding this, it would make the migration of images easier, as it would be a simpler migration (from image to image, rather than from image to media entity).
Thank you for your reply. What does it mean to "Make sure Drupal is set to handle "Not specified" languages correctly"? There are pages on the net talking (including ai software) about a fallback language. I am not able to find such an option at any of the following locations:
- /admin/config/regional/language
- /admin/config/regional/content-language
I want to suggest some improvements because I am a bit confused about what can an what cannot be done with the configuration system.
The page presents an example of how the configuration can be exported and then imported from one site into a clone of it. The procedure uses a full export of the configuration from the Drupal UI and then a full import.
However, the Drupal UI provides the possibility of exporting individual configuration items. Given the title of the page (which is very general) a reader expects to find in this page hints/suggestions about all the things that can be done with the Drupal UI.
My suggestion is the following: A section should be added somewhere in this page mentioning the possibility of exporting and importing individual configuration items and a sample workflow based on this functionality. This section should explicitly mention if individual configuration items once exported must be imported only in clones of the source site or if they can be imported in non-clones of it. (This last part is my dilemma. Independently of it my suggestion is still valid).
As previously mentioned, I do not know if it is possible to export/import individual configuration items between non-clone sites, but such a possibility would be very useful and should not be missing from the documentation. It would allow one to have for example an important configuration created in a site and next to port it into another non cloned site.
Here is my example:
I already have contents in my website (8 content types with more than 50 entities per content type) and I want to create a node that presents contents from 3 different views. Next I want to create another node that presents contents from other 4 totally different views and maybe some formatted text between the views.
With the help of the View Reference Field I can create a field that references a view display. Once I create a content type that contains a field named for example "display" that has an unlimited cardinallity I can create different instances of that contant type that point to different views. When combined with the Paragraphs module, by creating a paragraph with a field type View Reference the possibilities increase even more.
Essentially I want to use such content types to create the general pages of a web site. These pages usually present more information that a single content type or a view . The homepage of a website presents information from different sources (views, content types some blocks, etc.).
Thank you for your reply.
I've tried that module but contrary to what is written in the EVA module page, view displays are not attached to entities (instances of a content type). Instead, a view display can be attached to a content type. Thus, all instances of that content type have the same view associated with them which is not what I want. I want to change the view from instance to instance.
I've found the Views Reference Field module https://www.drupal.org/project/viewsreference →
quilx → created an issue.
The steps 5, 6 an 7 can further be improved by mentioning "drush udatedb" as an alternative to /update.php
quilx → created an issue.
quilx → created an issue.
I have created a "../config/sync" directory and "drush config:export" is able
to export my site configuration into this folder.
Then when I go to
Administration/Configuration/Development/Synchronize/Import
I get this message: "The directory ../config/sync is not writable"
- This message suggests that the operation needs to write that folder;
- I've tested what happens if I import a .tar.gz file created with the UI export. It overwrites the entire config/sync folder;
For me this workflow is clear. I do not have problems understanding and using it. In
fact I already use it.
My problems were the import and the export commands in the user interface
admin/config/development/configuration/full/import
I've never used them before and I wasn't expecting they behavior I've encountered.
Let me try to explain better my issues:
1) The import command:
The folder ../config/sync is kind of a bridge (a transit place) between your Drupal
installation and a git repository. By using drush and git the information flows from
Drupal into that folder and from that folder into git (and the same way backward).
This woks very well.
In this context the UI import command writes the contents "../config/sync" directory
(the same folder in which drush config:export saves your site configuration) . I was not
expecting this command to interfere with the transit location (for example I can
have data that must be pushed into Git but the import command overwrites it).
Now that I know what the command does I will be careful using it. However, I think
that better solution would be to have 1) a folder used for the transit Drupal <-> Git
and 2) another folder used for the import command, a temporary location. And once
the import operation from the UI is completed, the user could export it into the
../config/sync folder.
2) The export command:
I was expecting the export command to be a UI tool that does the same thing like
"drush config:export" (that is, to write the contents of the folder ../config/sync)
Instead it gives me a .tar.gz file which is fine because maybe you want to save the
config in a .tar.gz file.
Cristian
Thank you Devashish Jangid for your attention.
I was also expecting to be able to export configurations into this folder from
the user interface. In this case to have a writable 'config/sync' directory makes
sense because Apache needs to write that folder.
However when I press "export" from the page you have indicated
{/admin/config/development/configuration/full/export} Drupal does not make
an export into that folder. Instead it offers me a .tar.gz to download. In this
context it seems that the only operation that writes that folder is "import"
which imports a .tar.gz (into the folder in which I saved my precious
configurations).
Cristian