Available Updates are lists as 4 or 5 updates. When updating i receive a message at the top containing the following but update are successful.

User warning: The following module is missing from the file system: colorbox. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: emfield. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: entity. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: entity_view_mode. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: feeds. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: feeds_import. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: feeds_ui. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: filefield_sources. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: imagecache_external. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: image_link_formatter. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: job_scheduler. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: job_scheduler_trigger. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: linkimagefield. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: media_browser_plus. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: multiform. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: nodeaccess. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: remote_file_source. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: remote_stream_wrapper. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: service_links_displays. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: service_links_sprites. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: service_links. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: stock. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: stockapi. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: url_formatter. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: actions_permissions. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: views_bulk_operations. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: views_tree. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: ckeditor. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: salesforce_soap. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).
User warning: The following module is missing from the file system: salesforce. For information about how to fix this, see the documentation page. in _drupal_trigger_error_with_delayed_logging() (line 1143 of /home2/autogenomics/public_html/drupal1/includes/bootstrap.inc).

after updating core to 7.67 and replace jquery 10 with jquery 3.x3.1 all ajax call in web forms stop working and the below error showing in browser console .

Uncaught TypeError: $(...).find(...).andSelf is not a function
at Object.attach (js_PeRPhiR3AxQHBRyDqp_l56bHcF5QBkOwgr9xp9iD1t0.js:54)
at Object. (js_xHfRNX70oaQZzdHn2aEjHSvnphPMhnGr2dd0Nsl2MrY.js:305)
at Function.each (jquery-3.3.1.min.js:2)
at Object.Drupal.attachBehaviors (js_xHfRNX70oaQZzdHn2aEjHSvnphPMhnGr2dd0Nsl2MrY.js:303)
at HTMLDocument. (js_xHfRNX70oaQZzdHn2aEjHSvnphPMhnGr2dd0Nsl2MrY.js:786)
at l (jquery-3.3.1.min.js:2)
at c (jquery-3.3.1.min.js:2)

I did replace the andSelf() with .addBack() in misc/form.js and it solved .
ref : https://api.jquery.com/andself/

any suggestion from yours to avoid editing in core file misc/form.js

Thanks

Problem/Motivation

From #2935951-43: Copy migrate source plugin from migrate_drupal_d8 into migrate_drupal, we discussed extracting getDefinitionFromEntity from ContentEntity and EntityContentBase into a re-usable trait. Let's do it.

Proposed resolution

Remaining tasks

Extract the method into a trait.

User interface changes

API changes

Data model changes

Problem/Motivation

#states do not work with 'datetime' form elements.

Proposed resolution

• Update logic in the Datetime element to handle the nested elements.
• Fix datetime-wrapper twig templates to actually generate a wrapper div.
• Consistently use <label> not <h4> for the datetime wrapper label.

Remaining tasks

1. Write and verify automated tests. Complete. See comments #91-102
2. Markup review of all the changes to the datetime-wrapper twig templates.
3. JavaScript review of the changes to core/misc/states.es6.js.
4. Other reviews + manual testing (optional).
5. Commit.
6. Unblock child issues.

User interface changes

#states actually works on datetime form elements.

Changes to the datetime-wrapper.html.twig templates (default templates from system and both the classy and stable themes) to:

• Actually include a wrapper div (!)
• Always use <label> not <h4> for the label. The label is generated using the existing core theme templates for form labels (form_element_label).

API changes

None.

Data model changes

None.

Original Report

While trying to create a custom field widget containing a "datetime" form element, I discovered that the #states attribute does not work on it.

Some states can be achieved with a workaround: put the datetime element in a container, and put the #states on the container. But this is obviously no clean fix, and it doesn't work for all states. (Works for "visible" for example, but not for "required".)

I was not able to figure out why this is not working, but I noticed that there have been a lot of issues regarding the #states attribute in the issue tracker. Most of them for were for specific elements like submit buttons, select elements with multiple values, ...

I tried entering the date "2100-08-02 17:35 -0500" into the authored on field, and Drupal said it was invalid. Obviously it's a valid date. It's only a hundred years into the future. So if Drupal wants to last for the next century, I suggest this gets fixed.

https://dev.mysql.com/doc/refman/5.7/en/integer-types.html

BIGINT 8

https://www.postgresql.org/docs/10/datatype-numeric.html#DATATYPE-INT

