↧
Toolbar does not work with "nolink" links
↧
Twig LoaderError after upgrading Twig to 2.15.3
Problem/Motivation
After upgrading drupal core with composer from 9.4.5 to 9.4.6, admin theme Gin (contrib) based on Claro (core theme) is broken (wsod) while front theme (contrib) is still running.
Apache server throws this message :
Uncaught PHP Exception Twig\\Error\\LoaderError: "Template "@claro/../images/src/hamburger-menu.svg" is not defined in "core/themes/claro/templates/navigation/menu-local-task.html.twig" at line 30." at /my-website/vendor/twig/twig/src/Loader/ChainLoader.php line 98, referer: https://my-website/admin/reports/updates
↧
↧
Avoid costly lookups of drupal_array_get_nested_value / drupal_array_nested_key_exists
Problem/Motivation
drupal_array_nested_key_exists / drupal_array_get_nested_value is very costly and essentially always traverses the same path within either form_state['input'] / form_state['values'] .
field_x/und/0/_weight
etc.
The traversing itself can with 30 files go into direction of 300 - 500 ms alone already.
Proposed resolution
However form_builder() already traverses this path - unless someone overwrote it with arbitrary #parents - so in 90% of the cases, a reference could be put in $form_state or a new variable on where the form builder according to #tree and #parents should be right now in relation to the base of 'values' / 'input'.
e.g. pseudo code for values:
function form_builder() {
// check if set first obviously.
$current_values_element = &$form_state['form_builder_current']['values'];
foreach (element_children(...) as $key) {
// use $key only with #tree obviously.
if (!isset($element[$key]['#parents'])) {
if ($is_tree) {
$form_state['form_builder_current']['values'] = &$current_values_element[$key];
}
else {
$form_state['form_builder_current']['values'] = &$form_state['values'];
}
}
else {
$form_state['form_builder_current'] = array();
}
// ...
form_builder(..., $form_state);
}
}
It is also possible to create short-cut cache paths based on the parents as string, but that is more effort than trailing along directly:
function &drupal_array_get_nested_value_cached(array &$array, array $parents, &$key_exists = NULL) {
$ref = &$array;
$i = 0;
$path = '';
$found = array();
$paths = array();
$skip = FALSE;
foreach ($parents as $index => $parent) {
$path .= '/' . $parent;
if (isset($array['#form_builder_cached_path'][$path])) {
$skip = $index;
$ref = &$array['#form_builder_cached_path'][$path];
}
}
$path = '';
foreach ($parents as $index => $parent) {
$path .= '/' . $parent;
if ($skip !== FALSE) {
if ($skip != $index) {
continue;
}
$skip = FALSE;
continue;
}
elseif (is_array($ref) && (isset($parent[$ref]) || array_key_exists($parent, $ref))) {
$array['#form_builder_cached_path'][$path] = &$ref[$parent];
$ref = &$ref[$parent];
}
else {
$key_exists = FALSE;
$null = NULL;
return $null;
}
}
$key_exists = TRUE;
return $ref;
}
function drupal_array_nested_key_exists_cached(array &$array, array $parents) {
// although this function is similar to php's array_key_exists(), its
// arguments should be consistent with drupal_array_get_nested_value().
$key_exists = null;
drupal_array_get_nested_value_cached($array, $parents, $key_exists);
return $key_exists;
}
Remaining tasks
- See if one of the proposed approaches passes core tests.
↧
[meta] Deprecate dependency setters and getters on interfaces
Problem/Motivation
During the Drupal 8 development cycle we have added many setters (and getters) to interfaces in order to inject (and sometimes retrieve) dependencies of the primary classes that implement the interfaces. This was done because we were in code freeze and couldn't change the constructors of said classes, because that would break the often numerous child classes. However, these dependencies have nothing to do with the APIs the interfaces define.
Proposed resolution
As the dependencies for which setters and getters exist are implementation details and do not make up part of the APIs the interfaces define, they should be marked deprecated and scheduled for removal in Drupal 9, where they will be replaced with proper constructor injection.
Remaining tasks
Create child issues for the interfaces that use setters and getters for dependencies, and add @deprecated annotations to said methods.
User interface changes
None.
API changes
None.
↧
Deprecate dependency setters and getters on LanguageNegotiatorInterface
This issue deals with #2494695: [meta] Deprecate dependency setters and getters on interfaces for \Drupal\language\LanguageNegotiatorInterface.
↧
↧
Performance improvement for importing of project translations
Problem/Motivation
Currently importing of .po files for projects could take unacceptable about of time.
Proposed resolution
I have found that problem related to implementation of locale_translation_status_save();
This could be solved by this changes:
function locale_translation_status_save($project, $langcode, $type, $data) {
// Load the translation status or build it if not already available.
module_load_include('translation.inc', 'locale');
- $status = locale_translation_get_status();
+ $status = locale_translation_get_status([$project]);
if (empty($status)) {
$projects = locale_translation_get_projects([$project]);
if (isset($projects[$project])) {Remaining tasks
Don't see for now.
User interface changes
No changes
API changes
Data model changes
Release notes snippet
↧
[meta] Convert assertions involving use of xpath to WebAssert, where possible
Problem/Motivation
From #3129002: Replace usages of deprecated AssertLegacyTrait::assert():
In cases of constructs like
$view_link = $this->xpath('//div[@class="messages"]//a[contains(@href, :href)]', [':href' => 'aggregator/sources/']);
$this->assert(isset($view_link), 'The message area contains a link to a feed');
we are in fact failing to test appropriately: $this->xpath returns an empty array here, since the xpath selector is //div[@class="messages"] and in fact since the test was written the class changed to 'messages-list'. But an empty array is set as a variable, so the test passes anyway. I corrected by changing the selector to //div[@data-drupal-messages], and using the WebAssert::elementExists method.
Steps to reproduce
Proposed resolution
Review tests that use $this->xpath() and then an assertion using isset to ensure they are testing what they are meant to test.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
↧
Move template_preprocess, _template_preprocess_default_variables into services
Problem/Motivation
Coming from #2325571-7: Replace _theme() calls by calls to \Drupal::theme()->render() @alexpott suggested moving template_preprocess and _template_preprocess_default_variables into one of the Theme services. @dawehner created this issue as a follow up with original title: 'Move template_preprocess, _template_preprocess_default_variables into services (Probably ThemeManager or invoked via that.)'
Proposed resolution
Move template_preprocess() and _template_preprocess_default_variables() to ThemeManager class.
Remaining tasks
- Make reviews
Fix failing tests- Decide if we need to deprecate theme_preprocess() or can we simply remove it
User interface changes
None.
API changes
theme_preprocess() should be removed. I think nobody should use theme_preprocess() anywhere in contrib. Other option is to deprecate it. This need to be decided before merging this in.
Data model changes
None.
↧
Starterkit theme roadmap
New starterkit theme generator has been added as an experimental new tool in core. The starterkit theme generator allows developers to create a starting point for their theme. The generated theme has similar markup and CSS previously provided by Classy base theme including common CSS classes and markup. Instead of inheriting the markup and CSS from a base theme, the starterkit theme generator copies the defaults into a new theme.
Starterkit theme beta criteria
- #3206217: Allow starterkit themes to control how the theme is generated
- #3206219: Allow configuring which theme is used as a starterkit theme
- #3206226: Make updating changes from starterkit themes to generated themes easier
Starterkit theme stable criteria
- Documentation plan (needs issue)
Nice to have issues
↧
↧
Add negated regular expressions for views filters (string and integer)
Problem/Motivation
Usecase:
There are three nodes with the following titles: foo, bar, drupal. Requirement: Create a view that lists nodes that does not have title foo or bar.
Using views string filter you can't create a SQL expression like "some_field NOT IN ('foo', 'bar')", as a workaround when searching a multiple value string in a string Regular Expression operation can be chosen but it's hard to implement a reverse search for regex because the regex is done on SQL level which is limited according to https://dev.mysql.com/doc/refman/5.7/en/regexp.html
POSIX regexes don't support using the question mark ? as a non-greedy (lazy) modifier to the star and plus quantifiers like PCRE (Perl Compatible Regular Expressions). This means you can't use +? and *?
http://stackoverflow.com/questions/18317183/1139-got-error-repetition-op...
Proposed resolution
Implement negation for REGEXP operation, it can be found in documentation as NOT REGEXP.
NOT REGEXP Negation of REGEXP
https://dev.mysql.com/doc/refman/5.7/en/regexp.html
Remaining tasks
Requeue tests for 8.8.x branch and more DBs.- Final review / RTBC
- Commit
User interface changes
Adds a new "Negated Regular expression" option to the choices for the operation to use for Views string and integer filters.
API changes
None.
Data model changes
None.
↧
HTTP ERROR 500 on views pages
HTTP ERROR 500 on views pages
Some pages with views showing the following error massage :
This page isn’t working
website.com is currently unable to handle this request.
HTTP ERROR 500
this error shows only to authenticated users, the page display correctly for anonymous users.
↧
ContextDefinition::isSatisfiedBy does not take into account cardinality
Problem/Motivation
ContextDefinition::isSatisfiedBy does not check if the definition is multi-valued. This can cause an error when checking violations.
Steps to reproduce
The following code produces an error.
$definition = EntityContextDefinition::create('node');
$definition->setMultiple();
$nodes = Node::loadMultiple([1, 1]);
$context = new \Drupal\Core\Plugin\Context\Context($definition, $nodes);
$satisfied = $definition->isSatisfiedBy($context);Error: Call to a member function getEntityTypeId() on array in Drupal\Core\Entity\Plugin\Validation\Constraint\EntityTypeConstraintValidator->validate() (line 22 of /var/www/html/web/core/lib/Drupal/Core/Entity/Plugin/Validation/Constraint/EntityTypeConstraintValidator.php).
Proposed resolution
Check $definition->isMultiple() inside of ContextDefinition::isSatisfiedBy and tweak how $validator->validate() runs.
Remaining tasks
Write a patch.
User interface changes
n/a
API changes
n/a
Data model changes
n/a
Release notes snippet
n/a
↧
Display category-related recipes when seeing a recipe full page
Problem/Motivation
A common issue site builders face is adding a related content block based on categories. This is doable only with Drupal core, but people assume they will need a contrib module for that. Let's provide a related recipes block on the recipe full page, so we can demo that, and also point them to an example when they ask for support for doing this.
Proposed resolution
Add a block with related recipes view content based on category. E.g. if I look at a dessert, I see other dessert recipes linked.
Remaining tasks
Patch with config.
User interface changes
Recipe detail will have a block at the bottom with related recipes.
Image may be NSFW.
Clik here to view.
API changes
None.
Data model changes
None
Release notes snippet
None.
↧
↧
The $validated flag should be reset if the entity changes
Problem/Motivation
If an entity is validated and before save is called it still might be changed and if this happens the $validated property should be reset because the new changes have not been validated.
Proposed resolution
in CEB::onChange reset the $validated flag.
Remaining tasks
User interface changes
API changes
Data model changes
↧
Create new |value and |label twig filters
Let's create new |value and |label Twig filters for core.
Various modules such as Twig Field Value provide this within contrib.
Questions
- How do we handle entity references?
- Any special conditions for handling formatted text?
↧
Sub form not passed to BlockPlugin's submit callback
Problem/Motivation
In #2537732: PluginFormInterface must have access to the complete $form_state (introduce SubFormState for embedded forms), the SubFormState class was introduced for BlockPlugin's build/validate/submit callbacks, and additionally $form['settings'] (the sub form array) started getting passed to the build/validate callbacks, but not to the submit callback!
That means that $form is different in these two callbacks for everyone writing a BlockPlugin:
($form is $form['settings'] here)public function blockValidate($form, FormStateInterface $form_state) {
($form is the complete/parent form here)public function blockSubmit($form, FormStateInterface $form_state) {
Proposed resolution
We should fix this so that the $form argument passed to these callbacks is consistent.
Remaining tasks
Review the patch.
User interface changes
None.
API changes
The sub form is now passed to BlockPlugin's submitForm method, instead of the complete/parent form.
Data model changes
None.
↧
Follow-up for #3231334: global attributes should result in HTMLRestrictions becoming simplified
Problem/Motivation
⚠️ Discovered while reviewing #3312442: Make ready for ckeditor5, which is updating the ckeditor_bidi module to support CKEditor 5 and provide an automatic upgrade path.
<p lang> <* lang>
should get simplified to
<p> <* lang>
Steps to reproduce
See unit test, or alternatively create a dummy CKEditor 5 plugin with
elements:
- <p dir="ltr rtl">
You'll notice that filter_html gets configured to not allow just <p>, but <p dir="ltr rtl">, even though that's already implied by that filter (see \Drupal\filter\Plugin\Filter\FilterHtml::getHTMLRestrictions()).
Proposed resolution
Automatically resolve global attributes. This is something we didn't notice in #3231334: Global attributes (<* lang> and <* dir="ltr rtl">): validation + support (fix data loss).
Remaining tasks
Test coverage.
User interface changes
No more nonsensical additions to filter_html.
API changes
None.
Data model changes
None.
Release notes snippet
Not necessary.
↧
↧
Add |remove_class twig filter
This is a followup to #3301853: Create twig filters: |add_class, |remove_class, and |set_attribute.
In that issue we wanted to add the |remove_class along with the other filters. However, we determined it does not work as expected when the template adds the CSS class (e.g. the field class).
As a front-end developer, I would expect that the |remove_class would remove those CSS classes, however it currently cannot.
We're not sure this is fixable (or even should be fixed). But if so, we can work on ithere.
↧
PostCSS Logical not transpiling flow relative properties (e.g. float: inline-start) which are not supported by Chrome and Safari
In #3312481: Update core's browserlist we updated the browserlist database which determines what CSS properties PostCSS will transpile. With this update, Drupal core is not transpiling any logical properties.
However, there are certain properties which our supported browsers do not support, including flow relative properties such as `float: inline-end`, and `clear: inline-start`. You can see current browser support for these properties at https://caniuse.com/mdn-css_properties_clear_flow_relative_values.
The Chromium issue to implement this is at https://bugs.chromium.org/p/chromium/issues/detail?id=850004. I can’t find the webkit issue.
I created an upstream bug for PostCSS Logical at https://github.com/csstools/postcss-plugins/issues/632
Task
It'd be nice if either 1) this could be fixed upstream or 2) we could set PostCSS Logical to always transpile these values. But, for now, I think we need to change the float values to use non-logical CSS properties. This should be an easy task, as they're only used in a few places within Olivero.
↧
Create twig filters: |add_class and |set_attribute
This is related to #3301373: Create twig |add_suggestion filter
In conjunction with the |add_suggestion filter, themers typically want to set CSS classes on the field components to maintain proper BEM architecture.
The issue above has this discussion to add this functionality into that filter, but in a subsequent Slack conversation @lauriii suggested splitting it into its own |add_class filter, along with a |setAttribute filter.
This would enable something like
{{ content.field_event__links|add_suggestion('list')|add_class('event__link-list') }}
{# Produces: #}
<ul class="list event__link-list">
<li><a href="/">foo</a></li>
<li><a href="/">bar</a></li>
</ul>and
{{ content.field_event__links|as('list')|add_class('event__link-list')|set_attribute('data-kitten', 'mila') }}
{# Produces: #}
<div class="field__items field--tags__items event__link-list"> data-kitten="mila">
<!-- rest of the markup -->
</div>
↧