You define a schema type sequence:
# Schema for the configuration files of the Options module.
label: 'List (integer) settings'
label: 'Allowed values list'
Collections are for configuration overrides. Mainly used for translations, but could be used for other purposes as well. You can list the available collections in your Drupal installation, starting with the default collection (empty string):
$collections = \Drupal::service('config.manager')->getConfigCollectionInfo()->getCollectionNames();
More info ...
How is this possible and how can I programmatically set the
translations for my field(s)?
You can load language overrides with ConfigurableLanguageManager::getLanguageConfigOverride, set values and save:
Turns out it can be done with the config:export:entity command like so:
drupal config:export:entity paragraphs_type [PARPAGRAPH_TYPE] --module="[YOUR_MODULE]" --optional-config --remove-uuid --remove-config-hash --include-module-dependencies
You are safe to use the same name. The fields are unique for each entity type, even when they have the same name.
They have their own field storage configuration, instances and will be stored to dedicated database tables per entity type.
You're on the right track with the configuration export but i'm guessing you did the single export option for the content type? Each field on your content type has several configuration items that would need to be exported too.
An alternative is to use the Features module https://www.drupal.org/project/features
That will allow you to select your content ...
It's never the best idea to manipulate the database directly (for the usual reasons), but if you're out of other options, it's not that unsafe:
SET value = '<value>'
WHERE collection = 'state'
AND name = 'system.maintenance_mode'
Where <value> is replaced with a serialised PHP string representing the integer value 1 for ...
Thanks to everyone for your responses.
I looked in to using the Domain module but am avoiding for 2 reasons:
It is still in Alpha14 and this is going to be a business critical site
I couldn't work out how to set the domain specific configurations
However, installing the Domain Module and looking at the README file pointed me in the right direction.
Don't push to the develop branch directly. You should have a branch and merge strategy. If using GitHub or GitLab or similar, you would do a pull request of your branch to develop.
A common strategy (or one of) is the Git Flow workflow. Some links to explain Git Flow:
where is the drush cim command specific documentation?
Does cim command remove the files after they are imported
where are the setting files imported from, can you provide me with a
path relative to the root (I mean, relative to where the main
index.php file of drupal is)?
The path to ...
It's a little bit up to you how you manage your config. In my multisites I have a ../config directory outside the web root. Each site instance then has it's own folder in there. And inside each one I split the config per environment.
shared/ holds the config that is similar on all environments. local/ holds all the extra config for local development. And ...
so for what it's worth using the default/settings.php as the master and then having each of the sites do a PHP include (as @Alan mentions) does work well! (I know this is an old question but I am working through multisite issues with Drupal 8 (8.6.13) and have come across this very thing...)
a couple of caveats:
1) I am managing the multisite installation ...
You can read about it in the default.settings.php file:
Salt for one-time login links, cancel links, form tokens, etc.
This variable will be set to a random value by the installer. All one-time
login links will be invalidated if the value is changed. Note that if your
site is deployed on a cluster of web servers, you must ensure that this
Importing configuration in SQL alone is not possible, you need to run PHP code.
From the command line, if you don't have Drush installed, you can download Drush on the fly and execute the import command:
php drush.phar config-import
To add an add more button you'll need to create a callback function that will increase the number of fields necessary and rebuild that part of the form based on that information. You can make a new config variable based on some sort of index as you do a loop through all the necessary fields.
I haven't tested this so the syntax might be off but here's the ...
A module install should not update config. If you want to update existing config, your module should implement hook_update_N() (see docs) instead.
However, you could add a dependencies: enforced section to your YML config files. This will remove your existing config on module uninstall, and install the newest config on module reinstall. This way you can "...
The config system has switched already to events and the documentation for events describes in "My First Drupal 8 Event Subscriber" how to subscribe to a config event:
See also this example from the Color module:
I was recently struggling how to store data with a nested array of strings,
The only way I could figure out how to validate it was by running functional tests, where it validates the configs when you save a config entity.
I was able to save data like the above data by nesting 'sequences':
This was custom openid_connect plugin I was working on, so a bit different than a ConfigFormBase normal configuration form, but I hope this methodology applies and is helpful to someone in the future.
I used a schema like so (snippet):
# Schema for the configuration files of the OpenID Connect module.
Nowhere, most of configuration is located in database including webform.
With config module, you may find webform configuration in admin (yml) : /admin/config/development/configuration/single/export
First, select webform in configuration type, then the configuration you need to export.
NB : have a look at sources https://github.com/drupalprojects/webform/...
One way is to create a small testing module that contains specific config you need for a test, then have the test use it as a dependency. In my case, I put that module itself under the tests directory and marked it as hidden in its info file.
Although a drawback would be keeping these config files up to date when the system changes - but failing tests ...
If you're looking for a custom-code centric path. Both D7 & D8 provide a hook_views_pre_execute() hook. It will trigger prior to any view query execution.
You can hook into this function, inspect $view object for the particular view you're wanting to extend your PHP execution, then call the PHP function of your choice.
If the module was never installed in the target environment, it is safe to do so.
If the module was installed before however, and it features uninstall hooks for cleaning up possibly installed database tables, key/value pairs (State API), and the like, then your approach may leave data behind.
The more appropriate way would have been to uninstall the ...
I solved it with Drush.
To get around the UUID mismatch I uncommented the UUID field in system.site.yml and ran drush cim. After that I specifically set the UUID by running drush cset "system.site" uuid "my site id".
Yes you can but why not just remove the field ? here is a few ideas on to how to do it..
$settings['stop_captcha_from_being_stupid'] = TRUE;
$settings['enviroment_name'] = 'dev';
in some hook_form_alter
use Drupal\Core\Site\Settings; // above ^^^
$stop_capcha = Settings::get('stop_captcha_from_being_stupid') ;