I was modifying one of my view displays inside a particular view and i must have added an reference field improperly and now I cannot access my view at all. Reports gives me the following error:

Exception: No entity type for field vid on view newsletters in Drupal\views\Plugin\views\HandlerBase->getEntityType() (line 697 of /home/admin/domains/zend8.sitesbycoop.com/public_html/core/modules/views/src/Plugin/views/HandlerBase.php).

How can i disable this view mode or get back into my view to remove this field?

Thanks,
Josh

drupal_valid_test_ua() and drupal_generate_test_ua() should be removed with a modern approach.

Problem/Motivation

We are in the process of deprecating jQuery UI in core. The jQueryUI position library is among the components that need to be removed/replaced.
As mentioned in the parent issue: #3067261: [Plan] Remove jQuery UI components used by Drupal core and replace with a set of supported solutions
The OpenJS Foundation lists jQuery UI as an Emeritus project in https://openjsf.org/projects/ which is described as:

Emeritus projects are those which the maintainers feel have reached or are nearing end-of-life

Proposed resolution

In core, jQueryUI Position is primarily used by other jQuery UI libraries that will be deprecated. There is one instance where it is used in isolation and must be specifically addressed: the Quickedit module. This means this issue is essentially finding a new library for Quickedit's positioning

Some options

• https://github.com/HubSpot/tether (probably a bad option, Hubspot was impressibly candid about no longer maintaining this)
• https://github.com/FezVrasta/popper.js (recommended by Hubspot as a well maintained alternative)

Rule out libraries that shouldn't be used due to abandonment, performance, etc.
Create a prototype for the remaining libraries to be used in place of jQuery UI for quickedit's positioning
If prototype appears to function well, get signoff from Quickedit maintainer.

User interface changes

Ideally, there will be none. Any changes shouldn't be more than a mildly noticeable pixel difference

API changes

...

Data model changes

N/A

Release notes snippet

...

Since Drupal.org’s migration to GitLab, http://cgit.drupalcode.org/drupal is now https://git.drupalcode.org/project/drupal

Problem/Motivation

User gets an error when trying to reference an unpublished entity that he himself has just created and that he has full access to. This basically makes it impossible for a user to submit a set of unpublished interreferencing entities (e.g. artefact/architect/city).

Steps to reproduce:
1. Create content type A, make sure Published is unchecked in the Publishing options.
2. Create content type B, add an ER field referencing A, choose Autocomplete widget in Form display.
3. Create a test user, give him permissions to View own unpublished content, to Create A and B, to Edit own A and B.
4. Log in as that user.
5. Create a test node of type A, verify that it's Unpublished and the user can see it.
6. Create a test node of type B, start typing the label of the A node just created, verify that it's not recoginized and suggested by the system.
7. Type the complete label and hit Save, get the "No such entity" error.
8. Type the entity label followed by its nid in parentheses, still get the "This entity (node: N) cannot be referenced”

Proposed resolution

Allow referencing unpublished entities if the current user has access to them.

UPDATE:
This issue also prevents the user w/ appropriate permissions from referencing unpublished entities authored by other users.

Problem/Motivation

For PHP code, we have a well-defined set of rules for how to do deprecations in a continuous upgrade path:
https://www.drupal.org/core/deprecation

For JavaScript, we haven't defined a deprecation strategy yet. Some JS frameworks, including React and Ember, already provide mechanisms for providing developer-facing warnings about deprecated code use that are similar to what Symfony (and now Drupal) have adopted.

Proposed resolution

1. Adopt the same deprecation message format for JS as for PHP. It should include:
   • What version the code was first deprecated in
   • When it will be removed (the next major version)
   • What to use instead.
   • An @see tag linking the replacement.
   • A link to the change record.
2. Follow the same general best practices as we do for PHP, namely: public APIs should always provide BC and a deprecation. Internal APIs do not require BC and deprecations, but it's recommended to provide them unless there are substantial costs to doing so (in terms of maintainability, performance, etc.).

For #1, I've heard feedback from JavaScript contributors that since we're using a well-defined set of coding standards rules that's used outside Drupal, they don't want to add additional Drupalisms on top of that. However, for deprecations, I think all five of the things listed are important and so we might as well just use the same format as we do for PHP.

For #2, we'll need to actually define what's part of our public JS API vs. what is internal. There's an existing policy issue for that. I don't have it at the moment, but we should discuss that in that issue, not this one. :)

