Problem/Motivation

CKEditor 4.5 added HTML5 drag-and-drop file uploads. This can be done by using the uploadwidget.

Proposed resolution

We should support this feature in Drupal 8 core too and add it in a minor release by creating a custom plugin which handles drag-and-drop image uploads.

Remaining tasks

- Add uploadwidget
- Create the new plugin which should automatically open the image dialog when and image is dragged and dropped on the CKEditor textarea
- Usability testing

User interface changes

TBD

API changes

None.

Data model changes

None.

Hello all, it’s time for the weekly migration initiative 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 over chat.
➤ 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 here.
➤*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.

0️⃣ Who is here today? Anything interesting to share over the new year?

1️⃣ What do we need to talk about, other than the NR issues?

2️⃣ If no Drupal 8 equivalent filter is found during migration, drop transformation-only filters, so that body fields show up

3️⃣ Cannot update some file properties during migrate update

5️⃣ MigrateExecutableMemoryExceededTest has mismatched argument type mock expectations (and fails in PHPUnit8)

6️⃣ Create a way to declare a core migration yml file as deprecated

7️⃣ system_maintenance migrations uses incorrect maintenance mode variable in Drupal 7 migrations

8️⃣ Migrate D6 and D7 node revision translations to D8

9️⃣ getHighestId() should be able to use any integer destination id

🔟 Migration memory management thoughts and issues. (edited) 

Participants:

heddn, Nick Wilde (he/him) - DC 2020 DevOps Session Team, webchick, wimleers (he/him), gabesullice, mikelutz, chriscalip, kevinquillen

Problem/Motivation

In July 2018, PHP-FIG accepted PSR-17, providing a standard interface to http message factories. The interface for this standard requires PHP 7.0, and most implementations require PHP 7.1. The symfony/psr-http-message-bridge provides a wrapper interface around the message factory, and can be used with our current DiactorosFactory or with PSR-17 compliant factories. Beginning with psr-http-message-bridge v1.2, the non-PSR-17 Diactoros factory is deprecated, in favor of the PsrHttpFactory, which uses PSR-17 factories under the hood.

Proposed resolution

zend-framework/zend-diactoros provides a set of PSR-17 standard factories beginning with version 2.0, which can be plugged into the symfony PsrHttpFactory wrapper, however version 2.0 requires PHP 7.1. We should consider switching when we also support a PHP minimum version of 7.1. Because the symfony wrappers have the same interface, there are no BC concerns, and we could do this in Drupal 8.9 if we choose to support a minimum PHP version of 7.1 in Drupal 8.9. Alternatively this could be targeted for Drupal 9.0

A test of this swapout was done in #3039584: The "Symfony\Bridge\PsrHttpMessage\Factory\DiactorosFactory" class is deprecated since symfony/psr-http-message-bridge 1.2, use PsrHttpFactory instead. and it was found that a direct swap resulted in passed tests with minimal code adjustments

Remaining tasks

Update the vender versions,
Add services for the individual factories
Replace the current factory service with the new service, and pass in the individual factory service
Remove deprecation suppression messages regarding DiactorosFactory being deprecated in symfony/psr-http-message-bridge v1.2

User interface changes

none

API changes

Our message factory would use PSR-17 factories under the hood to build our PSR-7 messages

Data model changes

none

Release notes snippet

Drupal now uses PSR-17 compliant message factories to create PSR-7 Requests and Responses.

Problem/Motivation

Drupal 8 ships with Guzzle.
As such it is somehow enforcing a particular library to be used for HTTP communication.

