Problem/Motivation

#2577407: Module install form has two "install" buttons that do different things exposed the issue that once "add new module" has been clicked the following screens also need better wording.

Both that issue and this one stem owe their existence to a change that was made in Drupal 8 whereby modules are no longer enabled and disabled but only installed or uninstalled.

In the case of #2577407: Module install form has two "install" buttons that do different things that created a situation where the nomenclature was confusing. At the top of the page the user sees a link to "Install modules" and at the bottom the submit form also reads "Install" (assuming update manager is installed). The solution there was to change the top link to read "Add new modules".

Here the case is slightly different. We have the page the user lands on when they click "add new modules", which looks like this:

1. The help text could be more explicit and direct the user.
2. We are still in the "adding" flow and "installing" does not happen until the modules have been "added" to the site so the title needs to change.
3. The label "Install from a URL" suggests improperly that this step installs the module which it does not.
4. 'Upload a module or theme archive to install' is overly verbose for a label
5. The submit button says 'install', but the module/theme is not being installed, but uploaded or imported to be installed back on the extend page.

Proposed resolution

Remove references to 'installing' from this page. Make it explicit through the title that the user must go and 'get' the modules they need to install from elsewhere. Clearly disambiguate the two ways a user can get modules, Import (as opposed to install) or upload. Make the labels and descriptions less verbose and be clear that the submit applies to either import or upload.

Remaining tasks

It's important to note that if we were to use "add" in the submit text or in the title the user may get the impression that submitting this form (adding) installs the module.

Additionally we need to make the messages that these actions return match the nomenclature we use here.

Write patch

User interface changes

New wording (see above)

API changes

-

Data model changes

-

Problem/Motivation

The module install form (admin/modules) has two buttons that do different things:

• Install new module downloads and installs a module
• Install installs the modules that were selected on the form

At the top is:

In HEAD, the bottom link is:

But the consensus is to change it to:

This has confused at least a few people on this issue.

Proposed resolution

Rename the first button "Add new module".

Remaining tasks

User interface changes

Yes, button rewording.

API changes

Data model changes

Problem/Motivation

For three content entity types (menu_link_content, shortcut and taxonomy_term), in respective overview form, the operation list is hardcoded (e.g. core/modules/taxonomy/src/Form/OverviewTerms.php:269).
If I add a new operation via the hook_entity_operation, the new operation don't appear in the list.

Take taxonomy_term as an example:

Define the new operation

