Problem/Motivation

After spinning up media on 8.8.0 and attempting to use it w/ the CKEditor plugin, I noticed that I could insert images just fine, however, I was unable to adjust anything (view modes and/or alignment). Sometimes I could see the change reflected in CK Editor, but on save, the change would not be reflected.

Set up:

• Clean install of D8 w/ several contrib solutions
• 1 custom module (not media or ck related)
• Seven theme.

Corresponding log entries include:

Notice: Undefined index: data-view-mode in Drupal\media\Form\EditorMediaDialog->buildForm() (line 176 of /app/web/core/modules/media/src/Form/EditorMediaDialog.php) #0 /app/web/core/includes/bootstrap.inc(596): _drupal_error_handler_real(8, 'Undefined index...', '/app/web/core/m...', 176, Array) #1 /app/web/core/modules/media/src/Form/EditorMediaDialog.php(176): _drupal_error_handler(8, 'Undefined index...', '/app/web/core/m...', 176, Array) #2 [internal function]: Drupal\media\Form\EditorMediaDialog->buildForm(Array, Object(Drupal\Core\Form\FormState), Object(Drupal\editor\Entity\Editor)) #3 /app/web/core/lib/Drupal/Core/Form/FormBuilder.php(520): call_user_func_array(Array, Array) #4 /app/web/core/lib/Drupal/Core/Form/FormBuilder.php(277): Drupal\Core\Form\FormBuilder->retrieveForm('editor_media_di...', Object(Drupal\Core\Form\FormState)) #5 /app/web/core/lib/Drupal/Core/Controller/FormController.php(91): Drupal\Core\Form\FormBuilder->buildForm(Object(Drupal\media\Form\EditorMediaDialog), Object(Drupal\Core\Form\FormState)) #6 [internal function]: Drupal\Core\Controller\FormController->getContentResult(Object(Symfony\Component\HttpFoundation\Request), Object(Drupal\Core\Routing\RouteMatch)) #7 /app/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array) #8 /app/web/core/lib/Drupal/Core/Render/Renderer.php(573): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #9 /app/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) #10 /app/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) #11 /app/vendor/symfony/http-kernel/HttpKernel.php(151): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #12 /app/vendor/symfony/http-kernel/HttpKernel.php(68): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #13 /app/web/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #14 /app/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #15 /app/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(106): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #16 /app/web/core/modules/page_cache/src/StackMiddleware/PageCache.php(85): Drupal\page_cache\StackMiddleware\PageCache->pass(Object(Symfony\Component\HttpFoundation\Request), 1, true) #17 /app/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\page_cache\StackMiddleware\PageCache->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #18 /app/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(52): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #19 /app/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #20 /app/web/core/lib/Drupal/Core/DrupalKernel.php(694): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #21 /app/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #22 {main}.

Do you have the limit allowed HTML filter on?

Yes.

Does it allow ‘data-view-mode’?

Yes. Among others, here's what what I have for drupal-media .
<drupal-media id class data-entity-type data-entity-uuid data-view-mode data-align data-caption>

Proposed resolution

TBD

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

