🇧🇪Belgium @herved

Ideally it should also support future dates, resulting in a spike curve where the peak is NOW and decays in past or future.
In mysql at least, it looks like we can achieve the same formula as the one used in solr:
- solr: product(boost,recip(abs(ms(resolution,field_name)),m,a,b))
- mysql: boost * ( 1 / (m * ABS(TIMESTAMPDIFF(SECOND, FROM_UNIXTIME(field_name), NOW()) * 1000) + a) + b)

However I don't really know what would be the best to combine both numbers (keyword score that can be very high 1000-infinite), and this date boost. Maybe some kind normalization would be needed?
Something like: (score/(min_score+score)) where min_score = 1000
Then use a = 1, b= 0.1 producing a 0-1 date boost
and add both results?

I noticed that when keywords are given, we may need to join the main index table as search_api_db produces a group_by query which also makes things quite complicated.

Snapshot of current MR for composer on 3.x

Sorry for the late feedback, it seems to work well on my project and simplifies things greatly.
+1, thanks !

Here is a static patch for 10.3.x, based on MR 8334.

The webform submission issue can be solved by applying 🐛 Incorrect use of 'render element' for webform_submission_data Active on webform 6.2.x, or updating to 6.3.x.
Adding revision and language to the key like MR 4994 does would make sense I think.

Oh indeed, that could simplify things a lot.
Maybe loading all DS layouts and setting the default type to ds.layout_plugin.settings.default

Snapshot of current MR, for composer.

#202, FWIW on ddev I create a file .ddev/php/xdebug.ini and put this:

# Do not use xdebug develop mode causing transaction timing issues.
# @see https://www.drupal.org/project/drupal/issues/3405976
xdebug.mode=debug

herved → changed the visibility of the branch 3456722-regression-entity-view to hidden.

I pushed a better/proper recursion detection logic, with a similar logic than 🐛 Can only intentionally re-render an entity with references 20 times Needs work .

PS: the pipeline on 3.x is currently broken.

Update: we also hit the webform submission issue (thankfully from our tests) as mentioned in comments 163 - 179
I created an issue in webform and proposed a fix there 🐛 Incorrect use of 'render element' for webform_submission_data Active

herved → created an issue. See original summary → .

I encountered such issues with Media but this could also solve issues such as 🐛 [regression] Entity view block not displayed after #2962166 Needs review since it applies to all entity types.
Finally a true recursion detection and using pre/post_render callbacks to do it is very interesting.
I tested it on one of our projects and it works great, thanks!

Note that the recursion detection is still not very good.
Maybe we could borrow the same approach as 🐛 Can only intentionally re-render an entity with references 20 times Needs work ?

For now couldn't we revert the changes from the issue that introduced this regression?

Note that this introduced a regression, see 🐛 [regression] Entity view block not displayed after #2962166 Needs review

Short explanation:
- RdfSyncExceptionSubscriber::onException transforms any non-http exception into an http one
- it also transforms a NotEncodableValueException (supposedly coming from the normalizer) into a NotAcceptableHttpException which gets logged as a client error right after in \Drupal\Core\EventSubscriber\ExceptionLoggingSubscriber::onException

What is special about that content_moderation field, while other computed fields work just fine?

See #2321071-42: BaseFieldOverride fails to take into account ContentEntityInterface::bundleFieldDefinitions() when invoking onFieldDefinitionUpdate() → + this issue description.
It's convoluted...

herved → created an issue.

#54, see #37, the current patch only prevents moderation_state BFOs to be exported. Existing ones need to be removed manually.
Let's not continue with patches and create a merge request.

Tested this on our project at /admin/people/permissions, using network tab:

twig v3.14.0:
- after cr: 3.29s
- next load: 2.58s
twig v3.15.0:
- after cr: 8.39s
- next load: 7.60s
twig v3.15.0 + patch from https://www.drupal.org/i/3487031:
- after cr: 3.27s
- next load: 2.79s

