11
Looking at ThemeController::setDefaultTheme (the request handler for the /admin/appearance/default route), this should do the trick:
\Drupal::configFactory()
->getEditable('system.theme')
->set('default', 'machine_name')
->save();
9
In Drupal 7, a install profile is like a module, but a special one, with two major exceptions:
Any module required by a install profile can be disabled --as you have found-- except the ones required by drupal core (field, filter, node, system, user). See module_disable() function for details, where the dependency on the install profile is explicitly ...
8
Doing some research and testing I found a way to inherit Drupal installation profiles, using drush make (works in Drupal 7).
1) Apply Drupal patch #47 submitted in this topic
projects[drupal][type] = core
projects[drupal][version] = 7.32
projects[drupal][patch][] = https://www.drupal.org/files/issues/drupal-inheritable-profiles-2067229-47.patch
2) Set ...
7
To build on what Patrick said, if the profile is not already in your profile directory, you can download it with Drush dl:
drush dl drupal --drupal-project-rename=drupal
cd drupal
drush dl commons
drush site-install commons --db-url=mysql://user:pwd@localhost/db_name --site-name=Example --account-name=admin --account-pass=pwd
You do not need to run drush ...
6
The problem
A bad implementation of your code is causing the confusion. The input data is not stored in the $form_state variable, but in $form_state['input'] initially.
Once the user submit a form, Drupal will build the form again and process the values. In this step, the system make some checks. You can take a look of functions that have been called.
The ...
5
You can Install Drupal using Drush without interacting WEB UI.
You have to use following command
drush dl drupal-7.x --drupal-project-rename=D7
cd D7
drush site-install standard --account-name=admin --account-pass=admin --db-url=mysql://YourMySQLUser:YourMySQLPassword@localhost/YourMySQLDatabase
Ofcourse You have to install Drush if not already installed ...
5
This part of your original question isn't quite clear:
Simply setting it as the default selected profile is not enough.
However, all you have to do is to add exclusive = TRUE in the .info file of your installation profile.
This will automatically select your installation profile, and the user will proceed to the language selection screen.
Note 1: the ...
5
Installation profiles contain code to set up a site during installation, that's all they do. They aren't useful to an installed site.
Trying to change the profile after installation could never conceptually do anything. The installation code has already run, and the purpose of the profile has been served at that point.
5
The minimal profile lives up to its name - the vast majority of modules aren't installed when using it.
This include the core Field UI module, which provides the UI you're missing. Just enable that module and you should see a "Manage fields" link as the default option in the table from your screenshot.
4
You can enable insert by updating the field instance settings with these two core functions:
field_info_instance
field_update_instance
for example:
/**
* Enable insert field settings
*/
function MODULE_field_settings_enable_insert($entity_type, $field_name, $bundle){
// Load field instance
$instance = field_info_instance($entity_type, $field_name, $...
4
You can use the OPTIONAL ATTRIBUTES
root_element[first_key][next_key] = value
The 'projects' attribute is where you define the modules/themes that
are to be packaged with the profile. The first key is the short name
of the project (as seen in the drupal.org/project/{projectshortname}
URI).
These projects are defined using the short form ...
4
I would advise using Features. This would allow not only exporting functionality and compartmentalizing it a lot easier, but you could also have the ability to bring in features later from an external source, and/or, use certain features here on a different site that didnt start with your installation profile.
Currently there is an issue to support custom ...
4
Those are not bugs and have nothing to do with locale.
The standard install profile sets up the administrator role, the theme configuration and many other things, see standard_install() and its default configuration files like the overriden system.theme.yml.
I guess you mean the local tasks with "middle part of the GUI", that is a block and also set up by ...
4
User 1 doesn't need any roles to have super user status. User 1 is exempted from the permissions system entirely. So, they automatically have all permissions, regardless of roles they may or may not have.
4
This will not works because you are only saying to Drupal that your module is installed, but when you install a module there are other process that need to runs to import the configs and execute the .install functions.
But you can create a new module that will install all the other modules, create a .install file and add this inside:
/**
* Implements ...
answered Aug 23 '17 at 17:28
Adrian Cid Almaguer
14.2k11 gold badges52 silver badges94 bronze badges
3
I can't find a hook called hook_profile_final on drupal.org. I also can't see where you found it on the link you're using (https://www.drupal.org/node/1022020). You are using an outdated version of the tutorial (https://www.drupal.org/node/67921).
You need to implement hook_install_tasks_alter https://api.drupal.org/api/drupal/modules%21system%21system.api....
3
There is a constant for the anonymous RID named DRUPAL_ANONYMOUS_RID.
So, you would be able to use something like:
user_role_grant_permissions(DRUPAL_ANONYMOUS_RID, array('your permission 1'));
3
Article Common Drush Make errors and their solutions has a solution for you. It seems that you should provide both branch and revision, if you want to clone exact revision and still have other info filled properly.
projects[ctools][type] = module
projects[ctools][download][type] = git
projects[ctools][download][revision] = 747151e
projects[ctools][download]...
3
Apart from specific code changes like converting the .info file to a .info.yml, the biggest conceptual change is that most of what an install profile will contain are configuration files.
Basically, you can take the configuration directory of in installed site, copy it into the config folder of an install profile and then you're already pretty close to ...
3
If you go to /admin/reports/status, under Drupal if you see something written after Drupal version, that's your installation profile. If there is nothing, that means it is Standard profile.
3
There is no way to switch
you have two solution,
install again
remove standard modules.
lists the modules enabled by the Standard profile, as compared to the Minimal profile
2
Many configuration elements can be exported and imported using Features module.
Features provides a UI and API for taking different site building components from modules with exportables and bundling them together in a single feature module. A feature module is like any other Drupal module except that it declares its components (e.g. views, contexts, CCK ...
2
The Profile Switcher module for D7 may help: https://www.drupal.org/project/profile_switcher
2
Try using the drush site-install command. Name your installation profile with the command argument.
2
If you still want a configuration form, then you can build upon the "Client step" and change the function brochure_client_form_submit($form, &$form_state) so that it suits your needs (all code is untested):
function brochure_client_form_submit($form, &$form_state) {
// Setup the user account array to programatically create a new user.
$account =...
2
Move your post-installation hooks to a module/part-of-your-profile (that can implement any hook and move things around even after the system modules is installed).
That way you can overcome problems like custom block's BLOCK_VISIBILITY_LISTED not working on profile installation hook_install()?, and have a solid last installation step, that makes all ...
2
Checkout this post about Collecting and writing configuration settings to setting.php from an install profile.
It describes how a custom task (via hook_install_tasks_alter()) was injected into the installation profile to display a custom form and, upon submission, how drupal_rewrite_settings() can be used to inject the custom settings into settings.php.
2
Have a look at the function drupal_get_profile
Gets the name of the currently active installation profile.
When this function is called during Drupal's initial installation process, the name of the profile that's about to be installed is stored in the global installation state. At all other times, the "install_profile" setting will be available in ...
2
Solved.
Following https://drupal.stackexchange.com/a/186322/8938 I added the code below to my_profile_install() function inside my_profile.install file.
\Drupal::configFactory()->getEditable('system.menu.footer')->delete();
Reinstalled and yes, footer menu is not around anymore :)
Only top voted, non community-wiki answers of a minimum length are eligible
