Currently the dragable field "User name and password" mashes together:

- Username
- Current password
- E-mail address
- Change Password

I don't see this as very user friendly, especially the placement of the Current password.

Username, E-mail address and Change Password should be separate dragable fields in Manage Fields.

Current password should be made smarter and only show when it is needed to be entered, i.e when a user is changing the e-mail or password. Either Drupal will notice that changes are made and make it visible, or it will be asked for when the user clicks on the Save button.

Preferable these changes should also be backported to Drupal 7.

Updated: Comment #122
See details about the Usability Study at http://groups.drupal.org/node/163894

This issue contains suggestions and attempts to modify the display of these to fields to make it clear to the user how to 'update' the account password.

Problem/Motivation

During a usability test, users logged into Drupal could not determine how to update their account password. Users did not understand that the existing 'password' and 'confirm password' fields on the user/edit page served the purpose of a password update.

Proposed resolution

Proposed resolution from #59:
1. Change new password label from "Password" to "New password".
2. Move "Current password" to below "New password" and use the #states system to show it only when "Email address" or "New password" fields change.
3. Only show "Confirm new password" field if "New password" field has been populated. Makes sense to use the #states system for this. Additionally it helps save vertical distance to avoid missing the shown "Current password" field when editing username.

Screenshots to explain a proposed resolution

1. Upon load, only one password field visible:

2. Upon changing email address, "current password" field becomes visible:

3. Upon entering text in "New Password" field, "Current password" (and "Confirm password") fields become visible:

Criticisms of proposed solution

1. @webchick is concerned about the visual distance between the Email and Confirm password fields. See #65 and #86. She also suggested a review by someone not involved in the patch, this is what @victorkane did in #89 which verified that the proposed solution is already in use on other sites and that the proposed solution provides the proper usability.

Previous/alternative proposal summary

1. Change the name of the field to "New Password"
Suggested in #11
2. Move password fields to the end of the form
3. (rejected) Move password fields into a fieldset
See #19. Concern is that users do not put in the old password when changing a password, so they have to fill out the form again.
4. (rejected) Move password fields into a collapsed fieldset
Same concerns as for fieldset.
5. Move everything but password, email, and username fields to their own tab
See #9
6. Modal: On submit, if either the email or password field has changed, a modal appears prompting the user to fill in the previous password field.
See #70

Remaining tasks

Review patch in #122, decide if this solution works. If not asses other solutions, e.g. #70.

Followup for #2283977: Create a new ConfigEntity type for storing bundle-specific customizations of base fields

- FieldConfigBase looks like a bag of methods without much structure
- FieldConfigInterface should group setters together (allowBundleRename() & targetBundle() sit in the middle of two setters)

Since Drupal 8 is released there are some bugs inside the language system. sometimes you see them and sometimes you don't:

So I thought to start a Drupal 8.7-rc1 install and make a list by screenshots to show you what's broken.

1. Test against installing process

When Starting the Installer The language selection screen still containing english strings. Although the right Language is detected by useing browser detection

Suggestion

Add the ability to translate the 8 English strings shown here by using browser detection, too.

When the installer is started after choosing the desired language there are still untranslated strings. In the example above it shows the Installed filter module. The corresponding string in Core for German is translated so there shouldn't be an error. https://localize.drupal.org/translate/languages/de/translate?sid=248264

To make sure that this isn't a fault of translators I changed the username string in core back to English by copying the original string to German translation as you can see here:

Meanwhile, I revoked this to make sure everything it's all right.

So it is proved there are strings even in the installer, not translated since years.

2. Check user interface translation against a minimal profile to find even more bugs

To make sure this issue won't get too long I spawned a minimal install and navigated to http://localhost/admin/config/regional/translate just to see what else isn't translated.

Drupal has a number of strings representing time-zones and/or Country regions. By using the standard Profile the translation interface shows approx. 15 pages of untranslated strings like the strings shown above.

That means There is something missing in the core.

Notes:

The German translation has a 100 % core translation so there is no reason to check this through l.d.0 UI, again.
I am sure someone is aware of this already.
If not It's good to have an Issue opened to fix this before 8.8 comes out.

