image-widget.css CSS file of bartik, classy and seven theme is not used in theme (Classy). It was intended to be used,but due to a bug, Drupal 8 shipped with it not being used. To not breakbackwards compatibility, continue to not load it in Classy. Everysubtheme of Classy is encouraged to use it, by attaching the classy/image-widget asset library in their image-widget.html.twig file.
↧
Attach the classy/image-widget asset library in core/themes/classy/templates/content-edit/image-widget.html.twig
↧
Deprecate \Drupal\Core\Database\Database::getDatabaseDriverNamespace as it is no longer needed
Problem/Motivation
\Drupal\Core\Database\Database::getDatabaseDriverNamespace() supports D7 arrays - that's not necessary.
Proposed resolution
Deprecate the method.
Remaining tasks
User interface changes
API changes
\Drupal\Core\Database\Database::getDatabaseDriverNamespace() is deprecated and will be removed in D10.
Data model changes
Release notes snippet
↧
↧
Create a tool to convert a non-Composer-based Drupal to a Composer-based one
This is a child issue of #2982674: [meta] Composer Initiative Phase 1: Add composer build support to core
Problem/Motivation
Given a normalization to Composer-based site building, we need a tool to convert non-Composer-based sites into Composer-based ones.
We're targeting 'tarball' style installs, which have downloaded Drupal from the download page of drupal.org, and have then installed in place.
We want a core-native tool which can be easily used to reliably make a composer.json file, ideally without much user intervention.
Proposed resolution
Since Drupal tarball downloads will be Composer-ready out of the box, and updating a Drupal site via drush pm-update essentially involves swapping out (parts of) your current code with the latest tarball download, so for folks who do not have any contrib modules, converting to Composer-managed will be a simple matter of running "composer update". Folks who do have contrib modules will need their composer.json adjusted post-update.
There are three stages:
- Validate: The site must be using
drupal/core-composer-scaffold, and must have contrib modules on disk that are not listed in the composer.json file. (If either of these things is not true, then the tool does nothing.) - Prompt: In a Composer pre-update script (or perhaps post-update), conspicuously warn the user that: a) they cannot go back and use `drush pm-update` any longer, and b) their existing contrib modules will be added to their composer.json file (if available on Packagist).
- Convert: If the user confirms, run a version of composerize-drupal ported into drupal/drupal project. If they decline, print a warning that `composer update` is not updating their contrib modules.
composerize-drupal is already a Composer plugin, so it probably will not need a lot of work to convert it to this workflow. If we add it to the composer/Plugins directory, then it will be subtree split into a separate component, and can be added to drupal/legacy-project, where it will also become part of the tarball downloads. (Alternately, we could consider adding it during the tarball bundling process, since this tool is not necessary for sites created via composer create-project drupal/legacy-project.)
Remaining tasks
- [ ] Port grasmash/composerize-drupal to composer/Plugins directory.
- [ ] Remove functionality of composerize-drupal' that is no longer necessary (replacement of root composer.json with a template version, relocation of files to "web" directory, etc., where such things have already been provided by the Composer-ready download).
- [ ] Warn the user at `composer update` time that they've started out on a one-way trip.
- [ ] List contrib modules converted, add them to composer.json, remove them from repository in their old location,
- [ ] Optional. Remove the conversion plugin after it has converted the contrib modules.
Follow-on tasks
There are other things that folks might wish to do that could be handled in follow-on work.
- Convert from older Composer-managed template projects (e.g. drupal-composer/drupal-project sites still using drupal-composer/drupal-scaffold).
- Convert from drupal/legacy-project layout to drupal/recommended-project layout.
- Add a rational .gitignore file, perhaps assuming vendor is committed, or perhaps assuming it is not. Remove any ignored files that are currently committed to the repository.
- Convert a non-Composer-managed site to a Composer-managed site without updating the version of Drupal Core or contrib modules used (perhaps even for pre-8.8.0 versions, although most likely only Composer-ready sites will be supported at first).
User interface changes
None.
API changes
None.
Data model changes
None.
Release notes snippet
↧
Take out theme override for views listing table
↧
Off canvas filling up localStorage's quota, causing errors
Problem/Motivation
In #2952390: Off-canvas styles override CKEditor's reset and theme, a patch was committed that uses localStorage to cache previously processed CSS files. The localStorage key is based on the full path to the CSS file, including the query param, i.e. Drupal.off-canvas.css.http://drupal.localhost/core/assets/vendor/ckeditor/skins/moono-lisa/editor.css?t=pv9p89http://drupal.localhost/core/assets/vendor/ckeditor/skins/moono-lisa/dialog.css?t=pv9p89. If a user visits a site enough times without clearing their browser's localStorage, their browser's localStorage limit (on mine it's 5MB) will have been met, which throws an error like:
Failed to set the [...] property on 'Storage': Setting the value of [...] exceeded the quota.
Proposed resolution
Expire older items from the localStorage cache, or stop using localStorage for this use case. The CSS file for CKEditor could be quite large so putting it all in localStorage doesn't seem efficient.
Remaining tasks
Determine a path forward and write a patch.
User interface changes
None.
API changes
None.
Data model changes
None.
Release notes snippet
None.
↧
↧
egulias/EmailValidator allows addresses without TLDs
Hi,
There's a problem with the service "email validator" that considers "test@test" like a valid email address. But the address is invalid because there no top level domain.
Best Regards
↧
Add countSession for a user in SessionManager
Problem/Motivation
I noticed while working on a contrib module that it would be good, if it would be possible to fetch the count of open sessions for a single user.
The module creates locks for content, so only a single user can edit it. The idea here now is that when user logs out it should remove open locks. As a user can log in to multiple browser and can have multiple sessions, it needs to make sure that this is the last open session.
As a workaround in content_lock following is used:
// Only do the database check if the original drupal session manager is used.
// Otherwise its not sure if sessions table has correct data. As it would be
// a common practice to extend the Class, instanceof is not used here!
if (get_class(Drupal::service('session_manager')) == \Drupal\Core\Session\SessionManager::class) {
$query = \Drupal::database()
->select('sessions');
$query->condition('uid', $account->id());
$query = $query->countQuery();
$session_count = (int) $query->execute()->fetchField();
}
See FR #2937733: Remove locks on user log out
Proposed resolution
Add new method for counting the open sessions to SessionManager
Remaining tasks
- Add new method
- Add tests
User interface changes
None
API changes
Add new countSession() method to SessionManager
Data model changes
None
↧
Log errors for missing route_name in Drupal\Core\Menu\LocalTaskManager->getLocalTasksForRoute()
After updating to the latest dev release and also 8.x-1.12, I receive this notice on almost all pages of my site:
Notice: Undefined index: route_name in Drupal\Core\Menu\LocalTaskManager->getLocalTasksForRoute() (line 240 of core/lib/Drupal/Core/Menu/LocalTaskManager.php).
↧
Move cursor to new line after image insert in CKEditor
Immediately after inserting a new image via the CKEditor to the editor, the image remains selected by default and prevents users from start typing right away.
It'd be great if the active cursor would move a line below so that users can start typing without having to do anything. As of now, users need to hit the down-arrow key to move it to new line or click to start typing.
↧
↧
Add getter for layout object in Layout Builder's ConfigureSectionForm
Problem/Motivation
Modules that want to modify the section configuration form in layout builder may have a hard time, because there's no way to retrieve the layout plugin object. Contrib needs access to the plugin object so it can save configuration for it.
Proposed resolution
Add public getters for retrieving the layout and section, like we already did for the block configuration form in #3003666: Provide access to a Section or SectionComponent from within a $form_state
Remaining tasks
Needs tests
User interface changes
N/A
API changes
No
Data model changes
No
Release notes snippet
↧
$formatTranslationCache in DrupalDateTime class should be array
Problem/Motivation
Wrong variable type declaration of DrupalDateTime class's $formatTranslationCache property.
/**
* Format string translation cache.
*
* @var string
*/
protected $formatTranslationCache;
Following is the relevant code snippet from the same class's format() method:
// Translates a formatted date string.
$translation_callback = function ($matches) use ($langcode) {
$code = $matches[1];
$string = $matches[2];
if (!isset($this->formatTranslationCache[$langcode][$code][$string])) {
$options = ['langcode' => $langcode];
if ($code == 'F') {
$options['context'] = 'Long month name';
}
if ($code == '') {
$this->formatTranslationCache[$langcode][$code][$string] = $string;
}
else {
$this->formatTranslationCache[$langcode][$code][$string] = $this->t($string, [], $options);
}
}
return $this->formatTranslationCache[$langcode][$code][$string];
};
↧
Sub-themes wrong documentation description for libraries.yml - component: vs theme: - error Incomplete library definition
Moderator,
please remove this issue.
Sorry.
↧
Fix remaining @Deprecated layout manually and enable the coding standard
Problem/Motivation
This is a follow-on from #3048498: [≈Nov. 11] Fix Drupal.Commenting.Deprecated coding standard where the automated patch fixed 653 of the 675 @deprecated messages reported under the Drupal.Commenting.Deprecated.IncorrectTextLayout sniff.
Remaining tasks
Commit the first huge automated conversion chunk- Follow-up with patches to fix the rest (manually)
- Enable the new Drupal.Commenting.Deprecated in phpcs.xml
↧
↧
[PP-1] The 'Update' page has no idea that some updates are incompatible
Problem/Motivation
The form to actually install pending updates at /admin/reports/updates/update has no notion that some of the available updates are incompatible with your currently installed version of core, and will happily try to download and install them for you. I haven't actually tested what happens, but it seems seriously problematic to leave it as is.
Splitting this off from
#3102724: Improve usability of core compatibility ranges on available updates report
#3096078: Display core compatibility ranges for available module updates
...
For example, with the latest screenshots from #3102724, on a test site setup to believe it's 8.7.10 core, we'd see this:
Compare that with the "Update" page on the same site:
No indication at all that redis 8.x-1.4 (the "Recommended release") won't install on your current version of core (which you still have to manually update, unlike all the contrib updates this form would (try to) install for you...
Proposed resolution
- Harvest some of the compatibility-awareness from #3102724: Improve usability of core compatibility ranges on available updates report and use it on this other page/form, too. YES
- Add similar
Compatible /Not compatible details elements. YES, but to avoid too much noise, only show details for "Not compatible" Disable checkboxes on incompatible updates?NO- Move rows with incompatible releases into the bottom table ("Manual updates required")
- Figure out the latest release we could safely upgrade to and call that the recommended release for this form? E.g. given the current scenario from the screenshots, at least the redis 8.x-1.3 release could be installed on that site... - Nah, punt to follow-up.
Remaining tasks
Decide what to do.- Land #3102724: Improve usability of core compatibility ranges on available updates report so we have the new code we need to make this work.
- Implement proposed resolution.
- Reviews.
- ...
User interface changes
TBD
API changes
TBD. Probably nothing public. Perhaps some changes to protected/internal APIs inside update.module and friends.
Data model changes
TBD, probably none.
Release notes snippet
TBD.
↧
Element inside form-item can cause overflow
Elements inside a form-item can cause unwanted overflow to happen (see screenshot).
Path: admin/content
Patch follows.
↧
For core updates, link to list instead of update form
Problem/Motivation
This issue is a follow-up to #3110186: Simplify the wording of messages on the status report about security coverage for the site's installed minor version.
The "Drupal Core Update Status" message on the Status report (/admin/reports/status) has up to two links (the summary line and the text "available updates") to the form at /admin/reports/updates/update. These links are not helpful because Drupal core cannot be updated from that form.
Proposed resolution
Link instead to the list at /admin/reports/updates, the primary tab on the same page as the form.
Remove the text "and to install your missing updates".
Remaining tasks
User interface changes
This will change up to two links (target, not text) on the Status report and remove the text "and to install your missing updates".
API changes
None
Data model changes
None
Release notes snippet
Not needed unless this issue is promoted to Major.
↧
Remove Layout Builder's hard dependency on Field UI
Problem/Motivation
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
↧
↧
Unknown Field randomly occured
Hello,
In my application running on Drupal 8.7 and PHP 7.2 i have random errors of "Unknown field", bellow the error i'm seeing in my logs :
Field XX is unknown." at /var/www/core-model/web/core/lib/Drupal/Core/Entity/ContentEntityBase.php line 587
The field exist in a taxonomy term, when the error occure i go to "Manage Fields" of the Taxonomy and i can't find the field and after refreshing the cache (i'm using Redis cache) the problem is solved and the field come back again.
I can't reproduce the bug because it's so random with no apparent pattern !
The bug started to show after upgrading to Drupal 8.7.
Can you help me please
↧
Migration is busy with another operation
Problem/Motivation
Got this errors:
Migration d7_node_revision__page is busy with another operation: Importing
Migration d7_field_formatter_settings is busy with another operation: Importing
Migration d7_comment is busy with another operation: Importing
Import of Drupal 7 comments failed
Imported Drupal 7 comment type
What does this mean?
Proposed resolution
Remaining tasks
User interface changes
None
API changes
None
Data model changes
None
↧
Progress throbber position is incorrect
Problem/Motivation
Progress throbber position and styling are incorrect while viewing in table display as compared with other displays.
Steps to replicate
Example:
1. Go to admin/structure/block and click on place block to check the throbber effect.
2. After that click on the place block button from place block modal popup form and check the throbber effect.
See the below screenshots
↧