@jErry_jakcson

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

Couldn't apply patch from latest mr.

Also this should be commited marking as rtbc

The patch in #6 adds `list_class: TimeFieldItemList::class,` which doesn't exists in the current codebase. While it fixes the initial issue it introduces a new bug.

I'm attaching the patch from the merge request that only updates the existing annotations.

Just wanted to mention the change records → for the cause of this issue. It explains a way to add backward compatibility in "BC layer" section, but switching to attributes will break it anyway.

Despite there are no failing tests, the pipeline is still failing. I can't figure out why just from the logs. Can someone with more knowledge take a look?

murat_kekic → created an issue.

murat_kekic → created an issue.

I believe lazy builders might not work in this case, as they are primarily designed for render arrays.

For reference, there's a related support discussion about lazy builders not being supported by form elements.
#lazy_builder is not supported by forms →

The latest code wasn't selecting the correct entity translation.
It always picked the entity translation in the current user's language because the entity was resolved with the router service.
This issue can be reproduced by running a Pathauto bulk regenerate for all aliases on a multilingual entity.

I refactored the views_url_alias_get_path_entity_type function to ensure it handles entity translations properly when applicable.

However, I had to remove the views_url_alias_pathauto_alias_alter hook function. The comment in the hook says it’s for saving aliases during bulk updates

function views_url_alias_pathauto_alias_alter(&$alias, array &$context) {
  // Save alias during bulk update.

, but I don’t see how that’s the relevant place to save the data. Is it a workaround for something?

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

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

I was going to add some tests. While doing that, I noticed there's already a test very similar to the one I wrote. I checked why that test was passing and found out the helper function getCaptchaTokenFromForm wasn't working properly. It was assuming the CAPTCHA token to be an integer, which is not true. This caused some of the tests in CaptchaSessionReuseAttackTestCase to pass even though they should've failed.

I fixed the getCaptchaTokenFromForm function so it works as expected now. After fixing it, the tests actually failed without the initial changes. Then I applied the changes, and the tests passed. So there were some broken tests that went unnoticed before.

I'll try to add a test case for this soon.

For now, this patch is working for me.

I'm encountering this issue with a webform that uses a confirmation step and one of my custom forms. In both cases, after submission, the CAPTCHA element is not being rebuilt --either because it’s no longer included in the form or because $form_state->setRebuild() is not being called.

This causes the issue because the solution is updated in preRenderProcess. If the element is not rebuilt/rerendered, the solution remains unchanged, allowing the same solution to be reused as many times as possible.

In my opinion, @anybody's approach was correct but incomplete. The CAPTCHA status also needs to be updated to 'unsolved' whenever the solution is updated.

I have updated the _captcha_update_captcha_session function to always set 'status' to 'unsolved'

From captcha.inc:

function _captcha_update_captcha_session($captcha_sid, $solution) {
  \Drupal::database()->update('captcha_sessions')
    ->condition('csid', $captcha_sid)
    ->fields([
      'timestamp' => \Drupal::time()->getRequestTime(),
      'solution' => $solution,
      'status' => CaptchaConstants::CAPTCHA_STATUS_UNSOLVED,
    ])
    ->execute();
}

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

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

So it *might* also be a Webform issue, if it doesn't happen in other Multistep forms, I'm not sure. But still unexpected, so I'll keep the status.

I'm facing the same problem with my custom multistep forms.

One observation is that the persistence mechanism and the mentioned option in the captcha module rely on the captcha status stored in the captcha_sessions table. However, it appears that the captcha status is not being updated at all within the ReCaptcha module.

Additionally, I'm unsure whether the ReCaptcha module needs to perform the action mentioned. It might be the responsibility of the captcha module. The captcha status isn't managed if the cacheable attribute during the generation operation is set, which is the case with ReCaptcha.

To me, it makes more sense for the captcha status to be managed entirely by the captcha module.

Adding to the discussion, it appears that the persistence settings were previously overlooked #3363653 🐛 reCAPTCHA ignores “Omit challenges in a multi-step/preview workflow…" setting Needs work and not related to the patch.

I faced the same problem until I realized I was missing the core-dev package. Running composer require --dev drupal/core-dev solved the problem.