Ideally, we would not use a particular library. The obvious choice is a library implementing PSR-18 (announced in https://medium.com/php-fig/psr-18-the-php-standard-for-http-clients-3254..., includes rationale).

Note that we are also concerned about long-term support of Guzzle, but our concerns there have been addressed by Guzzle maintainers over at https://github.com/guzzle/guzzle/issues/2358.

Proposed resolution

Adopt a more abstract library for Drupal 9, and specifically a PSR-18 implementation since that's what the PHP ecosystem is adopting, to avoid tying our HTTP requests to Guzzle's implementation details.

Proposals:

1. ❌ Code Drupal against a PSR-18 service, so anything that implements it or have an adapter can be used. (initial patch in #11) Per #18, adopting PSR-18 while dropping Guzzle would be a feature regression (no more async support).
2. ✅ Existing alternative: http://docs.php-http.org/en/latest/'s php-http/guzzle6-adapter version 2.x. This allows all existing Drupal code in core and contrib to continue to work as-is, and merely exposes a PSR-18 adapter on top of Guzzle, for those cases where async requests are not needed. However, this requires PHP 7.1.
3. ❌ symfony/http-client (first proposed in #3): Same problem as far as its PSR-18 compliance, because PSR-18 does not support async. Just like Guzzle, it supports async requests, but switching to it would not bring any benefit: Drupal's existing use of Guzzle already offers async requests, and Guzzle's support will cover the entire D9 cycle, per https://github.com/guzzle/guzzle/issues/2358. So the only result of switching to this would be backwards compatibility breaks.

In other words: despite our intent to adopt a PSR-18 implementation, we cannot, because PSR-18 does not support async requests. PSR-18 will be extended in a future PSR with support for async requests, but that in turn requires a yet-to-be-ratified PSR for promises. (For more nuance, see #18.)

The current consensus per

• @Wim Leers in #18
• @larowlan in #21
• @xjm in #23
• @alexpott in #3047294-13: Switch to symfony/http-client

is to therefore not adopt a PSR-18-centric approach, but rather to layer PSR-18 on top of our existing more feature-rich client. This minimizes disruption while allowing Drupal developers to get on the PSR-18 standardization path.

Remaining tasks

1. Discussion.
2. Consensus.
3. Decide whether to adopt php-http/guzzle6-adapter 1.1.1 today or wait for Drupal to require PHP >=7.1 and then adopt version 2.0.1 We need version 2.0.1, see #27.
4. Patch
5. RTBC

User interface changes

None expected.

API changes

API addition: PSR-18 support layered on top of our existing Guzzle HTTP client. Since it is just an extra layer, it is backwards compatible.

Data model changes

None.

Release notes snippet

PSR-18 support added. It is recommended to change your Drupal code performing HTTP requests from Guzzle to PSR-18, if you're not relying on Guzzle-specific capabilities such as asynchronous requests.

After updading a Drupal site from 8.6.16 to 8.7.1 (PostgreSQL 9.6.13 , Nginx) I get this error in almost every operation (creating a view , installing a module, importing feeds, ....) with diferent plugins

Drupal\Component\Plugin\Exception\PluginNotFoundException: The "{whatever}" plugin does not exist.
Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan,[...]
in Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() (line 53 de /"
"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php).

I use the drupal-project composer template so my update process was:

composer update --with-dependencies webflo/drupal-core-require-dev drupal/* "symfony/*" -d /<path/to/site> --no-interaction ;
cd /<path/to/site>
drush updb
drush cron
drush cr

It was not successfull, so I do this:

rm -rf vendor/*
composer update

and run again previous commands which It worked.

I though that I could be a problem with PHP version so I update from PHP 7.0 to PHP 7.3, but the error still remains.
I also thought that it could be related with a feeds module installation so delete all feeds content, feeds types, etc .. and unistall and reinstall the module several times (also run drush devel-entity-updates because drupal status report warned of a feeds field that needed to be deleted)

After see that the problem was related with multiples plugins I start looking for a more generic issue (config?, permissions?, ...) but I don't find cause/solution.

EDIT 1

Looking for a stack trace I try using drupal console:

drupal site:mode dev -v

and get this:

In DiscoveryTrait.php line 53:

  [Drupal\Component\Plugin\Exception\PluginNotFoundException]                                                                                                                                               
  The "system.performance" plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan, language_reference, language, map  
  , binary, timestamp, list, datetime_iso8601, uri, integer, duration_iso8601, email, field_item:comment, field_item:datetime, field_item:daterange, field_item:file_uri, field_item:file, field_item:font  
  awesome_icon, field_item:image, field_item:link, field_item:list_integer, field_item:list_float, field_item:list_string, field_item:path, field_item:telephone, field_item:text, field_item:text_long, f  
  ield_item:text_with_summary, field_item:time_range, field_item:time, field_item:webform, field_item:email, field_item:uri, field_item:entity_reference, field_item:uuid, field_item:timestamp, field_ite  
  m:string_long, field_item:language, field_item:password, field_item:changed, field_item:float, field_item:decimal, field_item:map, field_item:boolean, field_item:integer, field_item:created, field_ite  
  m:string, entity, entity:block, entity:block_content_type, entity:block_content, entity:block_content:basic, entity:captcha_point, entity:comment, entity:comment:comment_forum, entity:comment_type, en  
  tity:contact_form, entity:contact_message, entity:contact_message:feedback, entity:contact_message:personal, entity:editor, entity:field_config, entity:field_storage_config, entity:file, entity:filter  
  _format, entity:image_style, entity:imce_profile, entity:language_content_settings, entity:configurable_language, entity:media_type, entity:media, entity:media:audio, entity:media:file, entity:media:i  
  mage, entity:media:remote_video, entity:media:video, entity:node_type, entity:node,[...], entity:node:page, entity:node:position, entity:rdf_mapping, entity:responsive_image_style, entity:rest_resource_config, entity:rules_reaction_rule, entity:rules_component, entity:s  
  earch_page, entity:shortcut_set, entity:shortcut, entity:shortcut:default, entity:action, entity:menu, entity:taxonomy_vocabulary, entity:taxonomy_term, entity:taxonomy_term:badge_type, entity:taxonom  
  y_term:categories, entity:taxonomy_term:forums, entity:taxonomy_term:materials, entity:taxonomy_term:nivel, entity:taxonomy_term:tags, entity:toolbar_menu_element, entity:tour, entity:user, entity:use  
  r_role, entity:webform_options, entity:webform, entity:webform_submission, [..], entity:menu_link_content, entity:pathauto_pattern, entity  
  :view, entity:base_field_override, entity:entity_view_mode, entity:entity_view_display, entity:entity_form_mode, entity:entity_form_display, entity:date_format, entity_reference

Exception trace:
 () at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php:53
 Drupal\Core\Plugin\DefaultPluginManager->doGetDefinition() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Component/Plugin/Discovery/DiscoveryCachedTrait.php:25
 Drupal\Core\Plugin\DefaultPluginManager->getDefinition() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/DataDefinition.php:195
 Drupal\Core\TypedData\DataDefinition->getClass() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/TypedDataManager.php:86
 Drupal\Core\TypedData\TypedDataManager->createInstance() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/TypedData/TypedDataManager.php:103
 Drupal\Core\TypedData\TypedDataManager->create() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/TypedConfigManager.php:394
 Drupal\Core\Config\TypedConfigManager->createFromNameAndData() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/StorableConfigBase.php:134
 Drupal\Core\Config\StorableConfigBase->getSchemaWrapper() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/StorableConfigBase.php:179
 Drupal\Core\Config\StorableConfigBase->castValue() at /home/"<user>"/www/"<site>"/web/core/lib/Drupal/Core/Config/Config.php:212
 Drupal\Core\Config\Config->save() at /home/"<user>"/www/"<site>"/vendor/drupal/console/src/Command/Site/ModeCommand.php:150
 Drupal\Console\Command\Site\ModeCommand->overrideConfigurations() at /home/"<user>"/www/"<site>"/vendor/drupal/console/src/Command/Site/ModeCommand.php:87
 Drupal\Console\Command\Site\ModeCommand->execute() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Command/Command.php:255
 Symfony\Component\Console\Command\Command->run() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Application.php:987
 Symfony\Component\Console\Application->doRunCommand() at /home/"<user>"/www/"<site>"/vendor/symfony/console/Application.php:255
 Symfony\Component\Console\Application->doRun() at /home/"<user>"/www/"<site>"/vendor/drupal/console-core/src/Application.php:184

EDIT 2

looking at the database I found two tables from feeds module (supposed to be uninstalled)

feeds_feed feeds_subscription

running drupal console commnand drupal debug:module feeds appears as the only module uninstalled with a schema version defined

ID     Name   Package  version      schema version  status      origin
...
feeds  Feeds  Feeds  8.x-3.0-alpha5    8001         Uninstalled no core
...

EDIT 3

After enable debugging (https://drupal.stackexchange.com/questions/127182/how-do-i-enable-develo...)

I got new clues about the error ( trying to create a view) but my lack of drupal core knowledge stops me from understanding where final cause is:

</br></br><em class="placeholder">Drupal\Component\Plugin\Exception\PluginNotFoundException</em>: The &quot;views.view.*&quot; plugin does not exist. Valid plugin IDs for Drupal\Core\TypedData\TypedDataManager are: filter_format, any, float, string, boolean, timespan, [...], entity:entity_form_display, entity:date_format, entity_reference in <em class="placeholder">Drupal\Core\Plugin\DefaultPluginManager-&gt;doGetDefinition()</em> (line <em class="placeholder">53</em> of <em class="placeholder">core/lib/Drupal/Component/Plugin/Discovery/DiscoveryTrait.php</em>). <pre class="backtrace">Drupal\Core\Plugin\DefaultPluginManager-&gt;getDefinition(&#039;views.view.*&#039;) (Line: 195)
Drupal\Core\TypedData\DataDefinition-&gt;getClass() (Line: 86)
Drupal\Core\TypedData\TypedDataManager-&gt;createInstance(&#039;views.view.*&#039;, Array) (Line: 103)
Drupal\Core\TypedData\TypedDataManager-&gt;create(Object, Array) (Line: 394)
Drupal\Core\Config\TypedConfigManager-&gt;createFromNameAndData(&#039;views.view.test2&#039;, Array) (Line: 134)
Drupal\Core\Config\StorableConfigBase-&gt;getSchemaWrapper() (Line: 179)
Drupal\Core\Config\StorableConfigBase-&gt;castValue(&#039;uuid&#039;, &#039;c2f6326b-a77f-4f1e-9698-cb96154252cb&#039;) (Line: 212)
Drupal\Core\Config\Config-&gt;save() (Line: 284)
Drupal\Core\Config\Entity\ConfigEntityStorage-&gt;doSave(&#039;test2&#039;, Object) (Line: 449)
Drupal\Core\Entity\EntityStorageBase-&gt;save(Object) (Line: 263)
Drupal\Core\Config\Entity\ConfigEntityStorage-&gt;save(Object) (Line: 394)
Drupal\Core\Entity\EntityBase-&gt;save() (Line: 613)
Drupal\Core\Config\Entity\ConfigEntityBase-&gt;save() (Line: 993)
Drupal\views_ui\ViewUI-&gt;save() (Line: 191)
Drupal\views_ui\ViewAddForm-&gt;submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter-&gt;executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter-&gt;doSubmitForm(Array, Object) (Line: 590)
Drupal\Core\Form\FormBuilder-&gt;processForm(&#039;view_add_form&#039;, Array, Object) (Line: 319)
Drupal\Core\Form\FormBuilder-&gt;buildForm(Object, Object) (Line: 93)
Drupal\Core\Controller\FormController-&gt;getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer-&gt;executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber-&gt;Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel-&gt;handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel-&gt;handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle-&gt;handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache-&gt;pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache-&gt;handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware-&gt;handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware-&gt;handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel-&gt;handle(Object, 1, 1) (Line: 693)
Drupal\Core\DrupalKernel-&gt;handle(Object) (Line: 19)
</pre>

Problem/Motivation

Related to #2313075: Allow users to upload webp files in image fields

Since webp is becoming popular, it would be nice if contrib could change the supportedTypes of GDToolkit without needing the extend the class, or even better add support for WebP out of the box.

PS: PHP 5.5 has build in support for WebP and since PHP 5.4 will be abandoned somewhere in 2015, it might be easier to just add support for it.

Proposed resolution

@todo

Remaining tasks

User interface changes

@todo

API changes

@todo

Data model changes

@todo

Release notes snippet

@todo

Today i updated my site using to 8.8.1 version using softaculous tried to login after this update and all i can get is

The website encountered an unexpected error. Please try again later

Can anyone explain the problem to me plz

The domain is http://wasimfayad.com/drupal8/

Problem/Motivation

There is currently no real documentation on how to utilize the new Dialog/Modal APIs properly.

The only thing that currently exists is the rather vague Ajax API group topic which includes some of the dialog/modal response commands in a table at the bottom and a couple change records that are rather terse with examples:

https://www.drupal.org/node/1852224
https://www.drupal.org/node/1989646

Suffice it to say, you're kind of SOL if you weren't involved or familiar with the issues that added dialog/modal support into core.

The only reprise is to start digging around the internal core/contrib code (both PHP and JavaScript) to try and reverse engineer how it's "supposed" to work. This can be made worse if you're only a novice with JavaScript and don't understand how the dialog/modal "magic" actually happens.

Proposed resolution

Create a "Dialog/Modal API" documentation topic.

Remaining tasks

• Create patch

User interface changes

None

API changes

None

Data model changes

None

Warning: Invalid argument supplied for foreach() in element_children() (line 6608 of /public_html/includes/common.inc).

I am seeing this in my logs since upgrading to php 7.2. A search of the above term returns many sites that are exeriencing this issue with visible errors on the page for anonymous users. I hope this helps track the issue.

Adding a meta-issue here for implementing large-scale, server-side mapping in drupal 8.

Problem/Motivation

Server-side clustering and large-scale mapping has been implemented in D7 with a handful of views patches, along with other projects. A sample minimal build can be found here. A production instance of this solution can be found here. At the heart of this implementation is Geocluster.

In order for the whole shebang to work together, we needed some general-purpose patches to Views. Submitting this as a core issue since, obviously, Views is now in core. Will be adding realated issues in comments. This is mostly for tracking of the Views patches with relation to the issues already submitted to other projects towards this goal.

Proposed resolution

Evaluate whether the specific patches have coverage out of the box, and whether or not we need/want to develop D8 versions of the patches, and whether or not they would be considered for commit.

Remaining tasks

Analysis of the patch list in the comments.

User interface changes

None.

API changes

None other than possible addition of hooks.

Data model changes

None

When setting up a private file system as explained in /docs/8/core/modules/file/overview#private-file-system the private file path must be absolute. But when I do that in my configuration with Apache on a shared hosting platform, it does not work. The website is not able to create that directory nor subdirectories. When I manually create the private files directory (or any subdirectory that is required) all works fine.
When I specify the private file path relative like:

$settings['file_private_path'] = '../private';

it works as intended.

So why the documentation states it must be an absolute path? Is this a hosting configuration or is the documentation perhaps wrong?

Problem/Motivation

file_create_url() got no love at all during the D8 cycle.

Consequently, it's:

1. still procedural
2. calls \Drupal::service()four times, and uses a global
3. is not unit testable

Additionally, in current D8, two additional problems arose:

1. 90% of the calls need to be wrapped like this file_url_transform_relative(file_create_url($css_asset['data'])); because it generates absolute URL's and we want to avoid the url.site cache context whenever we can.
2. Some of the calls that would like to use relative URLs currently can't because they need to pass the result as a Url object, and the problem is that non-absolute file_create_url() URL's are root-relative, so they contain the path that drupal is installed in. The Url class however doesn't accept that and can't deal with it. That is what #2646744: \Drupal\Core\Url does not accept root-relative (file) URLs, making it impossible to let LinkGenerator create root-relative file URL links is about. However, that is in my (berdir) opinion almost impossible to solve, because if you have /admin/foo without any further information, it's not possible to tell if /admin is now the base path or not.. Even if the base path really is /admin, it might still be an internal /-prefixed URL.

Proposed resolution

We have two possible options, but both involve adding a FileUrlGenerator service with methods to deal with this. The best way to fix the above problem is to return Url objects already from that service, at least when we need it. Initial versions had a method with an argument to get a relative/absolute URL, but that has been abandoned.

Option 1)
Add 3 dedicated methods for each use case: relative string: generate(), absolute string: generateAbsolute(), Url object: generateUrl(). Advantage is that *many* cases right now really do just need a string, but it leads to considerable duplication within the methods as the current implementation is designed to make it as efficient as possible. E.g. if we get a relative file URL, and want a relative result, we just generate that. And not a Url object or absolute URL just to make it then relative again like we do now.

Option 2)
Only add generateUrl(), if you want a string, use toString(), if you want it to be absolute, use setAbsolute()->toString(). That comes with a certain overhead when you don't need a Url object both in terms of code execution and also characters you have to type. But I more and more places deal with Url objects and the ->toString() thing is everywhere now.. entity toUrl/toLink, and we deprecated several other API's in favor of Url/Link .. toString(). It also allows us to improve cacheability metadata handling, as it can be added automatically.

The patch up until comment #130 implements Option 1, and I (again, berdir) initially believed that to be better, but I'm starting to reconsider. As far as the amount of calls on each of those calls go, these are the current numbers, identified with file.+->generate\(:
generate(): 76 calls in 32 files
generateAbsolute(): 35 calls in 13 files
generateUrl(): 6 calls in 5 files.

That does look it overwhelmingly points out that the separate methods are very useful. *But* a huge amount of those calls are actually in tests and are neither performance-relevant nor the main use case for DX. If I exclude those, it changes quite a bit:
generate(): 21 calls in 14 files
generateAbsolute(): 3 calls in 3 files
generateUrl(): 4 calls in 4 files.

Still considerably more generate() calls than generateUrl() but it does paint a more realistic picture.

Update

The decision was initially made to go with Option 2. However, considerable drawbacks were discovered while implementing that, for example because several related and underlying API's can only return strings and multiple conversions between Url object and back were necessary to display an image style for example. See #137for the details. Changing these API's is not feasible in the already large scope of this issue.

Because of that, this decision was reverted and starting with #151, the patch when back to an earlier version implementing Option 1.

Remaining tasks

Create a follow-up to deprecate the non-Url methods in Drupal 9, likely as a meta issue that first needs to update the related API's.#3087434: [meta] Use FileUrlGenerator::generateUrl() everywhere, then deprecate generate() and generateAbsolute()

Update #2646744: \Drupal\Core\Url does not accept root-relative (file) URLs, making it impossible to let LinkGenerator create root-relative file URL links after this is resolved. While the bug is not technically fixed, it becomes much less important as we can create a Url object directly instead of having to convert it.

User interface changes

None.

API changes

None.

Data model changes

None.

Remember back in the day (D7) when i could just import a view? And the odd time that i was missing a module or a field in that view i could just say "don't care, import anyway" and then just fix it later (which was easy; because when editing that view it was obvious what the issue was and how to fix it) - ahh, the good ole days. :(

I am trying to import a view and am getting the following:

The configuration cannot be imported because it failed validation for the following reasons:

    Configuration media_entity.settings depends on the Media entity (2.x) module that will not be installed after import.
    Configuration system.action.media_delete_action depends on the Media entity (2.x) module that will not be installed after import.
    Configuration system.action.media_publish_action depends on the Media entity (2.x) module that will not be installed after import.
    Configuration system.action.media_save_action depends on the Media entity (2.x) module that will not be installed after import.
    Configuration system.action.media_unpublish_action depends on the Media entity (2.x) module that will not be installed after import.

but my view has nothing to do with anything related to Media, file fields, etc.

From reading a few posts i'll go out on a limb and guess that doing my single import is possibly trying to import everything in my config table? But that can't be right as that would be silly. I admit i have gone through and hacked some things out of the db to try to uninstall the media entity module as it would not uninstall and was blocking db updates. But again, this has nothing to do with the view i am trying to import.

If there is something being imported that is not part of what i just pasted into the single import window; i can't see how that is not a bug.

While trying to finally close #2932625: Fix query count after query builder refactor, I started to look into the underlying functionality. I did not realize that we were doing anything to count queries. In fact, I think I can remember early discussions where we explicitly decided that providing counts was an anti-pattern and would encourage broken client implementations (but I could also just be dreaming that).

As far as I can tell, we're using using ResourceType::includeCount() to determine if we should run a count entity query, then adding that count to the EntityCollection which would only get serialized if includeCount() returned TRUE.

However, the current implementation of includeCount only every returns FALSE!:

public function includeCount() {
  // By default, do not return counts in collection queries.
  return FALSE;
}

This means we're supporting a lot of code paths that can never be executed unless JSON API Extras has overridden the resource type. I'm okay with that, if it's for a really good reason™️.

However, in this case, I think we're really doing a disservice to our consumers.

The only reason I can think of for including a page count is to try to guess the number of requests to make on the client side, rather than relying on the next links already in the document. It encourages clients to manually construct links and it can potentially really trip up developers when any kind of access control is involved.

This unnecessarily forces us to maintain BC for our URL structure, which "in theory", shouldn't be necessary (for discussion elsewhere ;) ). Worst of all, It promises something we can't deliver on. It's bad DX.

I believe we ought to remove this feature before we put JSON API in core and that we should consider how we can best provide resources for developers to grok best-practices for pagination and making use of all the link information we provide, rather than leading them astray.

To be clear, I don't want this to be construed as a blocker to core inclusion. I just think it's we should have the discussion sooner rather than later and the longer we wait, the less freedom we have.

Problem/Motivation

The uninstall box for Layout Builder is grayed out with the message

The Layout Section field type is used in the following field: node.layout_builder__layout

The "Manage Fields" page shows the Layout field as locked.
The "Manage Display" page says

You must revert all customized layouts of this display before you can disable this option.

Without individually checking each node, there is no way to determine which must be reverted

Proposed resolution

• A "Revert All" button on Manage Display that works for only that single bundle. This will appear in the "Layout options" fieldset.
• This button is only visible if the layout has overrides
• When this button is visible, the "Use Layout Builder" and "Allow each content item to have its layout customized." fields are grayed out
• This button will first take the user to a confirmation form, to confirm they're OK with all overrides being deleted.
• After confirming, Layout Builder will be disabled for that display and all overrides in that bundle will be removed from the database (including revisions) and remove all tempstore data for overrides in that bundle

Remaining tasks

Review
Write tests.

User interface changes

The Manage Display UI will be slightly different see ^^Proposed Resolution for details.

API changes

N/A

Data model changes

N/A

This is current state of my D8.8.1 site.

when I run update.php i get:

• Some of the pending updates cannot be applied because their dependencies were not met.
• No pending updates.

Doing a search on this i see posts going back 10 years reporting this in D5, 6, 7 and stating fixed in D7 - i think "fixed" suggests including some sort of useful information.

Running drush updb and response is: [success] No pending updates.

Status Report states:
Database Updates: Out of date - Some modules have database schema updates to install. You should run the database update script immediately.

Somewhat related:
I am trying to force a update hook to be re-run. I manually set system.schema for this module to 1. This was done BEFORE update.php and drush stating "no pending updates" - but there is one in the module whose system.schema i just set to 1.

When i force the update hook to be run (calling the function from devel/php window); there is no indication that it was run (i guess this is up to the module developer to include an output msg) but also, the system.schema remains at 1.

More than a single bug here i think.

The #2942426: [DISCUSSION] Remove query counting and collection counts? explains that without a JSON:API Extras it's *almost* impossible to get a total number of items for a collection request within meta.count. This caused by the "static" code of Drupal\jsonapi\ResourceType\ResourceType::includeCount():

public function includeCount() {
  // By default, do not return counts in collection queries.
  return FALSE;
}

Proposed resolution

- Introduce setIncludeCount($state = TRUE) and includeCount() methods for Drupal\jsonapi\ResourceType\ResourceTypeBuildEvent.
- Add the $include_count = FALSE argument to Drupal\jsonapi\ResourceType\ResourceType::__construct() and return that value by the includeCount() method.
- Get $include_count = $event->includeCount(); in Drupal\jsonapi\ResourceType\ResourceTypeRepository::createResourceType() and pass it to the resource type constructor.

Problem/Motivation

While working on #2998091-66: Remote videos overflow their containing element, the question was raised if we should allow JavaScript to be attached inside the oEmbed content iframe. That issue disallowed it in order to keep the scope limited, but we agreed to open this follow-up issue to discuss and possibly implement the ability to attach JavaScript too.

Themers need a way to interact and control oEmbed content. For example, if there is a play button next to a Vimeo video the JavaScript on the parent page must send the play request through the parent iframe to the child iframe. The child iframe page (media-oembed-iframe.html.twig) must be able to have JavaScript in order to receive the play request from the parent iframe and send it to the child iframe. (It is not possible use Window.postMessage() through multiple iframes.) Both Drupal JavaScript and external JavaScript should be allowed since the provider’s JavaScript API (//player.vimeo.com/api/player.js in this example) will be needed.

Proposed resolution

TBD, once #2998091: Remote videos overflow their containing element lands.

Remaining tasks

TBD.

User interface changes

TBD, but probably none.

API changes

TBD, probably none.

Data model changes

None.

Release notes snippet

TBD

Problem/Motivation

\Drupal\Core\Theme\ThemeNegotiator::determineActiveTheme() only checks for NULL so \Drupal\user\Theme\AdminNegotiator::determineActiveTheme() should return NULL when the admin theme is empty — i.e. the admin theme should be the default theme ie. should fallback to \Drupal\Core\Theme\DefaultNegotiator

Proposed resolution

Detect empty string and return NULL instead.

Atm you can also get "0" as a value but that's being taken care of in #2587119: Form sets system.theme:admin to '0' breaking Quick Edit and making no sense

Remaining tasks

User interface changes

None

API changes

None

Data model changes

None

Release notes snippet

N/A

Running phpcs --standard=PHPCompatibility reports few issues with PHP compatibility.