Remaining tasks

Run this by relevant maintainers (JS, frontend framework managers, release managers).

Right now, the Migration plugin does a lot of grunt work related to instantiating and managing source, destination, and ID map plugins and their configuration. This is a shame, because core already has an API for abstracting and encapsulating that kind of thing -- namely, plugin collections. The Migration plugin should use this plumbing, rather than reinventing the wheel. It's considered good practice to use plugin collections, and it's nice to delegate as much of the details of plugin management as we can.

Problem/Motivation

During an attempted drush cim, I get the following error messages:

array_keys() expects parameter 1 to be array, null given ConfigImportSubscriber.php:173 [warning]
Invalid argument supplied for foreach() ConfigImportSubscriber.php:173

and

exception 'InvalidArgumentException' with message 'Unknown theme: w2w.' in [error]
/Users/rppowell/Sites/women2women/core/lib/Drupal/Core/Extension/ThemeInstaller.php:220

This theme has been uninstalled but it looks like it has gotten stuck in config. I have tried different strategies to find the corrupt data but so far no luck. Here are some suggestions from people in slack channel and various pages which I have tried.

• Confirmed theme was uninstalled
• Searched config files for dependencies to the theme
• Ran queries to check database
  • select * from key_value where collection = 'state' and name = 'system.theme.files';
  • select name from config where name like ('%theme%');

Using xdebug I have determined that these lines are what are retrieving the corrupt data.

ConfigImportSubscriber.php#171

$uninstalls = $config_importer->getExtensionChangelist('theme', 'uninstall');

ThemeInstaller.php#214

