Currently, we can filter a view based on the current viewed user or node entity's uid.
There is a lot of contribs which define entity classes extending Drupal\Core\Entity\ContentEntityBase class. So, they all have getOwnerId() method. For example, commerce module which has product and stores entities or profile module's profile entity.
Suggestion: allow those entities to use "User ID from route context" contextual filter.
There are different precision limits for fields of the numeric type:
- PostgreSQL has a limit of 1000;
- MySQL has a limit of 65;
- Oracle has a limit of 38.
Still, testSchemaAddFieldDefaultInitial tries to test database for numeric fields with 40 and 65 precision limits.
#2867788: Log::findCaller fails to report the correct caller function with non-core drivers. added \Drupal\Core\Database\Log::getDriverNamespace() but this method will exist only until #3112476: Deprecate \Drupal\Core\Database\Database::getDatabaseDriverNamespace as it is no longer needed lands. Therefore lets make it private so we can remove it without breaking anything. As this method and property only exist in 8.9.x this is fine.
Do it.
None
None
None
N/a
In many projects - specifically when entity forms are displayed on front end - default messages from Node module are not relevant to contributors and should not be displayed.
Currently there is no easy way to alter messages displayed after a Node entity was saved.
As a site admin, I want to be able to disable the default "overcomplicated" messages displayed after Node save (currently, something like Article "Title of the article" has been updated).
As a developer, I want to be able to do custom things during Node save - e.g. display custom messages.
We should :
- add an option to enable/disable message display on save. Since website can have many different node types, we should add this option on the NodeType entity.
- add the opportunity to developper to alter things during NodeForm::save();. Until Event triggers are implemented in Entity's operations/forms, I suggest to add a custom hook.
New option in NodeType admin form.
None.
Issues:
Forum post about these messages:
FILE: /var/www/html/drupal_core/core/modules/action/src/ActionListBuilder.php
-----------------------------------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 3 WARNINGS AFFECTING 3 LINES
-----------------------------------------------------------------------------------------------------------------------
90 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and
| | $this->t() instead
91 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and
| | $this->t() instead
102 | WARNING | t() calls should be avoided in classes, use \Drupal\Core\StringTranslation\StringTranslationTrait and
| | $this->t() instead
FILE: /var/www/html/drupal_core/core/modules/aggregator/src/Controller/AggregatorController.php
-----------------------------------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
-----------------------------------------------------------------------------------------------
128 | WARNING | Unused variable $next.
The documentation for hook_node_access() states that the first argument $node can be NodeInterface object or a string:
\Drupal\node\NodeInterface|string $node: Either a node entity or the machine name of the content type on which to perform the access check.
If this is correct then the function stub provided in node.api.php is incorrect, because it accepts only a NodeInterface argument and will throw an exception if a string is passed:
function hook_node_access(\Drupal\node\NodeInterface $node, $op, \Drupal\Core\Session\AccountInterface $account) {
$type = $node
->bundle();
// ...
}
This should be changed to check whether $node is an instanceof NodeInterface, and then determine $type accordingly.
Alternatively, if it can only ever be NodeInterface then the documentation is wrong and the part about it being a string should be removed.
I'm happy to make this change but I do not know what the real behaviour is. Can hook_node_access() really be invoked with a string argument? All the contrib modules I have looked at assume that $node will be a Node object because they have copied the example code.
In #3107113: [policy] Decide on MySQL/MariaDB/Percona Server version support status for Drupal 9 the general direction of raising MySQL requirements to 5.7 and MariaDB requirements to 10.2 was agreed on.
Raise version requirements.
It was discussed that this may require resolving #2985788: Add a separate MariaDB driver first, but that does not seem to be the case.
Raise version requirements.
Update documentation.
None.
None.
None.
Raised the minimum MySQL version to 5.7 and MariaDB version to 10.2 in Drupal 9.
There are three types of buttons supported in core and in the Seven style guide. Standard, primary, and danger.
It's important that the correct button types are used consistently throughout Drupal
The ultimate goal of this issue is to remove \Drupal\Core\Messenger\LegacyMessenger entirely (which is deprecated and scheduled for removal prior to 9.0.0) and solely rely on the Messenger service.
If possible, 3rd party code should use the Messenger service or find alternative solutions that don't involve using this deprecated class.
If there is any 3rd party code that provides a legitimate use case for keeping this around, we may have to re-think how messages work (highly unlikely, but currently a complete unknown).
This is partially due to the fact that the drupal_set_message() and drupal_get_messages() proceedural functions have been around for over 14 years and usage of these functions was heavy throughout core, contrib and 3rd party code alike.
Thus, this issue also serves as a way to track usage of this deprecated class.
Use cases:
Is there any reason why development.services.yml does not disable TWIG cache by default? Every core update overrides this file with the default one. Themers routinely set those 3 lines, but this is a repetitive task. And the file loads only when settings.local.php is included, so it will not cause any problems on production sites.
parameters: key: twig.config:
debug: true
auto_reload: null
cache: true
/**
* Enable theme development services.
*
* Note: theme debugging can break parts of Drupal. Not recommended in
* production environments. See https://www.drupal.org/i/2914733
*/
# $settings['container_yamls'][] = DRUPAL_ROOT . '/sites/theme-development.services.yml';
For the website themer, this code is more or less analogous to adding $config['theme_debug'] = TRUE; option in Drupal 7 settings.php file. Optionally, a CR could be added to describe this difference between D7 / D8.
There are various problems with the update xml in core/modules/update/tests/modules/update_test
These problem don't make the test fail but should be fixed
For example
aaa_update_test.8.x-1.2.xml should not have version_* tagsaaa_update_test.1_2-alpha1.xml has a release with both <tag>DRUPAL-8--1-1-alpha1</tag> and <version>8.x-1.2-alpha1</version>core_compatibilityThere are probably others.
The doc for this feed is https://www.drupal.org/drupalorg/docs/apis/update-status-xml
Identify all problems and fix
Patch
None
None
None
None
Both #3102724: Improve usability of core compatibility ranges on available updates report and #3113992: [PP-1] The 'Update' page has no idea that some updates are incompatible would benefit from being able to tell a site admin the latest available update that could be installed, given the current version of core on the site.
For (hypothetical) example (if all the other issues were backported all the way to 8.7.x right now):
We'll soon have code that detects 8.x-1.4 is not compatible, wants the user, hides download link / update-me checkbox, etc.
But it'd be nice to at least be able to update them to 8.x-1.3 (e.g. via the UI), which would still be compatible with 8.7.x core.
Add logic (presumably to core/modules/update/src/ProjectCoreCompatibility.php) to figure this out.
Use this logic to enhance the UI of both the Available updates report (admin/reports/updates) and the update-my-site-via-the-UI form (admin/reports/updates/update) to help site builders make better choices.
TBD.
TBD.
Probably none.
TBD.
Discovered at #3111929-31: If no recommended update is found, Update Status recommends the latest release, even if it is unsupported ... the patch that was already RTBC would have broken this block of code from update.compare.inc:
// First, if this is the existing release, check a few conditions.
if ($project_data['existing_version'] === $version) {
if (isset($release['terms']['Release type']) &&
in_array('Insecure', $release['terms']['Release type'])) {
$project_data['status'] = UpdateManagerInterface::NOT_SECURE;
}
elseif ($release['status'] == 'unpublished') {
$project_data['status'] = UpdateManagerInterface::REVOKED;
if (empty($project_data['extra'])) {
$project_data['extra'] = [];
}
$project_data['extra'][] = [
'class' => ['release-revoked'],
'label' => t('Release revoked'),
'data' => t('Your currently installed release has been revoked, and is no longer available for download. Disabling everything included in this release or upgrading is strongly recommended!'),
];
}
elseif (isset($release['terms']['Release type']) &&
in_array('Unsupported', $release['terms']['Release type'])) {
$project_data['status'] = UpdateManagerInterface::NOT_SUPPORTED;
if (empty($project_data['extra'])) {
$project_data['extra'] = [];
}
$project_data['extra'][] = [
'class' => ['release-not-supported'],
'label' => t('Release not supported'),
'data' => t('Your currently installed release is now unsupported, and is no longer available for download. Disabling everything included in this release or upgrading is strongly recommended!'),
];
}
}
% grep -ri revoke core/modules/update/tests is empty. We have no test coverage of the above code block.
Add tests.
N/A
N/A
N/A
N/A
#3102724: Improve usability of core compatibility ranges on available updates report and other issues there has been confusion about why certain XML features were made they way they were.
We should make it clear.
They might be additions or better ideas for making this clear.
All the tasks
Both \Drupal\Component\Utility\Html::getId and \Drupal\Component\Utility\Html::getClass are available as Twig filters (clean_id and clean_class respectively), but \Drupal\Component\Utility\Html::getUniqueId is not available.
Add a clean_unique_id Twig filter that calls back to \Drupal\Component\Utility\Html::getUniqueId.
To do.
When adding packages doesn't sort them in composer.json.
Add sort-packages:true in root composer.json and core/composer.json
Add a patch.
N/A
N/A
N/A
We're using linkit to link to nodes. In the autocompletion we would like to display the status of an item. We can do this using tokens but there's no token for publication status.
Add tokens for publication status:
The core/composer.json file has the following config:
"autoloader-suffix": "Drupal8",
It's not Drupal8 anymore :)
The root composer.json has the correct configuration and the one in core/composer.json is never used to build an autoloader so let's remove it from core/composer.json.