bigint 8 bytes large-range integer -9223372036854775808 to +9223372036854775807

https://www.sqlite.org/datatype3.html

INTEGER. The value is a signed integer, stored in 1, 2, 3, 4, 6, or 8 bytes depending on the magnitude of the value.

#2885413: Timestamp field items are affected by 2038 bug

Problem/Motivation

There are still functional tests that can be converted, entirely or partially into Kernel/Unit tests.

Proposed resolution

Identify them and convert them:

Discovered so far:

• #3035518: Convert ImageEffectsTest & ToolkitTest into Kernel tests
• #3041755: Convert HandlerAllTest into a kernel test
• #3042994: MailCaptureTest provides the same test coverage as AssertMailTraitTest and should be removed
• #2664292: Convert Module\InstallTest into a Kernel test
• #2695221: Remove ConfigFileContentTest and spread its ashes over ConfigCRUDTest and ConfigStorageTestBase
• #3046670: Convert FieldTypeTest into a Kernel test. Move block content creation methods in a trait
• #3046682: Convert BlockContentValidationTest into a Kernel test
• #3048423: Convert RelationshipUserFileDataTest into a Kernel test
• #2035133: Convert system module's Mail unit test to phpunit (duplicate #3049866: Convert HtmlToTextTest into a Unit test?)
• #3050353: \Drupal\Tests\system\Functional\Module\VersionTest could be a Kernel (or Unit) Test

Done:

• #3050172: Move MigrateLanguageTest under Kernel tests namespace
• #3049685: Move MigrateNodeRevisionTest & NodeMigrateDeriverTest under the Kernel tests namespace
• #3048434: Convert FileManagedAccessTest into a Kernel test
• #3046694: Convert BookInstallTest into a Kernel test
• #3049604: Convert CommentFieldNameTest into a Kernel test
• #3041842: Convert ArgumentValidateTest into a kernel test
• #3046937: Convert TrackerUserUidTest into a Kernel test. Deprecate TrackerTestBase
• #3041863: Convert a few node access tests from functional to kernel tests
• #3041030: Convert functional EfqTest to a kernel test and move TaxonomyTestTrait from tests/src/Functional to tests/src/Traits
• #3046018: Convert SelectionTest into a Kernel test
• #3046377: Convert ContactFieldsTest into a Kernel test
• #3041696: Convert FieldApiDataTest into a kernel test
• #3046382: Convert ConfigTranslationFormTest into a Kernel test
• #3041778: Convert FilterEntityBundleTest into a kernel test
• #3046388: Convert LocaleStringTest into a Kernel test
• #3046171: Convert FilterCaptionTwigDebugTest into a Kernel test
• #3046698: Convert BcRoutesTest into a Kernel test
• #3046676: Convert block_content RevisionRelationshipsTest into a Kernel test
• #3046393: Convert ConnectionFailureTest into a Kernel test
• #2432647: Convert BlockTemplateSuggestionsTest into a KernelTestBase
• #3046281: Convert FilterUidRevisionTest into a Kernel test
• #3046392: Convert LocaleLibraryAlterTest into a Kernel test
• #3039378: Convert TermEntityReferenceTest to be a kernel test
• #2079647: Convert UserSaveTest to a kernel test. Remove useless test
• #3041036: Convert UserDeleteTest to kernel test (or get rid of it?)
• #3041096: Convert FilterNoFormatTest to a kernel test
• #3041042: Convert UserEntityCallbacksTest to a kernel test
• #3041727: Convert ViewRenderTest into a Kernel test
• #3041743: Convert ViewsTemplateTest into a Kernel test
• #3041765: Convert FieldGroupRowsTest into a Kernel test
• #3041770: Convert ArgumentStringTest into a Kernel test
• #3041786: Convert LatestRevisionFilterTest to a kernel test
• #3041801: Convert StyleTest to a kernel test
• #3041816: Move UserMailNotifyTest under Kernel tests namespace
• #3042472: Convert HandlerArgumentUserUidTest into a kernel test and clean up the surrounding code
• #3042540: Convert user RelationshipRepresentativeNodeTest into a kernel test
• #3042869: Convert UpdateDeleteFileIfStaleTest into a Kernel test
• #3042640: Convert TaxonomyFieldTidTest to a kernel test
• #3042877: Convert ArgumentValidatorTermTest into a Kernel test
• #3041081: Convert ConfigEntityImportTest to a kernel test
• #3041779: Convert LatestTranslationAffectedRevisionTest into a kernel test
• #3042536: Convert AccessPermissionTest into a Kernel test
• #3042538: Convert ArgumentDefaultTest into a kernel test
• #3042875: Convert TaxonomyIndexTidFilterTest into a Kernel test
• #3041055: Convert TaxonomyQueryAlterTest to a kernel test
• #3041837: Convert UserDataTest into a kernel test
• #2473681: Convert VocabularyCrudTest test to kernel test
• #3046680: Convert NewDefaultThemeBlocksTest into a Kernel test
• #3049637: Convert CommentUninstallTest into a Kernel test
• #3041790: Convert ViewsSqlExceptionTest to a kernel test
• #3049612: Merge ArgumentUserUIDTest & FilterUserUIDTest and convert them into a Kernel test
• #3046723: Convert HandlerFieldFieldTest into a Kernel test
• #3028712: Convert system MailTest into a Kernel test. Break its simpletest dependency

