drupal 9.0 core/aggregator module has deprecated code
Call to deprecated constant REQUEST_TIME: Deprecated in Drupal:8.3.0 and is removed from drupal:9.0.0. Use
\Drupal::time()->getRequestTime();
↧
Aggregator drupal core module has depricated code
↧
JSONAPI documentation lacks crosslink and security details
https://www.drupal.org/docs/8/modules/jsonapi/what-jsonapi-doesnt-do tells you how to log in with a user / password without basic auth.
The sub pages of https://www.drupal.org/docs/8/modules/jsonapi/get-post-patch-and-delete do not mention this. And, since they have the auth section three times instead of putting it there once I didn't want to go in and attempt to fix. Besides mentioning the existence, it should also be mentioned that curl -b needs to be used, just repeating the -c from the login example doesn't work.
The filtering section seems to imply the security is done by the querying party but it's not so, there's a lot of security going on and when logged in as above then the results change. This needs to be documented, again with curl -b examples. Maybe just create an authentication page and link it from everywhere?
↧
↧
t() calls should be avoided , use $this->t() instead in System module
t() calls should be avoided in classes, use dependency injection and $this->t() instead in DateFormatFormBase.php , SiteInformationForm.php , SiteMaintenanceModeForm.php files.
↧
Trying to access array offset on value of type null in _batch_finished()
There is a logical error in _batch_finished() resulting in accesing NULL as an array
PHP7.4:
Trying to use values of type null, bool, int, float or resource as an array (such as $null["key"]) will now generate a notice.
See https://www.php.net/manual/en/migration74.incompatible.php#migration74.i...
Issue is here:
$_batch = $batch;
$batch = NULL;
// Clean-up the session. Not needed for CLI updates.
if (isset($_SESSION)) {
unset($_SESSION['batches'][$batch['id']]);
if (empty($_SESSION['batches'])) {
unset($_SESSION['batches']);
}
}
$batch is always NULL !
↧
InvalidArgumentException: Placeholders must have a trailing [] if they are to be expanded with an array of values. in Drupal\Core\Database\Connection->expandArguments() when updating the database to 8.6.x
When I try to update Drupal from 8.4.0 to 8.6.1 I got the following error
Module Views
Updating table_display_cache_max_age
Fail: InvalidArgumentException: Placeholders must have a trailing [] if they are to be expanded with an array of values. in Drupal\Core\Database\Connection->expandArguments() (line 729 of /http/xxx/site/core/lib/Drupal/Core/Database/Connection.php).
↧
↧
dblog_update_8600() breaks views.view.watchdog config entity, leading to PHP warning on admin/reports/dblog and configuration import errors
Problem/Motivation
dblog_update_8600() only runs properly on sites where English is the default language.
Where English is not the default language, it doesn't update the view properly, and you get errors on the admin/reports/dblog
Proposed resolution
Add a new post update to set the correct value for the 'empty text' on the dblog view, regardless of the default language.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
↧
Replace @expectedException* annotations with dedicated methods
Problem/Motivation
The @expectedException, @expectedExceptionCode, @expectedExceptionMessage, and @expectedExceptionMessageRegExp annotations are deprecated. They will be removed in PHPUnit 9. Refactor your test to use expectException(), expectExceptionCode(), expectExceptionMessage(), or expectExceptionMessageRegExp() instead.
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
↧
Hide and disable Drupal Migrate Multilingual
Problem/Motivation
Once the multilingual migration path is fully stable (#2208401: [META] Stabilise Migrate Drupal Multilingual module ), we have no need for the separate Migrate Drupal Multilingual module.
Proposed resolution
Hide the module from the UI, disable it and let migrate discover multilingual migrations normally.
Remaining tasks
Hide migrate_drupal_multilingualAdd hook to uninstall itAdd followup to remove module in Drupal 9.- Review change record
- Answer questions in #22 and #23
- Commit it once #2208401: [META] Stabilise Migrate Drupal Multilingual module is done.
User interface changes
No more Migrate Drupal Multilingual module visible.
API changes
None. We keep the module for backwards compatibility.
Data model changes
↧
Configuration language being overwritten during module install
Problem/Motivation
Steps to reproduce
- Fresh install (in english)
- Enable the locale and language modules.
- Add a language (dutch in my case)
- Make the newly added language standard language
- Enable a module which provides default config (book module for example)
Note that this bug only occurs if the default language or the fallback language is not English.
Result
In the UI, you will see some English instead of Dutch on various pages that load configuration.
In the database:
- The base config items in the config table now have a langcode element in them, telling Drupal they are in Dutch not English.
- So when you try to load config, the base config thinks it is Dutch (even though the text is English), and the config overrides (which are still in the config database) are not being loaded to translate the English into Dutch.
Expected result
The English configuration is interpreted as english config, not Dutch, and the config translation overrides are used when viewing the site in Dutch.
Related issues
This issue seems fairly similar to #2468767: English config source strings are saved as custom translations in locale in foreign install .
Also, UI text gets overridden when modules are installed. This issue is about config being mangled; the UI text problem is a separate issue: #2806009: Installing a module causes translations to be overwritten.
Proposed resolution
There was some debugging done; probably the cause is described in #6 / #11 / #14
There was a test-only patch in #5 but it's really for the related UI text issue, not the config text issue.
Remaining tasks
Make a patch, including a test.
User interface changes
Configuration language will not be changed to an inappropriate language.
API changes
None.
Data model changes
None.
↧
↧
Decouple Classy-inheriting themes from Classy's preprocess functions
Problem/Motivation
As mentioned in #3050389: Remove dependency to Classy from core themes, Classy will be moved to contrib before Drupal 9 and we have to remove dependencies on Classy from all core themes. Part of removing these dependencies includes providing each theme their own copies of Classy's preprocess functions, provided they are relevant to the theme.
These are the three functions that need to be decoupled in Claro, Seven, Bartik and Umami
function classy_preprocess_links__media_library_menu(array &$variables) {
foreach ($variables['links'] as &$link) {
$link['link']['#options']['attributes']['class'][] = 'media-library-menu__link';
}
}
function classy_form_alter(array &$form, FormStateInterface $form_state, $form_id) {
$form_object = $form_state->getFormObject();
if ($form_object instanceof ViewsForm && strpos($form_object->getBaseFormId(), 'views_form_media_library') === 0) {
$form['#attributes']['class'][] = 'media-library-views-form';
}
}
function classy_preprocess_image_widget(array &$variables) {
$data = &$variables['data'];
if (isset($data['preview']['#access']) && $data['preview']['#access'] === FALSE) {
unset($data['preview']);
}
}
Proposed resolution
For each Classy inheriting theme, determine if each Classy preprocess function is relevant to the theme. If it is relevant, copy it to the theme and make changes where necessary so it functions identically and does not result in regressions or redundant functionality such as adding the same class multiple times.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
↧
[META] Make Umami theme non-dependent on Classy
As stated in #3050389: Remove dependency to Classy from core themes, Classy will be moved to contrib before Drupal 9 and we have to remove dependencies on Classy from all core themes.
This meta issue will keep track of all the Umami-specific issues regarding this change.
This is process will largely consist of making Umami-specific copies of libraries and templates that were previously inherited from Classy. The specific Classy resources that Umami depends on is documented in this spreadsheet.
Library dependency issues
#3096203: Create Classy library dependency tests that can be used for all themes, and verify by providing an Umami-specific classy/dropbutton
#3106600: Decouple Classy libraries from Umami
Template dependency issues
↧
Create test for confirming Themes do not depend on Classy templates
Problem/Motivation
As mentioned in #3050389: Remove dependency to Classy from core themes, Classy will be moved to contrib before Drupal 9 and we have to remove dependencies on Classy from all core themes. Part of removing these dependencies includes providing each theme their own copies of templates that previously belonged to Classy.
There's considerable potential for error when copying ~100 templates to four different themes, so we need a test that removes some of the uncertainty from the process.
Proposed resolution
Create a test that confirms that themes do not inherit templates from Classy, and that none of the templates they use include/extend Classy templates or attach Classy libraries.
The test will include a per-theme ignore-list of templates that do not need to be included as part of the test. At first, the ignore-lists will be very large, and will shrink with each template-copying issue filed. When a new template-copying issue is filed (for example, copy aggregator templates to Bartik), the first patch will be this test, but with aggregator's templates removed from Bartik's ignore list. This way, the test won't pass until the templates are properly copied.
Every Classy-inheriting core theme currently extends, includes or attaches something from Classy, so these tests will not pass at first.
Remaining tasks
Write the test, configured it to ignore templates that still need to be copied.
Create issues to address existing attach_library() calls to Classy libraries in Bartik/Seven/Claro/Umami, as these will cause the test created here to fail.
- Umami calls
{{ attach_library('classy/node') }}in node--article--full.html.twig, node--card--common.html.twig, node--card.html.twig, node.html.twig - Bartik calls
{{ attach_library('classy/node') }}in node.html.twig - Claro calls
{{ attach_library('classy/file') }}in file-link.html.twig - Seven calls
{{ attach_library('classy/image-widget') }}in image-widget.html.twig
These library-copying followup issues can't be created until #3096203: Create Classy library dependency tests that can be used for all themes, and verify by providing an Umami-specific classy/dropbutton is complete.
The Classy template include/require's should be addressed in the scope of this issue as this is where the test exists to verify they were done properly. This needs to be addressed with the following:
- Bartik
{% extends ""@classy/block/block--search-form-block.html.twig"" %}in block--search-form-block.html.twig - Bartik
{% extends "@classy/block/block--system-menu-block.html.twig" %}in block--system-menu-block.html.twig - Bartik
{% extends "@classy/content/page-title.html.twig" %}in page-title.html.twig - Bartik
{% extends "@classy/misc/status-messages.html.twig" %}in status-messages.html.twig - Seven
{% include '@classy/content-edit/image-widget.html.twig' %}in image-widget.html.twig - Claro
{% extends '@classy/form/form-element-label.html.twig' %}in form-element-label.html.twig
The template copying can't happen until #3095713: Create classy directory with README, in the templates and css directories for all themes subtheming Classy is complete
User interface changes
n/a
API changes
n/a
Data model changes
n/a
Release notes snippet
n/a
↧
[META] Remove dependency to Classy from core themes
Problem/Motivation
Classy will be moved to contrib during Drupal 9. In preparation to that, we have to remove dependencies on Classy from all core themes.
Proposed resolution
Use this spreadsheet of Core Theme's use of Classy as reference
Create theme-specific versions of all libraries that are not already overridden by the theme.
Copy all remaining Templates and CSS that are not already overridden by the theme and remove dependency to Classy. Some templates in Classy are identical to Stable and can be removed instead of copied. This is covered by #3098150: Add test coverage to ensure Classy templates that have identical versions in Stable are kept in sync
Themes subtheming Classy should not depend on preprocess/alters in classy.theme. The issue for this is: #3109287: Decouple Classy-inheriting themes from Classy's preprocess functions
Theme specific issues:
Claro: #3084810: Decouple Claro from Classy, #3108109: Decouple Classy libraries from Claro
Umami: #3096014: [META] Make Umami theme non-dependent on Classy
Seven: #3107872: Decouple Classy libraries from Seven
Bartik #3108181: Decouple Classy libraries from Bartik
Remaining tasks
- Determine directory structure for copied templates: #3095713: Create classy directory with README, in the templates and css directories for all themes subtheming Classy
- Create test process for copying libraries: #3096203: Create Classy library dependency tests that can be used for all themes, and verify by providing an Umami-specific classy/dropbutton
- Create test process for copying templates: #3096349: Create test for confirming Themes do not depend on Classy templates (currently blocked on #3106600: Decouple Classy libraries from Umami and other yet-to-be-created issues for decoupling Classy libraries from themes)
- Remove Classy templates with identical copies in Stable: #3098150: Add test coverage to ensure Classy templates that have identical versions in Stable are kept in sync
Once the test procedure and directory naming is settled, create multiple issues for moving templates/libraries to themes. Consider grouping similar templates in an issue to reduce the total number of issues, but the scope should remain reasonable for each.
User interface changes
API changes
Data model changes
Release notes snippet
↧
↧
Decouple Stable libraries from Bartik/Seven/Claro/Umami
Problem/Motivation
As stated in #3110855: Plan for removing dependency to Stable in Bartik/Seven/Claro/Umami, Bartik/Seven/Claro/Umami will be decoupled from Stable. This includes the two libraries provided by Stable, which extend existing core libraries.
drupal.ajax:
version: VERSION
js:
js/ajax.js: {}
drupal.user:
version: VERSION
js:
js/user.theme.js: {}
libraries-extend:
core/drupal.ajax:
- stable/drupal.ajax
user/drupal.user:
- stable/drupal.user
stable/drupal.ajax added in #3059847: Move hard coded AJAX progress bar classes to a theme function
stable/drupal.user added in #3061265: Use specific class for password confirm message
Proposed resolution
Make core versions of stable/drupal.ajax and stable/drupal.user.
Configure Bartik/Seven/Claro/Umami to extend core/drupal.ajax and user/drupal.user with these libraries, and override stable/drupal.ajax and stable/drupal.user to false.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
↧
Create test for theme asset decoupling from Stable
Problem/Motivation
Part of #3110855: Plan for removing dependency to Stable in Bartik/Seven/Claro/Umami includes determining what templates/css will function the same without Stable, and a way to confirm a theme has properly decoupled from these assets
Proposed resolution
Create a test that filters assets that will work identically were Stable removed, and checks the remaining assets to determine if they're inherited from Stable
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
↧
[PP-1] Drop support for Node.js 8
Problem/Motivation
Node.js 8 is EOL since the end of 2019. Node.js is only used by our development tooling.
Proposed resolution
Drop support for Node.js 8. Require 10.18.0 instead which is the oldest supported version.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
↧
Select All media option is missing while adding media in Grid view
1. Add the media as a reference field in the Basic Page content type.(Allow unlimited)
2. Add basic page content.
3. While adding a basic page in the media section click Add Media.
Select all media checkbox is missing media library popup.
↧
↧
[policy] Decide on MySQL/MariaDB/Percona Server version support status for Drupal 9
Problem/Motivation
Drupal requirements list the following MySQL/MariaDB/Percona requirements currently:
Required MySQL 5.5.3/MariaDB 5.5.20/Percona Server 5.5.8 or higher with InnoDB as the primary storage engine, and requires the PDO database extension. MySQL 8 is supported only on Drupal 8.6 or higher.
Decide on Drupal 9 requirements changes if any.
Distros
- Debian
- 9 (17th june 2017): Ships with MariaDB 10.1.41 & MySQL 5.6.47
- 10 (6th july 2019): Ships with MariaDB 10.3.18 & MySQL 5.7.29 and 8.0.19
- Ubuntu
- 16.04 (21 th april 2016): Ships with MariaDB 10.0.24 & MySQL 5.7.29 and 8.0.19
- 18.04 (26th april 2018): Ships with MariaDB 10.1.29 & MySQL 5.7.29 and 8.0.19
- 20.04:
- Red Hat Enterprise Linux
- 6 (10th november 2010): Ships with No MariaDB & MySQL 5.5.73
- 7 (10th june 2014): Ships with MariaDB 5.5.64 & MySQL 5.6.47
- 8 (7th may 2019): Ships with MariaDB 10.3.17 & MySQL 8.0.19
Databases
- MySQL
- 5.6 released on 5th february 2013
- 5.7 released on 21th october 2015
- 8.0 released on 19th april 2018
- MariaDB
- 5.5 released on 25th february 2012
- 10.1 released on 30th june 2014
- 10.2 released on 18th april 2016
- 10.3 released on 16th april 2017
- 10.4 released on 9th november 2018
Proposed resolution
TBD.
Remaining tasks
Discuss.
User interface changes
None.
API changes
TBD.
Data model changes
TBD.
Release notes snippet
TBD.
↧
Duplicate path aliases can be added
When adding aliases through the admin interface, there is a validation check (function aliasExists) to make sure you are not reusing an existing alias. Strangely the function does not prevent you from making a duplicate alias.
To reproduce, go to /admin/config/search/path/add and add an alias with a source. Then do it again (same alias, same source).
If you use different sources you will be stopped from reusing an alias, but nothing stops you from adding a duplicate. Why allow that?
↧
Add copies of Classy templates to core themes
Problem/Motivation
To remove dependency to Classy, we need to ensure core theme aren't relying on any markup in Classy. #3096349: Create test for confirming Themes do not depend on Classy templates has added test coverage to ensure that markup isn't being inherited from Classy. Currently, lots of templates have been added as ignored.
Proposed resolution
Ensure all templates have been removed from the skip lists, and copies of those templates exist in core themes.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
↧