In practice, I did not notice any performance degradation at first. Probably because the form has to be very complex, and the browser itself (UI performance) has to keep up anyway for example for this permission page. But there seems to be quite an impact indeed on a pure PHP performance. This may also behave worse on different environments as others stated.

I also ran the same tests with xhprof and the results are telling, it goes from 3s to 46s to load the page, with a very high wall time on Twig\Extension\SandboxExtension::ensureToStringAllowed.
So +1, looks like it fixes it, thank you!

I tested the above scenarios, works correctly. Just a minor nit.
+1, looks like a good fix and maintains BC.

+1, looks ok to me
Maybe the scope of 🐛 Remove private-message-* id Active could have been combined here, but it's fine either way.

+1, it looks ok to me.

PS: Do we still need to support Drupal 9 (from info.yml)?

herved → created an issue.

I just stumbled on this issue, in our project we use symfony_mailer_lite and print {{ subject }} in the twig mail template.
Twig encodes these chars to HTML entities: '&<>
If the subject contains any of these chars, then they get printed as encoded in the final twig template/email.

This is not an issue for the actual mail subject as it goes through PlainTextOutput::renderFromHtml() here.
But the twig template is rendered just before that, from here.
So I believe it makes sense to apply the proposed suggestion.

Changes look good to me, thanks.
I did some manual tests and didn't any other issues/regressions.

We can reproduce this as follows:
1. Enter in "to" field: foo,bar,baz
2. Remove all 3 user items
3. Redo step 1 again, we get an AJAX error

Attaching a gif to showcase issue.

Can't we simply use $private_message->get('message')->processed ?
This uses \Drupal\text\TextProcessed::getValue and returns a FilteredMarkup which would align with the filter format. Xss::filter may filter way more than expected.

herved → created an issue.

Does 🐛 Error: cannot call methods on dialog prior to initialization; attempted to call method 'option' Needs review solve this?

Is the ??[] needed here $this->config->get('form_settings') ?? []? I believe form_settings is always an array.

Oh good point, indeed, otherwise it would have nullable: true in the config schema if I'm not mistaken.
MR updated.

It looks like the pipeline is currently broken on HEAD, as it was changed to use D11.

I noticed D11 requires at least two things:
- https://git.drupalcode.org/project/private_message/-/merge_requests/129/...
- https://git.drupalcode.org/project/private_message/-/merge_requests/129/...

herved → created an issue.

Indeed this doesn't seem valid: https://jsfiddle.net/cafsjowu/1/
It looks like 📌 Prevent extlink icons from breaking into new lines Needs work recently committed added an extra span wrapper in the mean time?
Can you please create a new issue @cboyden? thanks

PS: The added code there looks convoluted. I wonder, wouldn't simply   work?

Leftover again...
MR updated, and updated 2.2.0 patch

Leftover in HoneypotSettingsForm::submitForm...
MR updated, and here's the updated 2.2.0 patch

+1 with avoiding this in the future, this is a BC break and needs a major release.
Having to pin/unpin in composer is tedious.
If every module were to do that, it would be quite a hassle.

Here is a patch that applies cleanly to 2.2.0

herved → created an issue.

I believe 🐛 Avoid random failures in JavascriptTestBase when testing functionality in a dialog Needs work is also related, as I mentioned in #6.

Interesting, I found some incoming requests to our production going to /filter/tips/｡｡｡, which is accessible as anonymous.
This throws such errors as well.

Opened a new branch for 11.x based on the previous one.
Fixed tests based on #106. However I didn't include the ones that were added in #106 as there is a lot of code duplication and they are not passing.
Attaching also a static patch for composer.

herved → made their first commit to this issue’s fork.

I work on 3 drupal sites running core 10.3, all passing config_inspector check, this is one of the remaining issues.
Drupal core is fully compliant AFAIK, and phpunit is configured to fail if such issues are found (in \Drupal\Core\Config\Development\ConfigSchemaChecker).

herved → made their first commit to this issue’s fork.

It looks like something went wrong with the last merge in 3390948-svg (in , imagecache_external.module imagecache_sanitize_svg got removed).
I created a new 3390948-svg-2 branch, rebased on 3.0.x.