Won't fix:

• #3041813: Convert CacheTagTest into a kernel test
• #3045736: Convert ModuleInstallBatchTest into a Kernel test

Remaining tasks

None.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

N/A

Problem/Motivation

Since EntityOwnerTrait can be used as a default implementation of EntityOwnerInterface the owner can't be NULL anymore for media entities.

Therefore if you cancel a user you can't edit a media entity that was own by this user. The following error is thrown:

Drupal\Core\Entity\EntityStorageException: SQLSTATE[23502]: Not null violation: 7 ERROR: null value in column "uid" violates not-null constraint DETAIL: Failing row contains (188, 241, image, nl, 1, building-buildings-busy-297743_0.jpg, 442, car, null, 1000, 667, null, 1558535344, 1563353147, 1, 1).: INSERT INTO drupal_webshop_nl.media_field_data (mid, vid, bundle, langcode, status, name, thumbnail__target_id, thumbnail__alt, thumbnail__title, thumbnail__width, thumbnail__height, uid, created, changed, default_langcode, revision_translation_affected) 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, :db_insert_placeholder_10, :db_insert_placeholder_11, :db_insert_placeholder_12, :db_insert_placeholder_13, :db_insert_placeholder_14, :db_insert_placeholder_15); Array ( ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 847 of /var/www/html/src/core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).

(Captain Obvious Note: When updating the media entity if you add an owner no errors are thrown.)

I open this issue for people who need a temporary solution.
The issue Some content entities are missing hook_user_cancel implementations try to find a generic solution and could take a while.

Proposed resolution

The first proposed solution is a no-brainer: copy/paste what is done for node.

Remaining tasks

Find a quick win better than copy/paste while waiting for Some content entities are missing hook_user_cancel implementations

User interface changes

None

API changes

None

Data model changes

Media entities updated correctly on user cancel.

Problem/Motivation

Over at #3065545: [PP-1] Deprecate base theme fallback to Stable, we need to keep update path test coverage for functionality that is being deprecated in that issue.

Because extension discovery happens very early in the installer, the deprecations are triggered during extension discovery. The only way to avoid this was by using $settings['file_scan_ignore_directories'], which was not acceptable. So we set out to update the existing test coverage to not use a physical on-disk file (to avoid extension discovery discovering it and then triggering a deprecation error), but one that is stored in vfs.

In doing that, I stumbled upon some remarkable bugs in the existing test coverage: even though some of it uses vfs already, it apparently is mostly working by accident, because the test coverage just happens to be not exercising certain code paths.

It turns out that even though \Drupal\Core\Extension\Extension is aware of the app root it operates in, it does not respect this for file system operations. Which means that as soon as you call Extension::getMTime() for example (which Drupal core does), it always assumes PHP's current working directory instead of the specified app root. This works fine outside of tests (since PHP's working directory matches the app root), but it fails in case of unit tests.

• For example, \Drupal\Tests\Core\Extension\ExtensionListTest::setupTestExtensionList() does:
  

  $extension_scan_result[$extension_name] = new Extension($this->root, 'test_extension', "vfs://drupal_root/example/$extension_name/$extension_name.info.yml");
  

  This contains multiple bugs:

  1. The first parameter passes $this->root. This is provided by \Drupal\Tests\UnitTestCase::setUp() and set to $this->root = dirname(dirname(substr(__DIR__, 0, -strlen(__NAMESPACE__))));— so something like /Users/wim.leers/Work/d8. This is obviously not a virtual file system app root.
  2. The third parameter then contains a vfs://drupal_root/… prefix: this is the actual app root!