public function uninstall(array $theme_list) {

I cannot determine what calls uninstall but it is after the batch kicks off. Just to clarify, if I do a drush cex w2w is listed under themes. If I try to delete that record and drush cim I will get this error. I would love it if someone could clarify how $config_importer is getting the theme name.

Unfortunately, I am at the point where I don't know how else to troubleshoot this and am starting to get really opinionated about why I don't think a deleted theme should break CIM. I will supply a patch on whatever work-around I commit to but really hoping to learn how to fix this the right way.

Proposed resolution

Two solutions:

1. In ConfigImportSubscriber, check if key exist before foreach
2. In ThemeInstaller.php, if the key is the known bad theme, return

Remaining tasks

User interface changes

API changes

Data model changes

Hi,

I have created a content type "Organization" and added 3 contents. Then I have configured profile 2 type for user signup. Used an entity reference select box in signup page to register a user under a specific Organization.

Now I want to display list of profiles that are registered under a particular Organization.

Created a view block to list Organization content. On click of a particular Organization(its detail page), profiles are not listing out.

Please help me out with steps to resolve this.
Thanks in advance.

Priya Agrawal

Example inside an svg that is imported in css as data-url:
<path fill="url(#SVGID_1_)" d="M1256.4,386h1500v21h-1500V386z"/>

Notice the "url(#SVGID_1_)". This will be converted to
url(http://domain.com/path/path/#SVGID_1_1)

Resulting in a broke svg.

(added an svg that has this problem)

Problem/Motivation

In #2940029: Add an input filter to display embedded Media entities, we added the ability to embed media entities into WYSIWYG text editors and HTML content, using an input filter. By default, the media items are embedded by rendering them through their "full" view mode (although this can be overridden by changing a special data attribute in the raw HTML). The "full" view mode might not be entirely appropriate for an embedded representation of a media item, so this issue is where we can explore the possibility of adding a new view mode specifically for use when embedding media items in HTML, and changing the input filter to use it as the default view mode.

Proposed resolution

Discuss whether we should create an "embed" view mode, and what should be in the corresponding view displays for each media type we ship with Standard.

Remaining tasks

Once we've decided what we want, make it happen.

User interface changes

TBD.

API changes

TBD, but likely none.

Data model changes

None anticipated.

Release notes snippet

TBD

Problem/Motivation

After path aliases are converted to entities, we should also convert their forms to extend content entity form base classes.

Proposed resolution

Convert custom path alias forms to entity forms.

Remaining tasks

Do it :)

User interface changes

Nope.

API changes

Nope.

Data model changes

Nope.

I recently tried to migrate our site in Drupal 7 to Drupal 8 via Drupal Migration UI available in Core. The Drupal version used 8.7.6. The migration crashed midway. On seeing the content created, there were no node type set. There were no content types created as well. Tried migrating 3 times after restoring database back, same results.

I then tried to see if I could make some changes post migration crash in the command line. I executed the command drush mim d7_node_type. The command did not succeed and threw exception. Please find them below.

I have migrated 3 sites till now from D7 to D8. Do let me know if additional details are required or if there is a workaround.

Prompt:/var/www/drupal8$ drush mim d7_node_type    PDOException: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'severity' cannot be null in    [error]   /var/www/drupal8/core/lib/Drupal/Core/Database/Statement.php:59  Stack trace:    
#0 /var/www/drupal8/core/lib/Drupal/Core/Database/Statement.php(59):    PDOStatement->execute(Array)    
#1 /var/www/drupal8/core/lib/Drupal/Core/Database/Connection.php(631):  Drupal\Core\Database\Statement->execute(Array, Array)  
#2 /var/www/drupal8/core/lib/Drupal/Core/Database/Driver/mysql/Connection.php(358):  Drupal\Core\Database\Connection->query('INSERT INTO {wa...', Array, Array)  
#3 /var/www/drupal8/core/lib/Drupal/Core/Database/Driver/mysql/Insert.php(32):   Drupal\Core\Database\Driver\mysql\Connection->query('INSERT INTO {wa...', Array, Array)   
#4 /var/www/drupal8/core/modules/dblog/src/Logger/DbLog.php(78):    Drupal\Core\Database\Driver\mysql\Insert->execute()   
#5 /var/www/drupal8/core/modules/dblog/src/Logger/DbLog.php(103):   Drupal\dblog\Logger\DbLog->log(NULL, Object(Drupal\Core\StringTranslation\PluralTranslatableMarkup), Array)    
#6 /var/www/drupal8/core/lib/Drupal/Core/Logger/LoggerChannel.php(127):  Drupal\dblog\Logger\DbLog->log(NULL, Object(Drupal\Core\StringTranslation\PluralTranslatableMarkup), Array)    
#7 /var/www/drupal8/modules/contrib/migrate_tools/src/DrushLogMigrateMessage.php(25):   Drupal\Core\Logger\LoggerChannel->log(NULL, Object(Drupal\Core\StringTranslation\PluralTranslatableMarkup))    
#8 /var/www/drupal8/modules/contrib/migrate_tools/src/MigrateExecutable.php(278):   Drupal\migrate_tools\DrushLogMigrateMessage->display(Object(Drupal\Core\StringTranslation\PluralTranslatableMarkup))  
#9 /var/www/drupal8/modules/contrib/migrate_tools/src/MigrateExecutable.php(239):   Drupal\migrate_tools\MigrateExecutable->progressMessage()  
#10 [internal function]:  Drupal\migrate_tools\MigrateExecutable->onPostImport(Object(Drupal\migrate\Event\MigrateImportEvent), 'migrate.post_im...',   Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))    
#11  /var/www/drupal8/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111):  call_user_func(Array, Object(Drupal\migrate\Event\MigrateImportEvent), 'migrate.post_im...',  Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))    
#12 /var/www/drupal8/core/modules/migrate/src/MigrateExecutable.php(279):    Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('migrate.post_im...',    Object(Drupal\migrate\Event\MigrateImportEvent))  
#13 /opt/drush-8.x/vendor/drush/drush/includes/drush.inc(720): Drupal\migrate\MigrateExecutable->import()  
#14 /opt/drush-8.x/vendor/drush/drush/includes/drush.inc(711): drush_call_user_func_array(Array, Array)    
#15 /var/www/drupal8/modules/contrib/migrate_tools/migrate_tools.drush.inc(326):  drush_op(Array)  
#16 [internal function]: _drush_migrate_tools_execute_migration(Object(Drupal\migrate\Plugin\Migration), 'd7_node_type',  Array)  
#17 /var/www/drupal8/modules/contrib/migrate_tools/migrate_tools.drush.inc(281):  array_walk(Array, '_drush_migrate_...', Array)  
#18 /opt/drush-8.x/vendor/drush/drush/includes/command.inc(422): drush_migrate_tools_migrate_import('d7_node_type')   
#19 /opt/drush-8.x/vendor/drush/drush/includes/command.inc(231): _drush_invoke_hooks(Array, Array)    
#20 /opt/drush-8.x/vendor/drush/drush/includes/command.inc(199): drush_command('d7_node_type')    
#21 /opt/drush-8.x/vendor/drush/drush/lib/Drush/Boot/BaseBoot.php(67): drush_dispatch(Array)  
#22 /opt/drush-8.x/vendor/drush/drush/includes/preflight.inc(66): Drush\Boot\BaseBoot->bootstrap_and_dispatch()   
#23 /opt/drush-8.x/vendor/drush/drush/drush.php(12): drush_main()  
#24 {main}   Next Drupal\Core\Database\IntegrityConstraintViolationException: SQLSTATE[23000]: Integrity constraint violation: 1048    Column 'severity' cannot be null: INSERT INTO {watchdog} (uid, type, message, variables, severity, link, location, referer,   hostname, timestamp) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2,  :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6,    :db_insert_placeholder_7, :db_insert_placeholder_8, :db_insert_placeholder_9); Array  (   [:db_insert_placeholder_0] => 0  [:db_insert_placeholder_1] => migrate_tools  [:db_insert_placeholder_2] => Drupal\Core\StringTranslation\PluralTranslatableMarkup Object   (   [count:protected] => 0   [translatedString:protected] => Processed 1 item (@created created, @updated updated, @failures failed, @ignored  ignored) - done with '@name'Processed @numitems items (@created created, @updated updated, @failures failed, @ignored    ignored) - done with '@name'  [translatedMarkup:protected] =>  [options:protected] => Array  (   )  [stringTranslation:protected] => Drupal\Core\StringTranslation\TranslationManager Object  (   [translators:protected] => Array    (   [30] => Array   (   [0] => Drupal\Core\StringTranslation\Translator\CustomStrings Object  (   [settings:protected] => Drupal\Core\Site\Settings Object  (   [storage:Drupal\Core\Site\Settings:private] => Array  (   [hash_salt] =>  kvhlb9NTNJ8JP5voIuHYcjavLbDFOO3x5oSlpJWceAbXiX20DaM9O_tWkVOSwFZogoAMymdWHQ  [update_free_access] =>  [file_private_path] => /srv/www/private/example  [container_yamls] => Array   (   [0] =>  /var/www/drupal8/sites/default/services.yml   )  [trusted_host_patterns] => Array    (   [0] => ^example\.net$  [1] => ^.+\.example\.net$  )  [file_scan_ignore_directories] => Array  (   [0] => node_modules  [1] => bower_components  )  [entity_update_batch_size] => 50    [entity_update_backup] => 1  )  [_serviceId] => settings    )  [translations:protected] => Array   (   [en] => Array   (   )  )  [_serviceIds:protected] => Array    (   )  [_entityStorages:protected] => Array    (   )  [_serviceId] => string_translator.custom_strings  )  )  )  [sortedTranslators:protected] => Array  (   [0] => Drupal\Core\StringTranslation\Translator\CustomStrings Object  (   [settings:protected] => Drupal\Core\Site\Settings Object  (   [storage:Drupal\Core\Site\Settings:private] => Array  (   [hash_salt] =>    kvhlb9NTNJ8JP5voIuHYcjavLbDFOO3x5oSlpJWceAbXiX20DaM9O_tWkVOSwFZogoAMymdWHQ   [update_free_access] =>  [file_private_path] => /srv/www/private/example  [container_yamls] => Array   (   [0] =>    /var/www/drupal8/sites/default/services.yml    )  [trusted_host_patterns] => Array    (   [0] => ^example\.net$  [1] => ^.+\.example\.net$  )  [file_scan_ignore_directories] => Array  (   [0] => node_modules  [1] => bower_components  )  [entity_update_batch_size] => 50    [entity_update_backup] => 1  )  [_serviceId] => settings    )  [translations:protected] => Array   (   [en] => Array   (   )  )  [_serviceIds:protected] => Array    (   )  [_entityStorages:protected] => Array    (   )  [_serviceId] => string_translator.custom_strings  )  )  [defaultLangcode:protected] => en   [_serviceId] => string_translation  )  [string:protected] => Processed 1 item (@created created, @updated updated, @failures failed, @ignored ignored)   - done with '@name'Processed @numitems items (@created created, @updated updated, @failures failed, @ignored ignored) -  done with '@name'   [arguments:protected] => Array  (   [@numitems] => 0  [@created] => 0  [@updated] => 0  [@failures] => 0  [@ignored] => 0  [@name] => d7_node_type  )  )  [:db_insert_placeholder_3] => a:0:{}    [:db_insert_placeholder_4] =>   [:db_insert_placeholder_5] =>   [:db_insert_placeholder_6] => http://default/   [:db_insert_placeholder_7] =>   [:db_insert_placeholder_8] => 127.0.0.1  [:db_insert_placeholder_9] => 1566801311    )    in /var/www/drupal8/core/lib/Drupal/Core/Database/Connection.php:689   Stack trace:    
#0 /var/www/drupal8/core/lib/Drupal/Core/Database/Connection.php(656):  Drupal\Core\Database\Connection->handleQueryException(Object(PDOException), 'INSERT INTO {wa...', Array, Array)   
#1 /var/www/drupal8/core/lib/Drupal/Core/Database/Driver/mysql/Connection.php(358):  Drupal\Core\Database\Connection->query('INSERT INTO {wa...', Array, Array)  
#2 /var/www/drupal8/core/lib/Drupal/Core/Database/Driver/mysql/Insert.php(32):   Drupal\Core\Database\Driver\mysql\Connection->query('INSERT INTO {wa...', Array, Array)   
#3 /var/www/drupal8/core/modules/dblog/src/Logger/DbLog.php(78):    Drupal\Core\Database\Driver\mysql\Insert->execute()   
#4 /var/www/drupal8/core/modules/dblog/src/Logger/DbLog.php(103):   Drupal\dblog\Logger\DbLog->log(NULL, Object(Drupal\Core\StringTranslation\PluralTranslatableMarkup), Array)    
#5 /var/www/drupal8/core/lib/Drupal/Core/Logger/LoggerChannel.php(127):  Drupal\dblog\Logger\DbLog->log(NULL, Object(Drupal\Core\StringTranslation\PluralTranslatableMarkup), Array)    
#6 /var/www/drupal8/modules/contrib/migrate_tools/src/DrushLogMigrateMessage.php(25):   Drupal\Core\Logger\LoggerChannel->log(NULL, Object(Drupal\Core\StringTranslation\PluralTranslatableMarkup))    
#7 /var/www/drupal8/modules/contrib/migrate_tools/src/MigrateExecutable.php(278):   Drupal\migrate_tools\DrushLogMigrateMessage->display(Object(Drupal\Core\StringTranslation\PluralTranslatableMarkup))  
#8 /var/www/drupal8/modules/contrib/migrate_tools/src/MigrateExecutable.php(239):   Drupal\migrate_tools\MigrateExecutable->progressMessage()  
#9 [internal function]:  Drupal\migrate_tools\MigrateExecutable->onPostImport(Object(Drupal\migrate\Event\MigrateImportEvent), 'migrate.post_im...',   Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))    
#10  /var/www/drupal8/core/lib/Drupal/Component/EventDispatcher/ContainerAwareEventDispatcher.php(111):  call_user_func(Array, Object(Drupal\migrate\Event\MigrateImportEvent), 'migrate.post_im...',  Object(Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher))    
#11 /var/www/drupal8/core/modules/migrate/src/MigrateExecutable.php(279):    Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch('migrate.post_im...',    Object(Drupal\migrate\Event\MigrateImportEvent))  
#12 /opt/drush-8.x/vendor/drush/drush/includes/drush.inc(720): Drupal\migrate\MigrateExecutable->import()  
#13 /opt/drush-8.x/vendor/drush/drush/includes/drush.inc(711): drush_call_user_func_array(Array, Array)    
#14 /var/www/drupal8/modules/contrib/migrate_tools/migrate_tools.drush.inc(326):  drush_op(Array)  
#15 [internal function]: _drush_migrate_tools_execute_migration(Object(Drupal\migrate\Plugin\Migration), 'd7_node_type',  Array)  
#16 /var/www/drupal8/modules/contrib/migrate_tools/migrate_tools.drush.inc(281):  array_walk(Array, '_drush_migrate_...', Array) 

Problem/Motivation

Field formatter third party settings provided by hook_field_formatter_third_party_settings_form() are missing form the Views UI interface when using Fields.

Proposed resolution

Add support for Field formatter third party settings to the Views UI interface when using Fields.

Remaining tasks

User interface changes

API changes

Data model changes

Problem/Motivation

Drupal modules and themes need to be able to specify that they depend on specific versions of Drupal because a new minor version of Drupal may introduce new APIs and a patch version may fix bugs. Drupal modules and themes also should be able to specify if they are compatible with 2 major versions of Drupal such as 8 and 9, if they don't use any APIs that will be removed in Drupal 9. Modules, install profiles and themes should not have to create a new major branches to achieve this as per #2608062: [META] Requirements for opening the Drupal 9 branch.

For Drupal 8 projects, currently the core key in info.yml files only supports core: 8.x which denotes that they support any version of Drupal 8. To get around this limitation many modules use the dependencies: key in info.yml files with a more specific version of system module. For example
- "drupal:system (>8.6)". But this method is not enough because it does not support patch releases either, see #2641658: Module version dependency in .info.yml is ineffective for patch releases.

While we could change the core: key to accept semantic version constraints to allow requiring specific core patch versions, for example core: ^8.7, or even support multiple branch compatibility (core: ^8 || ^9), or both (core: ^8.7 || ^9) this would cause problems for any sites using previous versions of Drupal 8 core, if they attempted to update a module they currently have installed that switched to the new format.

A Drupal 8.x.y site that has my_module 8.x-1.1 that uses core: 8.x and then updates to my_module 8.x-1.2 that uses core: ^8 (anything beside 8.x) will have this this module silently disabled, even while the configuration for the module would still be available. There would be no message that this happened. See #138 and #2917600: Disabling missing modules results in a "Unable to install MODULE already exists in active configuration" warning or PreExistingConfigException (via Drush).

Proposed resolution

As a consequence of the above, we need to introduce a new key core_version_requirement: that would accept Composer semantic version constraints. The version constraints will be evaluated by \Composer\Semver\Semver::satisfies(). The rules for this can be found at https://getcomposer.org/doc/articles/versions.md.

This key could be used at the same time as the core: key. But in certain cases it would be used in place of the core: key. To make it possible to have modules be compatible Drupal 8.7.x, 8.8.x, 8.9.x and 9.0.x and maximize the duration in which Drupal 9 readiness can be worked on and ensure that security fixes for contrib modules don't force sites still on Drupal 8.7.x to upgrade to Drupal 8.8.x (if the module doing a security release already started using core_version_requirement). See reasoning in #179.3 and release manager approval in #207.

Assuming the 8.7 patch release in which this issue ships is 8.7.7, the following combination would not produce the expected results info.yml file:

core: 8.x
core_version_requirement: ^8.7.7

This would not actually restrict anyone from installing it on Drupal 8.6.x, or 8.7.0 through 8.7.6 since the core_version_requirement key would be ignored and would therefore still allow the module to be installed. We cover this case by not allowing the core: key once a core_version_requirement key requires Drupal 8.7.7 or later. Not having the core: key will give a hard fail in Drupal 8.7.x sites but because it fails in \Drupal\Core\Extension\InfoParserDynamic::parse this would not cause a problem in #138 and #2917600: Disabling missing modules results in a "Unable to install MODULE already exists in active configuration" warning or PreExistingConfigException (via Drush).

Another combination that would not produce the expected results:

core: 8.x
core_version_requirement: ^8.7.4

In this case Drupal 8.7.3 would not enforce core_version_requirement: ^8.7.4. We enforce this by not allowing restrictions that cover versions before this issue is committed because these will not actually be enforced.

In both these cases it would be hard for a contrib author to be aware for these problems if they are working on Drupal 8.8.x unless they also tested their module on previous versions of Drupal. Therefore we should add validation to \Drupal\Core\Extension\InfoParserDynamic::parse() to make sure that module authors don't create info files with these problems.

Examples of supported core_version_requirement: values:

Remaining tasks

User interface changes

Small string change for modules page.

API changes

Support core semantic versioning for Drupal core via new core_version_requirement key.

Data model changes

None.

Release notes snippet

A new core_version_requirement has been added to info.yml files. This key replaces the core key for projects that only support Drupal 8.8 onwards (including Drupal 9). It may be used in addition to the core key for projects that want to specify compatibility with Drupal 9 as well (but remain compatible with prior versions of Drupal 8). Read more at https://www.drupal.org/node/3070687

Problem/Motivation

In Drupal 8.5 menu editing has regressed because if you edit a menu link from this form you are redirected back to the menu list form. It is very jarring. This is a regression from the 8.4.x behaviour introduced by #2767857: Add destination to edit, delete, enable, disable links in entity list builders.

Proposed resolution

Remove the destination as we did in #2940165: [regression] Cannot add effects to image style via the UI

Remaining tasks

Add a test

User interface changes

The destination is removed from the links on admin/structure/menu

API changes

None

Data model changes

None

I believe this being a follow up to #2291055: REST resources for anonymous users: register.

I am creating an user with the rest resource, configured not to verify email address, and the register_no_approval_required is not sent.

However, registering the user with the same settings through the drupal UI as an anonymous user does send the notification.

One would expect the same behavior:

./core/modules/user/src/RegisterForm.php

    // No email verification required; log in user immediately.
    elseif (!$admin && !\Drupal::config('user.settings')->get('verify_mail') && $account->isActive()) {
      _user_mail_notify('register_no_approval_required', $account);
      user_login_finalize($account);
      drupal_set_message($this->t('Registration successful. You are now logged in.'));
      $form_state->setRedirect('<front>');
    }

./core/modules/user/src/Plugin/rest/resource/UserRegistrationResource.php:

  protected function sendEmailNotifications(UserInterface $account) {
    $approval_settings = $this->userSettings->get('register');
    // No e-mail verification is required. Activating the user.
    if ($approval_settings == USER_REGISTER_VISITORS) {
      if ($this->userSettings->get('verify_mail')) {
        // No administrator approval required.
        _user_mail_notify('register_no_approval_required', $account);
      }
    }
    // Administrator approval required.
    elseif ($approval_settings == USER_REGISTER_VISITORS_ADMINISTRATIVE_APPROVAL) {
      _user_mail_notify('register_pending_approval', $account);
    }
  }

Problem/Motivation

This from feedback from @effulgentsia here #2801307-54: [META] Support WYSIWYG embedding of media entities:

[...] add CSS along the lines of max-width: 75% on media that's aligned left or right. It's fine for the media to be smaller. It's just that if you're explicitly choosing to align it left or right, then you're choosing to put something else beside it, which means leaving some amount of room for that something else.

Proposed resolution

TBD

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

Problem/Motivation

Core currently provides support for embedding of images. It is currently impossible to embed a video or a document. Also, when #2801277: [META] Support remote media assets as first-class citizens by adding Media Entity module in core lands we'll need to embed media entities rather than files.

Contrib already has a solution for this. Entity embed is a module that supports embedding of any renderable entity and supports extensive display configuration.

Proposed resolution

Move parts of Entity embed into core (simplified text filter) and handle embedding through it. Entity embed display plugins, embed button config entities, and other related API surface will stay in contrib. The simplified text filter will only support embedding media entities; people wishing to embed other types of entities will need to use contrib. Existing WYSIWYG functionality would remain the same.

Remaining tasks

In order:

1. ✅ #2940029: Add an input filter to display embedded Media entities
2. ✅ #2994696: Render embedded media items in CKEditor
3. ✅ #2994699: Create a CKEditor plugin to select and embed a media item from the Media Library
4. #2994702: Allow editors to alter embed-specific metadata, as well as `data-align` and `data-caption`
5. #3066802: Add a new view mode for embedded media
6. #3074608: [PP-1] Optionally allow choosing a view mode for embedded media in EditorMediaDialog
7. #3077756: Improve description of the Media Embed filter
8. SHOULD-HAVE #3073901: Determine an upgrade path from CKEditor image button to media library

Additional required bug fixes:

• #3067116: text_summary() returns malformed (not normalized) HTML for basic_html and other formats that use filter_html instead of filter_htmlcorrector
• #3067124: text_summary() returns a plain string, even if passed a MarkupInterface object

Additional related and follow-up issues

• #3074859: Add a button to remove an embedded media item from the editor
• #3074863: Improve the UX of captioning in CKEditor
• #3074867: Remove role attribute from figure tags generated by filter_caption
• #2910102: Improve icon colour contrast for WCAG 2.1

User interface changes

TBD

API changes

TBD

Data model changes

TBD

Problem

Now that #2880152: Convert custom menu links to be revisionable is in, changes to menu links in non-live workspaces are not showing up. Making changes, and publishing changes from non-live to live works well. But it's not possible to preview the changes on the site's frontend.

This is probably due to cache issues where rendered menus needs to be cached per workspace.

Proposed solution

Cache menus per workspace.

API changes

None.