function mymodule_entity_operation(EntityInterface $entity) {
  if ($entity->getEntityTypeId() == 'taxonomy_term'&& $entity->hasLinkTemplate('mymodule-link')) {
    return ['my_operation' => ['title' => t('My operation'),'weight' => 50,'url' => $entity->toUrl('mymodule-link'),
      ],
    ];
  }

The new operation don't appear in the list /admin/structure/taxonomy/manage/{taxonomy_vocabulary}/overview

Proposed resolution

For me, each entity could provide his operation list.
I would add (like linkTemplate):

• In the entity type (\Drupal\Core\Entity\EntityType): To replace the hook_entity_operation, a couple of method setOperation() to add operations and getOperations() to retrieve all operations defined for the entity type
• In the entity (Drupal\Core\Entity\Entity): a new method operations() the get the operation list for one entity
• Each entity (e.g. taxonomy_term \Drupal\taxonomy\Entity\Term) can override this method to add own specific operations

Remaining tasks

Discuss
Writing the patch

It's not possible to create tables with datetime fields using the schema api if you want to have a default value of now() or current_timestamp. This happens because all strings are escaped with ' before going to the database. Database function calls like now() do not work if escaped. The attached patch allows now() to be used for datetime fields.

Drupal 8,

How to switch between installation profiles in same instance??
(minimal to standard / standard to minimal)

Problem/Motivation

The actual rollback is very slow because it removes the destination objects and mapping records item by item. In D7, destinations were able to declare a bulkRollback() method. Migrations with such destinations took advantage of using faster APIs to delete the destination objects.

Proposed resolution

Add back the ability to run fast/bulk rollbacks but make it optional and defaulting to item-by-item rollback.

• A new destination interface MigrateDestinationFastRollbackInterface
• Destinations able to run fast rollbacks should explicitly demand this by adding the destination setting fast_rollback: true in their config, in migration .yml file.
• Add event dispatching for such operations.
• A fast rollback can have 2 types: batch or all-in-one rollbacks. By setting the destination setting fast_rollback_batch_size: 0, in the migration .yml file, the rollback will run in a single step (all-in-one). When the value is positive integer, that will override the default batch size of 50.
• Add a new methods MigrateIdMapInterface::deleteMultiple() and MigrateIdMapInterface::deleteAll() that allows bulk deletion of map items.

Remaining tasks

• Decide if some destination plugins can be converted to use fast rollbacks (follow-ups).

User interface changes

API changes

Data model changes

See ^^^.

Hello,
We have a big problem with our site.
We restore database from backup, clear cache and all special characters like "®", "em dash", "apostrophe" etc. are lost from the content. (replaced to "?" character )
We've tried to make backup via phpmyadmin and backup and migrate module. ( got same result)
Server is running on CentOS, php version is 5.5, mysql 5.5.52 version is.
Also we tried use defferent database encodings, such as utf8_general_ci and utf8mb4_general_ci
Drupal core 8.2.4
Please help.

Problem:

Issue summary:

NOTE: if you are trying to solve this novice issue, the plan of attack is at http://drupal.org/node/1170362#comment-5050480. We need a simple patch that takes most of http://drupal.org/node/1170362#comment-5011400 but instead of hiding the warning when a profile is not found, it displays its label as "Unknown").

There are multiple issues with install profiles, both within Drupal 7 and on upgraded Drupal 6 sites, these all end up with the same symptom: "Undefined index: distribution_name" due to system_requirements().

Drush 3 and dependencies

When profiles were made into modules, the modules the profiles need were put in dependencies. Unlike other modules, however, these are not real dependencies: your system might still work if you disable some. Like, installing the standard profile then disabling overlay module.

This bug was discovered in #820054: Add support for recommends[] and fix install profile dependency special casing however fixing it would have required an API change for install profile developers, so that issue is only marked against Drupal 8, and workarounds were put into all code dealing with module dependencies to special case profiles instead.

Those workarounds were put into Drush 4/5 as well, but not Drush 3, which is still in use. So any site that runs drush updb with Drush 3 will have its install profile disabled by drush.

There's nothing that can be done about this in drush 3, and the bug is in core, so this issue tried to fix that.

update.php

sun's patches above demonstrate that just running update.php on D7 can disable your install profile, due to some weird things going on in _system_rebuild_module_data()

Sites upgrading from Drupal 6 to a different install profile

In Drupal 6, install profiles were 'run once', this meant that you could make a custom install profile for a site, install it, then never touch the install profile again (including when upgrading). When install profiles became required (half-)modules in Drupal 7, support for this was completely removed - if you install with a profile, we're currently requiring you to upgrade the specific profile you installed with through every possible future version of Drupal core. #1242956: Allow install profiles to be uninstalled starts to discuss this, but since this blocks the upgrade path from D6 it's probably a legitimate bug here too

.

Proposed solution

There are a couple of ways to fix this, and they may be contradictory.

sun's patch started work on automatically ensuring the install profile is enabled every time _system_rebuild_module_data() is called. This would fix install profiles that have been disabled by drush 3 or update.php

However, there is no straight bug fix solution for the situation where a site is no longer using an install profile. For this we could either start allowing people to explicitly disable an install profile, or just make the system tolerant when none is found in the system (for example setting the site to use the 'minimal' profile which should never have any runtime code added to it).

To minimize the number of new comments asking for it, here's a work-around for current Drupal 7 users: You need to enable the profile used to install Drupal by updating the system table. For example: UPDATE system SET status=1 WHERE name='standard'; will enable the Standard profile. If you don't know which profile was used, just use 'standard'.

Problem/Motivation

field_default_validate() doesn't validate required empty field values.

Proposed resolution

Add required empty field values validation to field_default_validate().

Remaining tasks

1. Provide patch - Done.
2. Review patch.
3. Commit patch.

User interface changes

None.

API changes

None.

Data model changes

None.

Problem/Motivation

Steps to reproduce:

1. Create an entity with two translations.
2. Reload the entity.
3. Execute $entity->getTranslation("second_langcode");
4. Execute $clone = clone $entity
5. Test that $entity->field_name === $clone->field_name. Changing field values in $clone now also changes the values in $entity which precisely breaks the contract of the clone operation.

This affects content entity forms because during validation a clone of the entity is populated with the user submitted values to perform $cloned_entity->validate(). Due to this bug, after Ajax operations in content entity forms, the values in $this->entity during subsequent form building are actually the updated values from the user input and not the original entity values.

When there are at least three languages and a node has been created and translated into one language (but not the other(s)), it is possible to change the language of the original node to the language(s) in which no translation exist(s) yet. Due to the above problem this means that $this->entity->language() returns the previously selected language after Ajax requests - which may differ from the original entity language.

ContentEntityForm::updateFormLangcode() is run as an #entity_builder, so that $form_state->getLangcode() will return the previously selected language after Ajax requests. The fact that an #entity_builder has side effects is problematic, as discussed in #2799637: Document that #entity_builders and overrides of EntityForm::copyFormValuesToEntity() must be idempotent. In this concrete case, however, the problem is masked, because due to the bug described above, $form_state->getFormObject()->getEntity()->language()->getId() and $form_state->getFormLangcode() always return the same thing.

Thus, fixing the clone bug leads to the case where the language of the entity and the form langcode are different: The language of the entity is no longer (inadvertently) updated, but the form langcode is still updated by the #entity_builder. This breaks an expectation in the Paragraphs module.

Proposed resolution

Ensure the fields array is actually cloned by overwriting the original reference with one pointing to a copy of the array.

The original solution of only fixing the cloning discovered another bug and it is that when cloning properly then the form will be rebuild with the original entity instead of the modified one (which has been caused by the wrongly cloning). The problem relies in the entity builder ContentEntityForm::updateFormLangcode which is not idempotent and will change the langcode stored in the form state storage each time an ajax call is triggered and the user has changed the language in the language widget when ContentEntityForm::validate is executed and the entity build for validation with the user submitted values. So what we have now is that we are not setting $this->entity generated based on the user input on ajax calls but we are updating the form state langcode based on this intermediate entity which we are throwing away. Setting $this->entity is impossible as #2811841: Add test coverage ensuring user input is mapped on the correct form elements when elements are reordered currently shows.

We have currently two approaches which we are discussing:

1. Do not use the entity builder ContentEntityForm::updateFormLangcode as it is not idempotent, leave the function there and mark it as deprecated as of Drupal 9.0.0. This approach assumes as we are not setting $this->entity and rebuilding the form with the original entity that the form language is still the original one and if some code used to rely on changing the language in the form state the new language from the language widget has to be retrieved using $form_state->getValue($entity->getEntityType()->getKey("langcode")). This approach solves all the provided tests.

2. Always update the form state language code even if not setting $this->entity and continue using the entity builder ContentEntityForm::updateFormLangcode. This approach still has the problem that the title of the page will suddenly be changed by the content_translation module, as on form rebuild the decision would be made that a translation is being edited and [%translatio% translation] will be added to the page title. Additionally during form rebuild the form alter hooks which generated the first form send to the user now will be called with a form state indicating a different language than the one of the entity used now for rebuilding the form.

Remaining tasks

Review.

User interface changes

none.

API changes

none.

Data model changes

none.

Setting #default_value on a form element of type 'date' does nothing. Looking at the html source, it seems like the default value is set on the element, but misc/date.js ignores it.

On the Drupal project page, the "Installation Guide" link in this line is incorrect:

Before installing Drupal, please review the system requirements and the Installation Guide.

This links to https://www.drupal.org/documentation/install, which redirects to https://www.drupal.org/docs/7/install

This should probably redirect to (or link directly to) https://www.drupal.org/docs/8/install at this point.

Problem/Motivation

When disabling modules that create fields this error is sometimes displayed. The message does not make it clear what caused the issue or how to fix it which is frustrating for users.

If you want to fix the underlying issue that causes this message check out http://drupal.org/node/943772.

Proposed resolution

Change message to be more descriptive and more helpful in resolving the issue

There are Fields pending deletion that were created by a module you just tried to disable. Delete offending fields now or try running cron, it might fix this issue.

The error message is produced by field_system_info_alter() in core/modules/field/field.module.

Remaining tasks

1. Finalize the message text
2. Write a patch

Original report by [joachim]

I saw this message in my modules list and it completely baffled me.
I only found out I had to run cron thanks to a comment buried in an issue on a contrib module somewhere.
When this text appears in the module admin page it should be linked to further help.

Problem/Motivation

If I create a role and have the Actions module enabled I can edit the role created by user_user_role_insert() - but I can not save. This is because the ID has a dot in it.

Proposed resolution

There are currently three proposals:

1. Allow actions to have dots in their config names (as is true of entity_view_mode, entity_form_mode, block, and config_test)
2. Change user_user_role_insert to not create actions with dots
3. Add a UI lock on actions, and lock those created via user_user_role_insert (similar to date_format).

#3 might be appropriate since these actions are created and deleted by the User module. In fact the user_user_role_delete is completely unnecessary because of configuration dependencies. So therefore it could be possible to remove that and just create an action with an ID that can be edited.

However this is related to a wider issue of should configuration entities be able to control the meaning of dots in their ID see #2100203: Make config entities use dots in machine names consistently

Remaining tasks

Agree approach

User interface changes

tbd

API changes

tbd

Data model changes

tbd

Why is this a possible RC target

The UI makes it look like such actions are editable but they are not. We have a form where the submit is impossible - regardless of what the user does.

Tried with multiple views many times

Configuration block.block.bootstrap_mytheme_account_menu depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_branding depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_breadcrumbs depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_content depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_footer depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_help depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_local_actions depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_local_tasks depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_login depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_main_menu depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_messages depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_page_title depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_powered depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_search depends on the bootstrap_mytheme theme that will not be installed after import.
Configuration block.block.bootstrap_mytheme_tools depends on the bootstrap_mytheme theme that will not be installed after import.

Note that this is tagged against 8.1.x currently. If retitled "No way to retrieve an entity's URL alias via Rest" this could also be seen as a bug report and tagged against 8.0.x, but not sure about that.

Problem/Motivation

When normalizing a node or another entity with a path field, the alias is not part of the normalized entity.

This is because when loading an entity the path field item list never gets any field items, it only acts upon the saving of the entity. If there are no field items, the default field normalizer (rightfully) skips the field.

Proposed resolution

Provide a dedicated normalizer for path fields that fetches an entity's alias in the same way that \Drupal\path\Plugin\Field\FieldWidget\PathWidget::formElement() does and creates a field item for it.

The pid of the alias is not contained in the field item for the same reason we do not expose the entity ID in the normalization. We cannot convert the pid into a UUID (because aliases do not have UUIDs) so we simply skip it.

Remaining tasks

User interface changes

None.

API changes

None.

Data model changes

The normalized version of entities with path fields now contain said fields with the alias value.

Hi,
When I install a new module, I end up on this error page :

The website encountered an unexpected error. Please try again later.
InvalidArgumentException: Source path ://mysitename/admin/modules/install has to start with a slash. in Drupal\Core\Path\AliasManager->getAliasByPath() (line 186 of core/lib/Drupal/Core/Path/AliasManager.php).

However, the module installation works perfectly, so it's not a big problem, but I think this is a not a normal behavior...
Thx.

Problem/Motivation

A theme hook can specify a 'base hook' in order to inherit the preprocess functions.

This currently only works if the theme hook uses the __ pattern:

function mymodule_theme() {
  return ['foo__bar' => ['base hook' => 'foo',
    ],
  ];
}

Proposed resolution

Specifically handle the theme hooks not using a double underscore by merging directly, while leaving the while() loop handling in place for double underscores.

Remaining tasks

N/A

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Currently in the Appearance section of Bartik, a live preview of a chosen color scheme is displayed as an image. This section uses Latin placeholder text, "Lorem ipsum . . . ." The problem is getting users to understand the Latin is JUST A PLACEHOLDER. Participants in a Drupal usability study at the University of Minnesota in 2011 expected it to be the live preview of the site with THEIR content. Looking at the Latin text, one participant in the study said, "What's this? French?"

In this thread from May 2011 to December 2014, contributors have narrowed in on recommending a patch to change the Latin text to repetitions of the English words "Sample text." Other suggestions have been to make the text translatable or to imbed the content of the actual site as an iFrame. Placing "sample text" is the most simple of the solutions and would look like this:

Sample text

Sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text sample text.