The file core/lib/Drupal/Core/Entity/Plugin/Derivative/DefaultSelectionDeriver.php defines the class Drupal\Core\Entity\Plugin\Derivative\DefaultSelectionDeriver, but the documentation block for the constructor mentions a different class name:

  /**
   * Creates an SelectionBase object.
   *
   * @param \Drupal\Core\Entity\EntityTypeManagerInterface $entity_type_manager
   *   The entity type manager.
   */
  public function __construct(EntityTypeManagerInterface $entity_type_manager) {

This mismatch is probably left over from the changes described in this change record.

This documentation block generates the API documentation for DefaultSelectionDeriver::__construct(), so I am adding the "API Documentation" issue tag.

Proposed resolution

I am not sure whether "SelectionBase" should be replaced by "DefaultSelectionDeriver" (the name of the deriver class) or "DefaultSelection" (the name of the base class). The conventional code comment for A::__construct() is "Creates a(n) A object", but maybe the convention is different for deriver classes. Look for other examples in Drupal core.

There is another code comment, later in the same file, that refers to "SelectionBase", and that one should be replaced with "DefaultSelection".

Remaining tasks

User interface changes

None, except for fixing the API documentation.

API changes

None

Data model changes

None

After upgrading to 8.8 i keep getting errors related to path_alias

Drupal\Core\Database\DatabaseExceptionWrapper: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'drupal.path_alias' doesn't exist: SELECT 1 AS expression FROM {path_alias} base_table WHERE (base_table.status = :db_condition_placeholder_0) AND (base_table.path LIKE :db_condition_placeholder_1 ESCAPE '\\') LIMIT 1 OFFSET 0; Array ( [:db_condition_placeholder_0] => 1 [:db_condition_placeholder_1] => /node% ) in Drupal\Core\Path\AliasRepository->pathHasMatchingAlias() (line 111 of core/lib/Drupal/Core/Path/AliasRepository.php).

I'm running pathauto 1.6 so that should be ok according to the release notes.

Am I missing anything?

Problem/Motivation

Messages can be added with js using Drupal.Message, see: https://www.drupal.org/node/2930536

but the markup output does not match Umami's in
https://git.drupalcode.org/project/drupal/blob/8.8.x/core/profiles/demo_...

Claro overrides the theme function: Drupal.theme.message
https://git.drupalcode.org/project/drupal/blob/8.8.x/core/themes/claro/j...

If Umami had a similar override then js messages would look more like the twig messages.

Proposed resolution

Add a Drupal.theme.message function for Umami to override core/misc/message.js and output markup that matches the twig template.

Just crash testing patches

Problem/Motivation

When adding multiple moderation state filters, the content_moderation_state table is joined multiple times unnecessarily drastically effecting performance .

One might want to add multiple moderation state filters to first exclude certain states and a second exposed filter containing the 'any' option and remaining states. This ensure the excluded states will be filtered out when the 'any' option is selected.

Proposed resolution

Reuse any relationships created when joining to the content_moderation_state table.

Remaining tasks

Reviews needed.

We are struggling with an issue where config management doesn't allow a CIM if a module has been removed.

Below is the workflow to replicate this,

We have a develop, master and tagged releases workflow. We have a stable release on our prod environment that has been running without issues, but does have some minor config changes made by the client. We are now releasing a version through our workflow that has removed a module. And we need to sync the prod changes to dev before promoting it up.

The issue we have discovered is as follows, if the module is removed in a feature branch, merged to dev and deployed(using BLT) then everything goes well and the CIM that shows this module as being deactivated runs fine.

However, we now have a need to sync prod back down to dev. When we do this, a CIM fails saying the module no longer exists. I have looked through the general areas involved in this, but wanted to reach out here, to see if I am missing something simple before going under the hood even more.

So to summarize, when syncing a database from an environment where the module exists, a CIM fails even though the config files specify this module is now to be disabled. Has anyone else dealt with this?

Problem/Motivation

Parsing .info files for dependency information is already implemented on the modules administration page. Adding support for the same dependencies in theme.info files, and implementing the same behavior on the admin/build/themes page, would allow designers building heavily customized themes to make safer assumptions about their target sites.

A theme might require the existence of imagecache to auto-generate variations of a header image. This would be a nice compromise between systems like Wordpress and Joomla!, which give themes much greater control over the functionality of the site, and Drupal's module-centric approach.

It also creates following new UX requirements and non UI, API requirements

1. Represent the list of dependent modules in themes list page. Display of missing/disabled dependent modules.
2. Extension in Drush to download and enable modules dependent on themse.

Proposed resolution

• Allow themes to add the dependencies to .info.yml files
• Show these dependencies on /admin/appearance and make it impossible to install without the requirements
• Install dependencies automatically on API level.

Original report by [eaton]

Issue Summary
Parsing .info files for dependency information is already implemented on the modules administration page. Adding support for the same dependencies in theme.info files, and implementing the same behavior on the admin/build/themes page, would allow designers building heavily customized themes to make safer assumptions about their target sites.

A theme might require the existence of imagecache to auto-generate variations of a header image. This would be a nice compromise between systems like Wordpress and Joomla!, which give themes much greater control over the functionality of the site, and Drupal's module-centric approach.

(Technically, this is not comment.module. I guess.)

Problem/Motivation

Suppose a comment is orphaned - e.g. its parent comment has somehow disappeared. Then the Drupal standard installation gives a "Fatal error: Call to a member function url() on null in /Volumes/SSD2/www/8/core/modules/rdf/rdf.module on line ..." when that comment gets loaded. Once that would be fixed, like in #16 below, more fatal errors appear when rendering a node page with an orphaned comment on it gets built(/rendered?).

Same thing happens when its associated 'commented entity' has somehow disappeared, during loading and especially building a standalone comment with orphaned entity. (Though admittedly 'building/rendering a comment without its commented entity' is usually never done.)

See the 'test-only' patch in #16 for the 'loading' part.

(So how do comments get orphaned? I don't know. But it's pretty much guaranteeed that someone, somehow, somewhere, will have orphaned comments. See #16.)

Proposed resolution

1)
Fix fatals.

2) (optional for the loading part; not considered until an experienced person says something about this)
At first sight it looks to me like invokeStorageLoadHook() will need some try...catch statements. Because it's pretty much guaranteed that contrib modules will make the same mistake as rdf.module did, and people will end up with node pages that crash while rendering.

