happyculture / kumquat_kickstarter
Drupal project site building kickstarter
Installs: 0
Dependents: 0
Suggesters: 0
Security: 0
Stars: 0
Watchers: 0
Forks: 0
Open Issues: 9
Type:drupal-module
Requires
- drupal/migrate_plus: ^5 || ^6
- drupal/migrate_spreadsheet: ^2
Suggests
- drush commandes to run migrations: drupal/migrate_tools:^5 OR drush/drush:^10.5
- patch on drupal/core #1: Add patch from https://www.drupal.org/project/drupal/issues/3118262 on drupal/core to be able to use the migrations to update configuration entities
- patch on drupal/core #2: Add patch from https://www.drupal.org/project/drupal/issues/2845340 on drupal/core to prevent migration map table names to be truncated
- patch on drupal/migrate_spreadsheet: Add https://www.drupal.org/files/issues/2019-12-06/3032719-no-error-on-null.patch patch on migrate_spreadsheet and use the skip_on_empty process to prevent additional lines to be processed
- 1.x-dev
- 1.1.1
- 1.1.0
- 1.0.1
- 1.0.0
- 1.0.0-rc1
- 1.0.0-alpha21
- 1.0.0-alpha20
- 1.0.0-alpha19
- 1.0.0-alpha18
- 1.0.0-alpha17
- 1.0.0-alpha16
- 1.0.0-alpha15
- 1.0.0-alpha14
- 1.0.0-alpha13
- 1.0.0-alpha12
- 1.0.0-alpha11
- 1.0.0-alpha10
- 1.0.0-alpha9
- 1.0.0-alpha8
- 1.0.0-alpha7
- 1.0.0-alpha6
- 1.0.0-alpha5
- 1.0.0-alpha4
- 1.0.0-alpha3
- 1.0.0-alpha2
- 1.0.0-alpha1
This package is auto-updated.
Last update: 2024-11-07 12:59:12 UTC
README
Kumquat Kickstarter
Kumquat kickstarter is a drupal module that helps you start your Drupal projects faster by migrating entity bundles and fields from a spreadsheet.
Installation
composer require happyculture/kumquat_kickstarter --dev
drush en kumquat_kickstarter
Basic usage
- Copy this Google Sheet into your own Drive and fill it with data
- Each bundle you want to create must have an entry in the
Bundles
worksheet - Each bundle for which you want fields must have its own woksheet named
Field: [BUNDLE LABEL]
based on theFields: Actualités
worksheet
- Each bundle you want to create must have an entry in the
- Export it as ODS format, name it
site_builder.ods
and place it in your../config/
directory - Migrate the bundles:
drush migrate:import --tag kumquat_kickstarter_entity_bundles
- Clear Drupal cache to get the new bundles detected:
drush cache:rebuild
- Migrate the fields:
drush migrate:import --tag kumquat_kickstarter_fields
- Migrate the default form modes:
drush migrate:import --tag kumquat_kickstarter_default_form_mode
- Export the created configuration
Advanced usage
Running all fields migrations of a specific bundle
Fields migrations are generated using a custom migration tag that allows to run all fields migration of a specific bundle at once. This tags is the form of kumquat_kickstarter_fields:ENTITY_TYPE__BUNBLE
.
For example, to run the fields migrations of the news_categories
vocabulary, you can run drush migrate:import --tag kumquat_kickstarter_fields:taxonomy_term__news_categories
.
Prepopulating migrate maps after site reinstall
It can help a lot to prepopulate the migrate maps when you reinstall your site from scratch to prevent future migrations to override your existing entities.
To do so, you can use the drush kumquat_kickstarter:prepropulate --tag kumquat_kickstarter
command.
Translating the spreasheet in your language
You may have noticed but the first line of each worksheet is hidden. It contains the name used by the script to migrate the data. The headers line that you can see is dedicated to end users and can be translated.
The names of the entity and field types cannot be translated, though. They are used by the migration to get important settings from the code.
Translating the configuration that you migrate
Configuration is imported using the site's default language. To be able to also import the translated version of the configuration for your other enabled languages you'll need to add some columns in the document.
The additional columns have to be named like the reference column (see below) appended by an uppercased langcode.
Reference columns for bundles:
- Name
- Description
Reference columns for fields (include label override):
- Field label
- Help text
For example, if your default language is French and if you want the configuration to be translated in English and Spanish, you'll need to add "Name EN", "Name SP", "Description EN" and "Description SP" columns to your Bundles worksheet. You'll also need to add "Field label EN", "Field label SP", "Help text EN" and "Help text SP" columns to your fields worksheets.
Using contributed and custom entities
To add an entity type:
- Enable the module that carries the entity type
- Find the PHP Class that define the bundle entity ('bundle of' in the Annotation)
- Copy the exact label value of your bundle entity
- Paste it in the A column of the
Settings
worksheet - You can start using this new type in the
Bundles
worksheet and run migrations to get those bundles migrated
Troubleshooting
Errors when defining fields settings
Invalid YAML
Most of the time, invalid YAML will not throw any useful error. Be careful to respect indentation and wrap keys or values including spaces into some quotes.
Field types that convert settings
The settings columns need to be filled with YAML. Most of the time, you can take the YAML from the settings a field created in the UI, but sometimes, for example for list fields, it won't work. The thing is that some field types implements a storageSettingsFromConfigData()
or a fieldSettingsFromConfigData()
static method that converts the settings.
For example, for a List (text) field, you would find the following in the field storage configuration object:
allowed_values:
-
value: my_key
label: 'My label'
-
value: my_other_key
label: 'My other label'
But because of the ListItemBase::storageSettingsFromConfigData()
method, you will need to put the following in the migration source file:
allowed_values:
my_key: 'My label'
my_other_key: 'My other label'
Credits
The font used for the logo is Smooth Butter from PutraCetol Studio.