• Analogously, \Drupal\Tests\Core\Extension\ThemeExtensionListTest::testRebuildThemeDataWithThemeParents() does:

  'test_subtheme'  => new Extension($this->root, 'theme', $this->root . '/core/modules/system/tests/themes/test_subtheme/test_subtheme.info.yml', 'test_subtheme.info.yml'),
  

  While less obviously broken, this is also still wrong, because it is saying that it lives at /Users/wim.leers/Work/d8/Users/wim.leers/Work/d8/core/modules/system/tests/themes/test_subtheme/test_subtheme.info.yml: the app root is repeated.

This combination has happened to work okay so far because all extensions that were ever actually installed were not stored in vfs://. #3065545: [PP-1] Deprecate base theme fallback to Stable is the first to instal an extension from the virtual file system and is hence running into this bug.

Proposed resolution

I first thought we could not fix this separately from #3065545 because the bug only exists in test coverage. And writing test coverage for a test makes no sense.

However, I see an easier path forward now: adding development time-only validation logic by adding assert() statements to the \Drupal\Core\Extension\Extension constructor.

Remaining tasks

Review.

User interface changes

None.

API changes

None.

Data model changes

None.

Release notes snippet

None.

Problem/Motivation

jQuery Joyride was added to support tours. It is used in a Views tour and a welcome tour in Umami. However Joyride has not been maintained for the last 2 years. See https://zurb.com/playground/jquery-joyride-feature-tour-plugin and commit history at https://github.com/zurb/joyride

Proposed resolution

Consider replacing Joyride or remove altogether if we don't think its useful. The Umami team thinks it is useful and uses it.

Remaining tasks

Discuss.

User interface changes

TBD.

API changes

TBD.

Data model changes

TBD.

Release notes snippet

TBD.

I was doing view import, In between site shown "The website encountered an unexpected error. Please try again later."

While looking to error logs in web server it gives,
Error: Unsupported operand types in Drupal\views\Entity\View->mergeDefaultDisplaysOptions() (line 472 of modules/views/src/Entity/View.php).

Steps to reproduce

1. Create a custom entity
2. Install the custom entity
3. Add a map field (in baseFieldDefinitions) to the above entity
4. Try to install the new entity using an update hook

Thrown error:
Fatal error: Call to a member function isRequired() on a non-object in /var/www/html/.../core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorageSchema.php on line 1819

Call Stack:

• 0.0001 223840 1. {main}() /usr/local/bin/drupal:0
• 0.0148 1917048 2. require('phar:///usr/local/bin/drupal/bin/drupal') /usr/local/bin/drupal:10
• 0.0150 1943328 3. require('phar:///usr/local/bin/drupal/bin/drupal.php') phar:///usr/local/bin/drupal/bin/drupal:3
• 0.2460 7191848 4. Symfony\Component\Console\Application->run() phar:///usr/local/bin/drupal/bin/drupal.php:97
• 0.2485 7530088 5. Drupal\Console\Application->doRun() phar:///usr/local/bin/drupal/vendor/symfony/console/Application.php:123
• 0.8564 36435096 6. Symfony\Component\Console\Application->doRun() phar:///usr/local/bin/drupal/src/Application.php:280
• 0.8565 36435880 7. Symfony\Component\Console\Application->doRunCommand() phar:///usr/local/bin/drupal/vendor/symfony/console/Application.php:192
• 0.8603 36478536 8. Symfony\Component\Console\Command\Command->run() phar:///usr/local/bin/drupal/vendor/symfony/console/Application.php:860
• 0.8605 36480536 9. Drupal\Console\Command\Update\EntitiesCommand->execute() phar:///usr/local/bin/drupal/vendor/symfony/console/Command/Command.php:259
• 0.8686 36846752 10. Drupal\Core\Entity\EntityDefinitionUpdateManager->applyUpdates() phar:///usr/local/bin/drupal/src/Command/Update/EntitiesCommand.php:47
• 2.6319 69601832 11. Drupal\Core\Entity\EntityDefinitionUpdateManager->doEntityUpdate() /var/www/html/.../core/lib/Drupal/Core/Entity/EntityDefinitionUpdateManager.php:105
• 2.6319 69601832 12. Drupal\Core\Entity\EntityManager->onEntityTypeCreate() /var/www/html/.../core/lib/Drupal/Core/Entity/EntityDefinitionUpdateManager.php:210
• 2.6319 69601832 13. Drupal\Core\Entity\EntityTypeListener->onEntityTypeCreate() /var/www/html/.../core/lib/Drupal/Core/Entity/EntityManager.php:382
• 2.6320 69602432 14. Drupal\Core\Entity\Sql\SqlContentEntityStorage->onEntityTypeCreate() /var/www/html/.../core/lib/Drupal/Core/Entity/EntityTypeListener.php:71
• 2.6320 69603168 15. Drupal\Core\Entity\Sql\SqlContentEntityStorage->wrapSchemaException() /var/www/html/.../core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php:1357
• 2.6320 69603336 16. Drupal\Core\Entity\Sql\SqlContentEntityStorage->Drupal\Core\Entity\Sql\{closure}() /var/www/html/.../core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php:1452
• 2.6364 69715576 17. Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema->onEntityTypeCreate() /var/www/html/.../core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php:1356
• 2.6811 70216352 18. Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema->createDedicatedTableSchema() /var/www/html/.../core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorageSchema.php:276
• 2.6811 70216352 19. Drupal\Core\Entity\Sql\SqlContentEntityStorageSchema->getDedicatedTableSchema() /var/www/html/.../core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorageSchema.php:1102