How can you help?

• If you are a translation team member of any language other than German check against this issue in your own language and report if you can confirm the same errors for your own language as well.
• If you are a maintainer of the translation server project: Just drop me a note about how to fix this. maybe core translation in German is corrupted in some way I do not know. Let me know if we can do anything to fix this without diving into code.
• If you familiar with the core Issue Queque and know Issue Templates by heart. reformat this issue to make it much more clear than I did.

I added a file field to the user entity and followed the instructions here by enabling and configuring the new file_upload REST resource plugin to use simple_oauth for authentication. I then attempted to POST a new file at /file/upload/user/user/field_headshot_file?_format=json, but am getting a 403 indicating that the `administer users` permission is required. If I give the role belonging to the user in question the `administer users` permission I am able to upload the file successfully. This is contrary to how things work through the UI, however, as the user is able to login and edit their own user account without the `administer users` permission.

After talking with @wim-leers on this, he pointed me to the line in code in core/modules/file/src/Plugin/rest/resource/FileUploadResource.php that is throwing the access denied:

    $access_result = $entity_access_control_handler->createAccess($bundle, NULL, [], TRUE)
      ->andIf($entity_access_control_handler->fieldAccess('edit', $field_definition, NULL, NULL, TRUE));

It’s looking like the issue is that the FileUploadResource is checking for create access for the entity the file is being uploaded to. That *might* make sense when a user is editing a blog post (there's probably a scenario where a user can edit blogs, but not create new ones), but is seemingly overly restrictive when a user is editing their own account, since in reality, they don't need to have the ability to create new users to perform this action through the UI.

I'm migrating a multilingual plain-HTML site to Drupal. It has loads of pages in three languages. I'm getting into a situation where I will be creating nodes in various languages, and won't know ahead of time which are actually translations of each other. I want to then go back and "link" the nodes together in translation sets, as I was used to doing with i18n in D7, but there seems to be no such option in D8. Is this correct?

If so, it means I would need to basically add the translation, copy-paste my node content into the new node translation, then delete the previous translation node. Kind of roundabout and would be so much nicer to just be able to have a node reference autocomplete field to indicate which node should be associated with the German or Czech translation, for example.

I did read through some of the d8 discussions on translation sets, and it appears there had been a decision not to have that functionality (at least not the autocomplete UI portion of it) in D8. I think there's still very much a use case for it.

Problem/Motivation

Currently several process plugins check for valid input before processing:

ArrayBuild,
Callback
Concat
Explode
Extract
FileCopy
Flatten
FormatDate
MakeUniqueBase
StaticMap
SubStr
UrlEncode

Of those, Callback is the only one that throws an InvalidArgumentException on invalid input. Every other plugin throws a MigrateException on invalid input. While both exceptions are caught and logged in roughly the same way, we should be consistent and use MigrateExceptions in all migrate process plugins.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

I'm getting a 500 error when I upgraded from 9.2.10 to 9.3 today. This is what I see when I added verbose to settings.php:

The website encountered an unexpected error. Please try again later.
Error: Class 'Drupal\Core\Update\UpdateHookRegistry' not found in require_once() (line 24 of core/includes/schema.inc).
require_once() (Line: 569)
Drupal\Core\DrupalKernel->loadLegacyIncludes() (Line: 583)
Drupal\Core\DrupalKernel->preHandle(Object) (Line: 46)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 50)
Drupal\ban\BanMiddleware->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 708)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

My dev site is working perfectly with no issues.

Does anyone have this same issue? Or know how to solve this?

Hello all, it’s time for the weekly migration subsystem meeting. The meeting will take place in slack in various threads
This meeting:
➤ Is for core migrate maintainers and developers and anybody else in the community with an interest in migrations
➤ Usually happens every Thursday and alternates between 1400 and 2100 UTC.
➤ Is done on the #migration channel in Drupal Slack (see www.drupal.org/slack for information).
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to. See the parent issue for an idea of the typical agenda.
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

Core migration issues

• RTBC
• NR
• all open
• Statistics, Google spreadsheet

