Problem/Motivation

Menu drag and drop can exceed either suhoson max_* or PHP's own max_input_vars, resulting in changes from the form silently disappearing.

Since there is no PHP error, there's no way for the user to know that their form submission has been lost except for checking the form again.

Tabledrag has hidden select lists for weight, it's possible this is hitting limits if a lot of them are shown on the page.

Proposed resolution

The select lists only show for users without JavaScript, or if 'show weight's is clicked, should we change them to textfields instead?

Remaining tasks

User interface changes

API changes

Data model changes

So I am a long time user of D6 and recently started to create a new website using D8. I'm completely frustrated by the menu system as what should be a fairly straightforward process, is not. Either I am missing something or there is a critical bug out there. All I am trying to do is create a submenu item in the Primary Menu.

I have the default "home" menu item listed there and I have 2 other menu items called "My Items" and "My Coordinations" which are created via Views to the view page.

I would like to simply add a menu item called "Add Item" which is linked to /node/add/item.

I have created this menu item manually through the "add link" button on http://sitename.com/admin/structure/menu/manage/main.

It appears fine and works. But once I move the menu item by dragging it to become the submenu item of "My Items" and click the save button. The page refreshes with the menu item back on the main level with all menus and now (disabled). WHY!?!?!?

Also, another issue is now that it's disabled, if I try to click the enable checkbox and hit save from the main (primary) menu edit page. It will NOT enable after save. It will just go back to being disabled (i.e. NO CHANGE). I have found that I need to actually click the edit button for that menu item and then on the menu item's edit page, I can click the checkbox next to "Enabled" with sub text "A flag for whether the link should be enabled in menus or hidden.". Then after I click the save button on that page, it will go back to the main menu edit page and show it now enabled. Why do I need to drill into it to enable it, why does the enable checkbox on the main edit page of the Main (Primary) menu not work!?!?

Then again, if I now drag it under the "My Items" menu again to make it a submenu item (i.e. it shows as indented under My Items), and click save, it will again move it out from under My Items and disable it again.

What the heck is going on?!!?

Problem/Motivation

Currently, we have utility classes defined in System module. These utility classes, such as visually-hidden are currently usable from other modules as well as themes. However, core libraries that are not in any modules or themes shouldn't add dependencies on utility classes defined in System module because System module is higher level code than the libraries.

Proposed resolution

Move essential utility classes into a new library that is located in core (not inside modules or themes). Add dependency from libraries requiring these to the newly created library, so that the dependency has been defined explicitly.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

There's no handy way to mark some rows as disabled for selection in a tableselect element.

Proposed resolution

Allow to pass an optional #disabled property in option. When an option has #disabled === TRUE, the corresponding checkbox will be disabled.

Workaround

Without this change there's still possible to disable certain rows:

1. Add an additional #process callback to the tableselect element. Note that you should add also the original processor:
   

   $form['my_table'] = [
     '#type' => 'tableselect',
     ...
     '#process' => [
       // This is the original #process callback.
       [Tableselect::class, 'processTableselect'],
       // Additional #process callback.
       [static::class, 'processDisabledRows'],
     ],
     ...
   ];
   

2. The additional #process callback:
   

   public static function processDisabledRows(array &$element): array {
     foreach (Element::children($element) as $key) {
       $element[$key]['#disabled'] = isset($element['#options'][$key]['#disabled']) ? $element['#options'][$key]['#disabled'] : FALSE;
     }
     return $element;
   }
   

3. Set the #disabled property to TRUE on the rows that you want to disable:
   

   $form['my_table'] = [
     '#type' => 'tableselect',
     ...
     '#options' => [
       'row1' => [
         'col1' => '1.1',
         'col2' => '1.2',
       ],
       // This row is disabled.
       'row2' => [
         'col1' => '2.1',
         'col2' => '2.2',
         '#disabled' => TRUE,
       ],
     ],
     ...
   ];
   

Remaining tasks

None.

User interface changes

API changes

A tableselect element can have disabled options.

Data model changes

None.

Release notes snippet

By adding a #disabled property set to TRUE, it's possible to prevent used by selecting certain options in a tableselect form element.

Initial report

Currently it is not possible to disable an option on a tableselect list.
Can we allow a Tableselect checkbox to be disabled on a specific option, like it currently is possible with the attribute and ajax parameters?

Problem/Motivation

Problem

• When #states is attached to a form element that contains #markup the following notice occurs:
  

  Notice: Undefined index: #type in drupal_process_states() (line 583 of core/includes/common.inc).