herved → made their first commit to this issue’s fork.

I stumbled on this issue in our CI, but cannot reproduce locally for some reason...

The patch does fix the issue for me as well, as long as I don't use --list-constraints
If I do, I get:

/vendor/bin/drush config:inspect --only-error --detail --list-constraints
>  🤖 Analyzing…

 [warning] Undefined array key "menu_position.settings" ConfigSchemaValidatability.php:164
TypeError: Drupal\config_inspector\ConfigSchemaValidatability::getConstraints(): Return value must be of type array, null returned in modules/contrib/config_inspector/src/ConfigSchemaValidatability.php on line 164 #0 modules/contrib/config_inspector/src/Commands/InspectorCommands.php(577): Drupal\config_inspector\ConfigSchemaValidatability->getConstraints()
#1 modules/contrib/config_inspector/src/Commands/InspectorCommands.php(257): Drupal\config_inspector\Commands\InspectorCommands::getPrintableConstraints()
#2 [internal function]: Drupal\config_inspector\Commands\InspectorCommands->inspect()

This might be another issue I'm not sure...

Also related, config schema validation is failing on this module:

  tmgmt.translator.tmgmt_cdt:settings.conf_mode       missing schema
  tmgmt.translator.tmgmt_cdt:settings.conf_advanced   missing schema
  tmgmt.translator.tmgmt_cdt:settings.conf_network    missing schema

I'm expanding the scope to all views plugins if you agree.
Opened MR and here is a static patch for composer.

PS: looks like the pipeline is broken on 3.0.x branch :\

I think this ccan be closed as duplicate of 🐛 Views filter schema Needs review
Could you confirm? thanks

herved → made their first commit to this issue’s fork.

We need langcode now that some configs are translatable.

Note: there is no hook_update so, in bootstrap.settings and subtheme settings:
- add langcode: en
- if present, delete reset_http_request_cache, table, apply, reset configs

Some more fixes... I think it should be ok now.

#20 discarded most settings from the previous patch #13, what happened there?
Updated MR and patch, according to patch #13 instead.

Opened MR, here is a static patch for composer if anyone needs it.
and the interdiff with #20.

PS: I know 3.x is now phasing out but I need those schema fixes, we are planning a BS5 migration.

herved → made their first commit to this issue’s fork.

Static patch for composer, if anyone needs it.

MR created, let me know if you have a better idea on the approach.

This may need a change record so site owners are aware they need to define the schema for all their custom layouts.
E.g.: If ds_my_layout uses the main Drupal\ds\Plugin\DsLayout class, then we have to use.:

layout_plugin.settings.ds_my_layout:
  type: ds.layout_plugin.settings.default

herved → created an issue.

Thanks, though I wasn't looking for a code review yet (tests and upgrade path still todo) but rather opinions on the overall approach / scope as it may extend way beyond link formatters.
See #13.

Sadly, I don't have time to work on this right now, and didn't investigate potential solutions.
So if anyone wants to work on it and/or propose an approach, you are most welcome :)

herved → created an issue.

Rebased and moving to review, to get feedback on the approach, thanks.

herved → created an issue.

herved → created an issue.

whoops, forgot to move back to review, thanks

herved → created an issue.

Thanks @Claudiu,

I propose to fix cspell here directly, but I can always create a new issue and move the commit there if you prefer.
Most of those are obvious except I added exclusions for "please" from \Drupal\entity_legal\Plugin\EntityLegal\Message::execute, just in case site owners translated the string.

Tests are currently broken on the base branch, please see 📌 Fix tests and restore redirection test Needs review

Phpunit is failing because there is a broken/wrong serialized value in modules/contrib/entity_legal/tests/fixtures/update/install_entity_legal.php:88

We can verify this by throwing the exception in \Drupal\Core\KeyValueStore\DatabaseStorage::getMultiple instead of muting it. See this https://3v4l.org/mr8AW
It fails on PHP 8.3 but not on lower versions, which explains the issue.
I will fix it in this MR.

herved → created an issue.