However, since no hooks seem to wrap their calls, maybe there's a conscious decision not to do that?

Remaining tasks

* discuss need
* review

User interface changes

None.

API changes

None... but comments in CommentInterface clarify when to call the 'has referenced entity' and 'referenced entity' methods in more detail.

Data model changes

None.

Problem/Motivation

#2807785: Move global constants from *.module files into interfaces deprecated a bunch of constants but it did not actually replace their usage. We should do this. This issue handles DRUPAL_USER_TIMEZONE_DEFAULT, DRUPAL_USER_TIMEZONE_EMPTY, and DRUPAL_USER_TIMEZONE_SELECT. This is a bug because we've deprecated something but we've not completed the task and, more importantly, the old constants are in the System module and used by it but the new constants are in the User module. That does not work. The user module is dependent on the System module not the other way around.

Proposed resolution

TBD

Remaining tasks

Work out the solution

User interface changes

None

API changes

TBD

Data model changes

None

Discovered in #2466197: Staging directory should not have to be writeable.

Problem/Motivation

config_get_config_directory() just throws a \Exception when the config directory type does not exist - that's way too generic.

Proposed resolution

Create a more specific exception

Remaining tasks

User interface changes

None

API changes

A new exception - but any code catching the existing exception will work because the new exception will extend (at some point) from \Exception

Problem/Motivation

#2156401: Write install_profile value to configuration and only to settings.php if it is writeable added a BC layer to read the install profile from settings.php instead of configuration. This can be removed in 9.x.

Proposed resolution

Remove

    else {
      // If system_update_8300() has not yet run fallback to using settings.
      $install_profile = Settings::get('install_profile');
    }

And simplify code.

Remaining tasks

User interface changes

API changes

None

Data model changes

None

Problem/Motivation

Drupal 8.3 moved the revision metadata for revisionable entities into the proper database tables. This causes a problem for views config entities exported prior to the table change, as they contain incorrect table data. This has been handled in Drupal 8 by detecting and fixing revisionable entity table names on View save (or import). In Drupal 9, support for these pre-8.3.0 table names in views is removed.

Proposed resolution

remove the View::fixTableNames() method and it's usage.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

One major piece of functionality from the D7 Entity Reference module was left out entirely in #1801304: Add Entity reference field: the ability to render exposed views filters as a select list or autocomplete of available entities.

Proposed resolution

Generalize the taxonomy module's TaxonomyIndexTid plugin to be available for all entity reference fields and migrate the existing taxonomy filters to be based on the new generic filter plugin.

How to use

1. Add on an entity type / bundle an entity reference field, ex field_test_reference.
2. Create a view displaying this entity type.
3. Add a filter on the view for field_test_reference.
4. Configure the entity selection mode and the widget display mode.
5. Configure the filter behavior (ex: required, multiple, etc.)
6. Finally use the filter field for filtering the results based on the selected entity from the autocomplete or select list.

Remaining tasks