Cause

• This happens because a #markup element does not require the #type to be set.

Proposed resolution

1. Fix the PHP notice.
2. Add a regression (kernel) test to ensure that this bug does not reappear in the future.

Notes

• There are no PHP/backend tests for #states right now, because the "functionality" on the PHP side is in essence just a json_encode(), so nothing worth to test.

Remaining tasks

• Make sure patch applies to 8.5.x and 8.6.x as well.
• Write an unit (kernel) test to ensure that the bug does not reappear in the future.

User interface changes

No.

API changes

No.

Data model changes

No

When there is an uncaught exception, Drupal 8 displays a simple dump of the exception.

Although the page is served as 'Content-Type' = 'text/plain', it contains HTML. It looks better to me when I change the code (in FinalExceptionSubscriber.php) to serve as 'text/html'. See attached images.

Setting to "Minor" as the message would never be shown in production. Nevertheless, when debugging it's tedious to try to read text that contains HTML tags.

I asked for help on Drupal Answers. @4k4 suggested that the problem was potentially related to #2853300: Standardize fatal error/exception handling: backtrace for all formats, not just HTML, and that the "obvious" fix of changing the content-type would revert that issue.

Sometimes developers will have invalid YAML files. In my case, I botched a .routing.yml file, but edited many more. Commands like drush cr then correctly say "Unable to parse at line xyz", but not which file.

This issue suggests to add the affected file to the exception thrown by YamlDiscovery. For orientation: The YamlDiscovery is part of the Discovery component.

Problem/Motivation

Sometimes you want to force content-editors to provide a summary. Use case would include

• You're showing it in a teaser display mode
• You're using it for the metatag description
• You're using it for search results

The summary input is easy to miss, but is really useful as it avoids needing a second text field for teaser text.

Proposed resolution

Setup options for the "Text area with a summary" widget to allow for the Summary field to be "Shown by default" (instead of collapsed with js) and a field level setting to make the summary value "Required".

Remaining tasks