Problem/Motivation

If I put more than 20 blocks or fields in a section and try to reorder it later, it doesn't save the correct order for the last few items. If I enable to display row weights there, I see that it only supports weights ranging from -10 to +10.

Proposed resolution

Increase the range.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

The jsonapi module offers an 'IN' operator for multiple values in a filter.
See fx https://www.drupal.org/docs/8/modules/jsonapi/filtering#s-4-filtering-wi...

This is equivalt to the SQL operator IN.
IN [a,b] means [either a or b].
SQL does not offer an operator to do [a and b] (what I call inclusive IN), but this can be accomplished with a join for each value (which the views module does for tags)

Can I do inclusive IN with jsonapi filters?

For example, say I want to get nodes that have both tag A and tag B (and maybe others) via field_tags.

The filter

filter[tag-filter][condition][path]=field_tags.id
filter[tag-filter][condition][operator]=IN
filter[tag-filter][condition][value][]=A
filter[tag-filter][condition][value][]=B

would return nodes that have either A or B.

ResourceTypeRepository::getFieldMapping is supposed to throw an exception if there is a naming conflict between a generated alias and a fieldname. That check does not work currently since it accesses the wrong variable ($field_name[$alias], but $field_name is the loop variable, a string).

What's more, I think the mapping must be unique in both directions since the ResourceType inverts the mapping (after filtering for string values).

Updated: Comment #212

Problem/Motivation

Inserting an image in the text editor dialog today allows the user to fiddle with image dimensions. It doesn't even have aspect ratio locking.

It's not great for the authoring experience nor for structured content reasons that users are defining the specific dimensions of every single image they insert. It'd be much better to allow them to choose from image styles — just like we do for image fields.

Proposed resolution

Allow an image style to be selected in the image dialog, which gets stored in a data-image-style attribute, and is handled by a yet-to-be-added imagestyle filter.

Remaining tasks

1. Initial patch: select image style in dialog, inserting that sets a data- attribute, and a filter transforms the end result.
2. Get #1589176-4: Follow-up: Use data-* to store #states api informations— a blocker to this patch — committed.

User interface changes

• The new ability to select an image style.
• A new filter.

API changes

None.

Related Issues

• #1932652: Add image uploading to WYSIWYGs through editor.module
• #1589176-14: Follow-up: Use data-* to store #states api informations
• #2123251: Improve DX of responsive images; convert theme functions to new #type element

Problem/Motivation

An old migration configuration, using migrate_plus and migrate_source_csv, used the following definition for migration dependencies. This old, malformed migration_dependencies broke all migrations. This is on 8.1.10 and latest versions of migrate_plus.

migration_dependencies:
  - csv_migrate_story

whereas it should have looked more like:

migration_dependencies:
  required:
    - csv_migrate_story