Next video meeting 2022-13-01 2100Z

The hope is that most or all of the maintainers will attend. We will try to focus on longer-term goals than in the weekly meeting.

Hello all, it’s time for the weekly migration subsystem meeting. The meeting will take place in slack in various threads
This meeting:
➤ Is for core migrate maintainers and developers and anybody else in the community with an interest in migrations
➤ Usually happens every Thursday and alternates between 1400 and 2100 UTC.
➤ Is done on the #migration channel in Drupal Slack (see www.drupal.org/slack for information).
➤ Happens in threads, which you can follow to be notified of new replies even if you don’t comment in the thread. You may also join the meeting later and participate asynchronously!
➤ Has a public agenda anyone can add to. See the parent issue for an idea of the typical agenda.
➤*Transcript will be exported and posted* to the agenda issue. For anonymous comments, start with a :bust_in_silhouette: emoji. To take a comment or thread off the record, start with a :no_entry_sign: emoji.

Core migration issues

• RTBC
• NR
• all open
• Statistics, Google spreadsheet

Next video meeting 2022-13-01 2100Z

The hope is that most or all of the maintainers will attend. We will try to focus on longer-term goals than in the weekly meeting.

0️⃣ Who is here today?

1️⃣ What should we talk about today? Suggest topics here and I will add threads. I will also check for comments on the issue for today's meeting.

2️⃣ Action items. To be added later.

3️⃣ Statistics

4️⃣ Comment in this thread if you are looking for ways to help. Give us some idea of what you would like to do: documentation, code review, testing, project management, ...

5️⃣ Previous minutes.

6️⃣ Handling files when migrating from D6 or D7

Media Reference: Using the Record Media Ref Plugin

This plugin fills in the field_original_ref data with a hashed file path. This allows later entity migrations to lookup media data by file path.

 process:
   'field_original_ref':
   -
     plugin: migration_lookup
     source: field_old_image
     migration: example_file
     no_stub: true
   -
     plugin: record_media_ref

field_file_attachment:
    -
      plugin: sub_process
      source: field_file_attachment
      process:
        target_id: fid
        display: display
        description: description

field  field_document_media:    
    -    
      plugin: migration_lookup    
      source: field_file_attachemnt    
      migration: upgrade_d7_file    
      no_stub: true    
    -    
      plugin: update_file_to_document

      plugin: sub_process
-      source: field_file_attachment
-      process:
-        target_id: fid
-        display: display
-        description: description

field_document_media:
  plugin: subprocess
  source: field_file_attachment
  process:
    target_id:
      - 
        plugin: migration_lookup    
        source: field_file_attachemnt    
        migration: upgrade_d7_file    
        no_stub: true  
      -
        plugin: update_file_to_document<

field_document_media:
    -
      plugin: sub_process
      source: field_file_attachemnt
      process:
        target_id:
          -
            plugin: migration_lookup
            source: fid                                                                                                                                                       
            migration: upgrade_d7_file
            no_stub: true
          -
            plugin: update_file_to_document

7️⃣ In Callback Migrate process, allow functions that accept no arguments to be used as callable

?+ * - no_args: (optional) Whether to pass no arguments to the callback. To be
+ *   used in cases where a function does not accept arguments, such as time().
+ *
  *
  * Examples:
  *

<br />
<b>Fatal error</b>:  Uncaught ArgumentCountError: time() expects exactly 0 arguments, 1 given in [...][...]:4
Stack trace:
#0 [...][...](4): time('')
#1 {main}  thrown in <b>[...][...]</b> on line <b>4</b><br />

php > function foo() { return time(); }
php > echo foo();
1639060902
php > echo foo('');
1639060906

field_timestamp:
  plugin: service
  service: datetime.time
  method: getCurrentTime # or getRequestTime

process:
  time:
    plugin: callback
    callable: time
    unpack_source: true
    source: {  }

'pi' => [
  'pi',
  [],
  pi(),
],

8️⃣ ContentEntity source plugin shouldn't throw exception when the bundle key is missing: unavoidable in rollback situations