• manual testing (See contributor task doc for instructions on manual testing: http://drupal.org/node/1489010) Especially see #42 on for what combinations to test.
• Reviews

User interface changes

New checkbox on text with summary widget and text with summary field.

API changes

No api changes.

Related Issues

• #1888744: text.module missing text_library_info() - does not explicitly declare js dependencies
• #626546-62: The body field on the Basic Page content type should not allow a summary to be input
• ?

See #2848161: [meta] Replace calls to deprecated db_*() wrappers.

Replace all usages of db_query in core, except in code that is testing db_query.

Steps to create scripted patch:

• Script to do the majority of the work
  

  # Replace the occurrences in code.
  find ./core/lib -type f -exec sed -i -r 's/db_query\(/Database::getConnection\()->query\(/g;' {} \;
  find ./core/tests -type f -not -path "./core/tests/Drupal/KernelTests/Core/Database/*" -exec sed -i -r 's/db_query\(/Database::getConnection\()->query\(/g;' {} \;
  find ./core/tests/Drupal/KernelTests/Core/Database -type f -not -path "./core/tests/Drupal/KernelTests/Core/Database/SchemaTest.php" -not -path "./core/tests/Drupal/KernelTests/Core/Database/QueryTest.php" -exec sed -i -r 's/db_query\(/$this->connection->query\(/g;' {} \;
  find ./core/modules -type f -exec sed -i -r 's/db_query\(/Database::getConnection\()->query\(/g;' {} \;
  find ./core/tests/Drupal/KernelTests/Core/Database/LoggingTest.php -type f -exec sed -i -r "s/call_user_func_array\('db_query'/call_user_func_array\([\$this->connection, 'query']/g;" {} \;
  find ./core/tests/Drupal/KernelTests/Core/Database/SchemaTest.php -type f -exec sed -i -r 's/db_query\(/Database::getConnection\()->query\(/g;' {} \;
  find ./core/includes/form.inc -type f -exec sed -i -r 's/db_query\(/Database::getConnection\()->query\(/g;' {} \;
  find ./core/scripts/ -type f -exec sed -i -r 's/db_query\(/\\Drupal::database\()->query\(/g;' {} \;
  # Start using \Drupal::database() or inject service
  find ./core/modules/tracker -type f -exec sed -i -r 's/Database::getConnection\(/\\Drupal::database\(/g;' {} \;
  

• The files that requires to manually add use Drupal\Core\Database\Database; row. See interdiff at #26
• Fix the replacements in the comments. See interdiff #27

Problem/Motivation

Since testbot only tests issues with the vendor versions in the composer lock file, we need a way to test against recent vendor updates in order to catch issues like #3039408: Updating twig/twig to v1.38.0 or v1.38.1 causes fatal error and #3039584: The "Symfony\Bridge\PsrHttpMessage\Factory\DiactorosFactory" class is deprecated since symfony/psr-http-message-bridge 1.2, use PsrHttpFactory instead. and #3045349: Lazy started sessions with session data are not saved with symfony/http-foundation 3.4.24. If we enable Symfony 4 support in 8.8, we will need a way to test against that as well

Proposed resolution

Keep an RTBC issue with a patch to run composer update against the codebase prior to running the test suite.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

When a site has lots of blocks that have context definitions, loading the blocks from cache (and not necessarily doing anything with them) is expensive. It's a cost that is paid any time the block list is accessed from cache. This is because in __wakeup when blocks are being deserialized, a compatibility layer is instantiated.

Proposed resolution

Instead load the compatibility layer on demand when you try to actually do something with a given block plugin.

Before:

After:

Comparison:

Remaining tasks

Commit!

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

Problem

As it stands, the menu system checks all menu paths pointing to internal links (ie, node/add or user/logout) upon submission to verify:

1. The path exists in the menu system.
2. The user has the proper permissions to access that path.

Furthermore, when a menu is being rendered, paths that the current user does not have access to are not rendered in the menu.

The problem begins when the user creates a menu item using an absolute URL pointing to an internal system path. For example, with Clean URLs, the user could create a menu item using the path 'http://www.example.com/admin'.

This avoids all the access checks that are made when the path is entered as an internal path.

The other problem is that the site is no longer portable as links will break when migrated between Dev, Staging and Prod environments (or the domain is changed entirely).

This has happened on several client's sites when they add menu items by surfing to the page they want to add, copying the URL from the address bar, then pasting into the menu form.

Proposed solution

I would suggest that when the menu system parses absolute URLs, it should check:

1. Does the domain in the URL match the domain of the site?
2. If so, is the path in the Drupal menu system?
3. Convert the absolute URL to a relative one.
4. If so, apply all access checks and controls similar to if the URL was entered as an internal path. This shouldn't be necessary because core now treats the URL as relative.

I am putting this on my list of 'bugs to fix'. However, I can't guarantee I will get around to it soon. If someone wants to take a crack at it, please, take ownership and tackle it. Chances are you are more familiar with the menu system than I am anyways!

Problem/Motivation

I ran an update from 8.7 alpha1 to beta1 and encountered the following fatal:

[notice] Update started: layout_builder_post_update_make_layout_untranslatable
Error: Call to a member function isTranslatable() on null in /data/app/core/modules/layout_builder/layout_builder.post_update.php on line 205 #0 /data/vendor/drush/drush/src/Commands/core/UpdateDBCommands.php(260): layout_builder_post_update_make_layout_untranslatable(Array)
...
Error: Call to a member function isTranslatable() on null in layout_builder_post_update_make_layout_untranslatable() (line 205 of /data/app/core/modules/layout_builder/layout_builder.post_update.php).

The field map reflects the layout_builder__layout field existing in a bundle that was introduced and deleted early in the development cycle. The bundle isn't listed for any of the other fields.

Proposed resolution

• Be more defensive in layout_builder_post_update_make_layout_untranslatable to protect against incorrect field maps.
• Figure out why the field isn't updated in the field map when a bundle is deleted.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

(Security team told me to post this in a public)

This applies to most or a lot of Drupal 7 sites in one way or another.

Steps to reproduce (on drupal.org):

1. Open an incognito browser window (e.g. with Chromium)
2. Visit https://register.drupal.org/user/register
3. Right-click the form, "inspect element".
4. Edit the form as html. Insert
   <input name="mollom" type="hidden" value="xxx" /> at the end of the form. (*)
5. Submit the form.

Result on drupal.org:
5xx Server Error

Result on a local test site, with error reporting enabled:
Fatal error: Cannot create references to/from string offsets nor overloaded objects in [..]/includes/common.inc on line [..]

This is in drupal_array_set_nested_value(), called from _form_builder_handle_input_element().

Imo, a site should be able to handle arbitrary data sent via POST. It should not crash if the data has a non-expected format.

(*) More generally:
One simply needs any form element that usually expects an array, and send it a string instead. Interestingly, "pass" does not work, but this might be a special case.
More examples can be found in the admin backend, e.g. on admin/config/content/formats.
All the other elements on the registration form expect string values, so the registration form seems to be ok without Mollom.
Still, it is likely that there are other forms with nested array values.

The error itself is not new.
https://startpage.com/do/search?q=site%3Adrupal.org%2Fnode+%22Cannot+cre...
But other issues so far always see it as a bug in a specific component.
Instead, I think it is generally wrong to trust data from the client.

Behavior change in PHP 7.1

There is one case that triggers an error in PHP 7.1, but did not trigger an error in PHP 5.6.
This happens if there is an empty string in the array structure.
See comment #5.

This behavior changed from PHP 5.6 / 7.0 to PHP 7.1.
https://3v4l.org/dDDi0 - check "eol versions".

For non-empty strings this was always broken.

Empty strings were treated the same as NULL in PHP 5.

Possible causes

Causes:
- Conflicting form elements defined in the appilcation. This could be due to a bug in a module, due to incompatible modules used in combination, or due to misconfiguration by a site builder.
- Misbehaving client-side javascript. Again this could be due to bugs, incompatibilities or misconfiguration.
- Intentional manipulation by a visitor/user, bot or malware, or by a misbehaving browser/extension or other client software.

Who might be at fault?
- Contrib developer
- Site builder or site developer
- The visitor

Solution, part I

Make the behavior in PHP 7.1 consistent with the behavior in earlier PHP versions.
Improve error reporting.
The patch in #7 does that.

Solution, part II

Rethink what should happen in case of manipulated POST data.

NodeRevisionDeleteForm has a description: "Provides a form for reverting a node revision." which is not correct, as such functionality is provided by the NodeRevisionRevertForm.

Problem/Motivation

#2851635: DefaultSingleLazyPluginCollection retains stale instance IDs shows that base plugin classes should all merge default configuration in the same way. We should supply a trait to make it easy to correctly implement \Drupal\Component\Plugin\ConfigurableInterface.

Proposed resolution

Add new trait and use it where appropriate in core.

Remaining tasks

User interface changes

None

API changes

New trait

Data model changes

None

Problem/Motivation

This is a D7 follow-up to #2886609: Migrate translations for D6 i18n taxonomy 'localized' terms

Drupal 7 i18n_taxonomy provides two different multilang concepts: 'localized terms' and 'per language terms'.

The scope of this issue is to migrate the translations of the D7 'localized' terms to D8.

Proposed resolution

The scope of this issue is to migrate D7 taxonomy term translations.

D7 vocabulary translation settings are handled in #2979970: Migrate D7 vocabulary language settings

References between translated nodes and translated terms are handled in #3035392: Migrate taxonomy term references for D7 Node translations

Remaining tasks

Postponed on #2886609: Migrate translations for D6 i18n taxonomy 'localized' terms
1. Write a patch.
2. Test manually and review the patch.
3. Commit

User interface changes

N/A

API changes

N/A

Data model changes

N/A

I created the private file system as detailed in all the documentation. When I upload my custom logo file, it uploads to the private file directory correctly. However, I get an error message on my reports page....warning page not found. D7 doesn't seem to be able to find it. When I set the file system to public and upload my logo, it works.

I have tried this with just D7 installed and no contrib modules.

I am running this in a dev environment on my Mac OS 10.6.6 on Mamp Pro 1.9.4, Apache, Mysql 5.1.44, PHP 5.3.2

I have included screen shots.

Hello guys,

In the user registration settings we can choose between those options :
- admins only
- visitors
- visitors, but the approval of an administrator is required

I am wondering why we don't have a 4th option "users manager only" and the opportunity to tell which role is the "users manager".

Actually I am building a website that I am gonna deliver to an association.
I'd like them to manage the users creation but certainly not the content types settings and other settings that I (administrator) should be the only one to manage.
And guess what ? If I choose "only admins" and choose a role to be "administrator" then that role is way to much powerfull cause he has every right on the website...

What do you guys think about that?

Problem/Motivation

In the comment module's help section on /admin/help/comment, the following paragraph

For more information, see the online documentation for the Comment module.

contains a link to the Drupal 7 handbook instead of the Drupal 8 handbook.

Proposed resolution

Update the link to point to https://www.drupal.org/docs/8/core/modules/comment-module

Problem/Motivation

Currently, when rendering the book tree, an in_active_trail value is included in the book tree for each item; however, no is_active value is included. As a result, it's not possible to know if a particular item is active. This is useful for applying active states in book navigation.

Proposed resolution

When rending items in the book tree, check if the item belongs to the current page. Make this information available in the template layer.

Remaining tasks

Submit patch

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

None.