• ☑ support for content entity reference
• ☑ support for configuration entity reference
• ☑ support for content with and without bundles
• ☑ taxonomy filter rebased on generic entity reference
• ☑ settings forms to configure the filter
• ☑ display widget in select or autocomplete
• ☑ filter values based on reference view
• ☑ filter values based on bundles
• ☑ maximum filter values in select list for performance concerns
• ☑ sort for filter values when in bundle selection handler mode
• ☑ argument support for when view selection handler is used
• ☑ views configuration schema update
• ☐ existing configuration migration
• ☐ fix select option (#208, #215)
• ☑ tests

Post tasks

• ☐ conversion of the "authored by" filter to use the entity reference filter
• ☐ extract selection handler form logic in separate plugins that will specialize for rendering and validating the filter selection config form
• ☐ caching of the value form?
• ☐ documentation updates

User interface

Known issues

• CANNOT REPRODUCE ATM sometimes when switching between widget it gets stuck on the previous selected one
• FIXED when switching between the widget types the previous value is left in the exposed form and it's incompatible with the other widget type
• FIXED triggering ajax requests on the extra options form right after adding the filter brings you back to the add handler form fixed

API changes

None.

Coming from #2742585-102: Deprecate dangerous assertTrue/False() compatibility overrides in PHPUnit Kernel, Functional and FunctionalJavascript tests:

@mondrake

How about deprecating also the assertEquals override in KernelTestBase and BrowserTestBase, so forcing tests to call explicitly castSafeStrings when needed?

@alexpott

the gain with it is less obvious.One thing that is interesting is instead of the assertEquals hack we could register a Comparator to compare MarkupInterface objects...

Problem/Motivation

Currently rendering of canonical taxonomy term link for forum vocabulary is broken and have no test coverage.

To be more consistent with the object-oriented architecture need to implement Drupal\Core\Entity\EntityInterface::uri() method and drop taxonomy_term_uri() function and clean-up Term annotation uri_callback.

Proposed resolution

Implement a path processor outbound service to make this work again and add test. Remove taxonomy_term_uri() and forum_uri() functions as useless because entity templates are takes precedence.

Remaining tasks

User interface changes

API changes

Original report by @andypost

Part of #2010184: [meta] convert ‘uri_callback’ entities param to EntityInterface::uri() method

Needs to implement Plugin\Entity\Term.php uri() method and drop taxonomy_term_uri() function replacing it's calls to $term->uri() and clean-up Term annotation uri_callback

Problem/Motivation

The admin toolbar applies a padding to the top of the body element that should be equal to its height.

However, with the following scenarios, the height calculation is incorrect.

1. Settings Tray is enabled and is accessible by the user, the page does not contain any contextual links (?) and the front-end (?) theme uses Bootstrap CSS
2. The displayed toolbar tabs break into multiple lines.

Proposed resolution

Refactor Drupal.toolbar.ToolbarVisualView.updateToolbarHeight() to fix the height calculation issues.

Remaining tasks

* Test
* Patch
* Get a review

User interface changes

Toolbar does not overlap page content anymore.

API changes

Nothing.

Data model changes

Nothing.

Original report

The admin toolbar applies a padding to the top of the body element that should be equal to its height.

However in the following scenario the height calculation is incorrect.

Settings Tray module adds a tab to the toolbar with a class of hidden. It's the first element inside #toolbar-bar.

Bootstrap css defines hidden as display: none !important;

In ToolbarVisualView.js the updateToolbarHeight method sets toolbarTabOuterHeight by getting the outerHeight of the first .toolbar-tab

Because the first tab is hidden (and crucially, because of bootstrap it has !important), the outerHeight is 0px and thus the body receives a top padding of 0px.

I think the height calculation needs to do something like check the height of tallest tab, not just first one. Or perhaps just ensure the tab it selects to get the height isn't hidden/

Here is an example of calculating the height on an element that is display: none!important.
https://jsfiddle.net/marmite/d9oma2e3/7/

The jQuery documentation for outerHeight says:
The value reported by .outerHeight() is not guaranteed to be accurate when the element or its parent is hidden. To get an accurate value, ensure the element is visible before using .outerHeight(). jQuery will attempt to temporarily show and then re-hide an element in order to measure its dimensions, but this is unreliable and (even when accurate) can significantly impact page performance. This show-and-rehide measurement feature may be removed in a future version of jQuery.

Problem/Motivation

core/modules/update/update.compare.inc contains 1 method, update_process_project_info() that is called from outside of the file.

update_calculate_project_update_status() is over 300 lines long and its docblock is over 50 lines. It very hard to follow what this function is doing.

Once #3094304: Create tests that cover contrib non-full releases and contrib patch versions is committed we will actually have decent test coverage for this functionality

#3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates will update to the new XML but retain the current functionality

Proposed resolution

We should create a new class that encapsulates the 3 methods in this file exposing 1 public method. The class should refactor
update_calculate_project_update_status() into smaller methods that can be more easily understood.

This should be done after #3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

#3074993: Use "current" in update URLs instead of CORE_COMPATIBILITY to retrieve all future updates we are switching to a new XML feed from drupal.org that provides supported_branches instead of supported_majors and some other metadata changes.

#3074993 is changing to this new XML feed but keeping the current functionality based on majors. For instances if:

• The site's current core version is 8.7.0
• The latest 8.7.x release is 8.7.10
• The latest 8.8.x release is 8.8.0
• the project XML has <supported_branches>8.7.,8.8.x</supported_branches>

currently 8.8.0 will be the recommended release even 8.7.10 is still release on a supported branch and doesn't require jumping to the next minor version of core which can be disruptive.(this will be the same after (#30749930)

Currently this does not affect contrib because support branches are the same as minors. this will change when #2681459: Add support for optional contrib semver-ish tags and releases to d.o is done.

Proposed resolution

The update module should recommend the latest release for the current branch if it is still supported. It should also indicate there is another release on the next supported branch.

Remaining tasks

Determine if this is the desired functionality

User interface changes

User shown updates by supported branch

API changes

Data model changes

Release notes snippet

When creating new content, only the title is displayed.
Already uninstalled modules, which could cause this problem.
Body is turned on in content type display.
When displaying Teasers with views, you can see the content.
When choosing Default for the view, only title is been shown.
When I click the preview button, before saving, I can see the content on the page.

Website fistly encountered a "missing filter-plugin: Filter_Null error" on the logs page. This problem was solved by opening php filter and saving it. Now no error is logged...

Do you have any ideas for the solving problem? Problem started after updrading from 8.7.0 to 8.8.0.