So, even though it wasn't related to the new migration, it caused the following exception, making me thing there was something wrong with the new migration:

TypeError: Argument 1 passed to Drupal\migrate\Plugin\MigrationPluginManager::expandPluginIds() must be of the type array, string given in             [error]
Drupal\migrate\Plugin\MigrationPluginManager->expandPluginIds() (line 138 of
/var/www/drupalvm/web/core/modules/migrate/src/Plugin/MigrationPluginManager.php).
TypeError: Argument 1 passed to Drupal\migrate\Plugin\MigrationPluginManager::expandPluginIds() must be of the type array, string given in /var/www/drupalvm/web/core/modules/migrate/src/Plugin/MigrationPluginManager.php on line 138
TypeError: Argument 1 passed to Drupal\migrate\Plugin\MigrationPluginManager::expandPluginIds() must be of the type array, string given in Drupal\migrate\Plugin\MigrationPluginManager->expandPluginIds() (line 138 of /var/www/drupalvm/web/core/modules/migrate/src/Plugin/MigrationPluginManager.php).

Proposed resolution

Give a more meaningful error message when migration_dependencies isn't structured correctly.

Remaining tasks

Code it.

User interface changes

n/a

API changes

n/a

Data model changes

n/a

Problem/Motivation

Currently there are three Installation Profiles: Minimal, Standard and Demo: Umami Food Magazine.

When you install a new Drupal site with the Standard profile, you get three user roles by default: Admin, Authenticated user (logged-in user when this issue is fixed) and Anonymous.

• Admin role: for site building and development purposes and comes with almost every existing permission by default.
• Authenticated/logged-in role: has the same permissions as the Anonymous user (viewing content) plus is able to post comments.
• Anonymous role: for visitors to the site not logged in.

Drupal is a content management system but we don’t have any default user role for creating, editing or managing content.

Proposed resolution

Based on our discovery, this proposal aims to create an out-of-the-box editor role to serve Drupal’s main purpose: manage content.

We propose that this new role is named “Content Editor.”

Installed with the standard profile, this new role will be created with a new set of permissions and options. Our initial proposal for this set is:

• Create and edit new content — articles and pages
• Use the basic HTML text format
• View unpublished content
• Create and edit terms (tags and categories)
• Access the administration theme

Remaining tasks

• Agree on the name and machine name for the new role
• Define the new set of permissions
• Create a patch
• Code Review
• Create tests?

User interface changes

• Roles and permissions screen:
  • Content Editor role will be included.
  • The new permissions for the role will be checked.
• Edit or Create user screens should include the Content Editor role in the options to select the role(s).

API changes

No changes to existing API changes?

Data model changes

No changes to existing data models?

Problem/Motivation

While implementing the new design system, the team raised some interest in using some of the new CSS features (mainly CSS custom properties or CSS variables). Being able to leverage these new features would lead to less overhead in the maintenance.

For example, CSS custom properties are currently supported by latest browser versions, while some older browsers are lacking support (browser support matrix). However, with the usage of CSS preprocessor, we could already reliably use CSS custom properties.

Proposed resolution

Use PostCSS to compile a version of our CSS that is supported by the browsers Drupal currently support. PostCSS is used by industry leaders including Wikipedia, Twitter, Alibaba, and JetBrains. PostCSS has over 20 000 stars in Github and is being used by almost 2 million projects according to Github.

Plugins we are currently using:

• Autoprefixer is a plugin to parse CSS and add vendor prefixes to CSS rules using values from Can I Use. It is recommended by Google and used in Twitter and Alibaba.
• PostCSS Calc reduces calc() references whenever it's possible. This can be particularly useful with the PostCSS Custom Properties plugin.
• PostCSS Custom Properties lets us use Custom Properties in CSS, following the CSS Custom Properties specification.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet

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

See #3042745: Remove group @legacy from jsonapi tests and fix deprecation messages and [#32450793], I don't fully understand yet how this all works together but I assume by overwriting the user name *field* with the label/display name can result in overwriting the actual username if that data is saved back.

I'll see if I can create a failing test to show the problem.

Proposed resolution

Not sure, but maybe the display name could be exposed as a separate thing that is explicitly read-only?

Would need to be BC somehow, of course unless we define that the current behavior is simply a bug that must be fixed.

Remaining tasks

User interface changes

API changes

Data model changes

Release notes snippet