9️⃣ Wrap up

Grouping a date filter results in an undefined index notice:

Notice: Undefined index: #states in Drupal\views\Plugin\views\filter\FilterPluginBase->buildExposedFiltersGroupForm() (line 995 of ...\core\modules\views\src\Plugin\views\filter\FilterPluginBase.php).

1. Install Drupal using the standard profile
2. Navigate to admin/structure/types/manage/article/fields/add-field
3. Add a new field of type "Date", label = "Optional date field"
4. Click Save on the next two pages to accept the default values
5. Navigate to admin/structure/views/view/frontpage
6. Add the "field_optional_date_field" filter
7. Tick the "Expose this filter..." checkbox
8. (Workaround #2248223: Adding a new Views filter and making it exposed returns user back to list of filters: Click cancel and click the "Optional date field" filter to edit it again)
9. Tick the "Expose this filter..." checkbox
10. Tick the "Grouped filters" radio button
11. Navigate to admin/reports/dblog

Problem/Motivation

When #3124762: Add 'lifecycle' key to .info.yml files is committed, we will have three new non-stable module states. At present there is a visual affordance to experimental modules at admin/modules. But nothing at present for obsolete and deprecated.

Proposed resolution

Indicate the non-stable statuses in admin/modules page - add a status icon and link the description to the lifecycle link URI.
Provide additional information on the modules confirmation page- including a more information link that leads lifecycle link URI (which will be the deprecated module page on Drupal.org)

Remaining tasks

Review

User interface changes

The modules confirm page now has title 'Are you sure you want to install experimental/deprecated/experimental and deprecated modules?' (depending on what modules are being installed) and lists both experimental and deprecated modules if you attempt to enable modules of either type.

The module listing page has a warning icon and either Deprecated or Obsolete next to the module name if it is one of those statuses. This links to the lifecycle link for the module (a page on Drupal.org with more information).

API changes

Data model changes

Release notes snippet

Problem/Motivation

In testing #1876394: You have to specify $node->changed when comment.module is enabled. using

No title given

drush @drupal.d8 php-eval "\$node = entity_create('node', array('type' => 'page'));\$node->save();"

a node is created without the required title field.

Even calling $node->validate(); does not help preventing the node saved.

drush @drupal.d8 php-eval "\$node = entity_create('node', array('type' => 'page')); \$node->validate(); \$node->save();"

Bogus bundle name

Creating a node with non existing type 'bogus' is also possible. Calling $node->validate(); throws an exception.

drush @drupal.d8 php-eval "\$node = entity_create('node', array('type' => 'bogus'));\$node->save();"

drush @drupal.d8 php-eval "\$node = entity_create('node', array('type' => 'bogus')); \$node->validate(); \$node->save();"

gives

exception 'Drupal\Component\Plugin\Exception\PluginNotFoundException' with message 'The "entity:node:bogus" plugin does not exist.' in /Users/clemens/Sites/drupal/d8/www/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php:57 [error]

Proposed resolution

Make sure an entity is validated before saving it.
Make sure validate checks for required title field.

Remaining tasks

User interface changes

API changes

I'm able to create label or other fields translation for config entity, but this fields isn't translated on some pages.

For example, I can translate any display mode, but this translated data isn't shown on admin/structure/display-modes/form page. Or, I can translate any content type, but this translated data isn't shown on admin/structure/types

Steps to reproduce:

• Clean Umami install
• Go to /admin/structure/display-modes/form/manage/media.media_library/translate and translate the label to spanish
• Go to /es/admin/structure/display-modes/form

expected result:

See the Spanish label

actual result:

See the English label

Meta for triage credit, please note: you only need to add a comment for one issue that was triaged and closed, not every one.

Problem/Motivation

- Create decimal field, set precision to 10 (minimum in the UI and scale to 4
- Saving new node with value 19999.0000 succeeds (precision is 5+4 = 9).
- Saving new node with value 99999.0000 fails (same precision as above).

or

- Create decimal field, set scale to anything over 6 (need 8 to store bitcoin values for example). I used 16 as precission.
- Saving new node with value 20.12345678 fails validation while 0.1234567 succeeds.

This is because Drupal\Component\Utility\Number::validStep() returns false. Detailed investigation on this function (which is only used once in Drupal), reveals that the first argument ($value) is received as a string, but $step and $offset are floats. PHP seems to slightly mangle the $step value on the first case above from 0.0001 to 0.00010000000000000001438. Passing the step parameter as a string in the case of decimal numbers maintains the correct precision, and allows a correct approximation calculation.

Proposed resolution

Bypass weak PHP floating-point handling by passing the step as a string.

Remaining tasks

Merge. Commit. Decimals FTW!

User interface changes

None.

API changes

A new field was added to the Number FormElement, in order to decide when to use the workaround. This "#number_type" field may be useful in other cases.

Data model changes

None.

Possible workaround if you need big decimals

Disable this validation by setting the render element #step to 'any'

i.e.

$element['#step'] = 'any';

In the case of fields, you can do

function MYMODULE_form_FORM_WITH_BIG_DECIMAL_FIELD_alter (array &$form, FormStateInterface $form_state) {
  $form['field_some']['widget'][0]['value']['#step']='any';
}

And if you want to target all decimal fields:

/**
 * Prevents validation of decimal numbers
 * @see https://www.drupal.org/node/2230909
 */
function MYMODULE_field_widget_form_alter(&$element, \Drupal\Core\Form\FormStateInterface $form_state, $context) {
  $field_definition = $context['items']->getFieldDefinition();
  if ($field_definition->getType() == 'decimal') {
    $element['value']['#step'] = 'any';
  }
}

See description.
This issue created for D8.

Copy/paste from D7 issue:
The following patch allows to check if the currently logged user can access a path before outputting it (from a field). This allows to add custom "Edit" or "Delete" links in tables without having to use php.

Problem/Motivation

Backbone is on the way out #3145958: [META] Re-evaluate use of Backbone.js in core, we should figure out exactly what we rely on backbone for while reducing the size of the asset used by core.

Steps to reproduce

Proposed resolution

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Drupal 8 can send HTTP headers up-to 16kb.
https://www.drupal.org/docs/8/api/cache-api/cache-tags

Downstream systems are being updated to support this. If Drupal sends a request that exceeds 16k the downstream systems will fail with inconclusive errors. For example Varnish will return "HTTP/1.1 502 Bad Gateway." Very few people will be able to debug this sort of situation. We recently encountered a situation with a 50k header!

If a request has too many cache-tags associated with it the header size could exceed 16kb. When this occurs Drupal should provide feedback. Some possible approaches:

1. Throw a 50x error.
2. Log an error but allow the request through.

My gut is that this should be treated like an out of memory exception at PHP and be made obvious? Thoughts?

Problem/Motivation

Currently the without Twig filter doesn't allow specifying nested keys to exclude.

Proposed resolution

We can't just update without to accept an array for a nested key, because it's already been updated to accept arrays and assume they're just sequences of base-level keys in #3093577: Let Twig without() filter take both arrays and strings as arguments.
We could

• use a delimiter character (patch in #14): if present, the code would interpret them as nested keys? E.g.:
  {{ content|without('parent.child1', 'parent.child3') }}
  If '.' is a legit character in existing keys (I don't believe it is), we could find something else that's safe. E.g. '/' or whatever.

  Or we could use the wonky array syntax at the end of #5 and use '][' or equivalent.

• use a different filter for recursive values (without_nested anyone?)
• deprecate the current array behavior of without and add nested value support to D10.

Remaining tasks

Decide if it's safe to use a delimiter character, and if so which one. It looks like menu-local-tasks.html.twig for example can have periods in key names.

User interface changes

API changes

Data model changes

Release notes snippet

Original report by @taote

Under Drupal 8.6.5, after installing the module Field Layout, the filter function 'without' in the templates for my paragraphs, for example, is ignored. Once uninstalled the filter works fine again.

For example, if I put this in the twig template for a certain paragraph:

{{ content|without('field_label') }}

The field label is shown when the Field Layout module is installed.