🇩🇪Germany @chr.fritsch

This was now fixed by 🐛 Previewing appears to unlock node RTBC

alexpott → credited chr.fritsch → .

Thank you @mfb, @ergonlogic and @astonvictor for all your work on the Drupal 7 version.

It's time to get rid of all the D7 issues. I am +1 on this.

lgtm

I support that idea. Let's get rid of this and make the module better manitainable.

chr.fritsch → created an issue.

This looks really good to me. The flow makes much more sense now

I tested this in Thunder 7.4.x. I created an article and went to the edit page, so the article is locked. I went back to the content overview and wanted to delete the article.
Then I got the following error message:

The website encountered an unexpected error. Try again later.

TypeError: Drupal\content_lock\Event\ContentLockReleaseEvent::__construct(): Argument #3 ($formOp) must be of type string, null given, called in /var/www/html/docroot/modules/contrib/content_lock/src/ContentLock/ContentLock.php on line 153 in Drupal\content_lock\Event\ContentLockReleaseEvent->__construct() (line 17 of modules/contrib/content_lock/src/Event/ContentLockReleaseEvent.php).

Drupal\content_lock\ContentLock\ContentLock->release() (Line: 207)
content_lock_entity_delete()
call_user_func_array() (Line: 416)
Drupal\Core\Extension\ModuleHandler->Drupal\Core\Extension\{closure}() (Line: 395)
Drupal\Core\Extension\ModuleHandler->invokeAllWith() (Line: 415)
Drupal\Core\Extension\ModuleHandler->invokeAll() (Line: 217)
Drupal\Core\Entity\EntityStorageBase->invokeHook() (Line: 900)
Drupal\Core\Entity\ContentEntityStorageBase->invokeHook() (Line: 462)
Drupal\Core\Entity\EntityStorageBase->delete() (Line: 753)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->delete() (Line: 362)
Drupal\Core\Entity\EntityBase->delete() (Line: 71)
Drupal\Core\Entity\ContentEntityDeleteForm->submitForm()
call_user_func_array() (Line: 129)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers() (Line: 67)
Drupal\Core\Form\FormSubmitter->doSubmitForm() (Line: 597)
Drupal\Core\Form\FormBuilder->processForm() (Line: 144)
Drupal\autosave_form\Form\AutosaveFormBuilder->processForm() (Line: 326)
Drupal\Core\Form\FormBuilder->buildForm() (Line: 97)
Drupal\autosave_form\Form\AutosaveFormBuilder->buildForm() (Line: 73)
Drupal\Core\Controller\FormController->getContentResult()
call_user_func_array() (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 638)
Drupal\Core\Render\Renderer->executeInRenderContext() (Line: 121)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext() (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 181)
Symfony\Component\HttpKernel\HttpKernel->handleRaw() (Line: 76)
Symfony\Component\HttpKernel\HttpKernel->handle() (Line: 53)
Drupal\Core\StackMiddleware\Session->handle() (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle() (Line: 28)
Drupal\Core\StackMiddleware\ContentLength->handle() (Line: 116)
Drupal\page_cache\StackMiddleware\PageCache->pass() (Line: 90)
Drupal\page_cache\StackMiddleware\PageCache->handle() (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle() (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle() (Line: 36)
Drupal\Core\StackMiddleware\AjaxPageState->handle() (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle() (Line: 741)
Drupal\Core\DrupalKernel->handle() (Line: 19)

chr.fritsch → created an issue.

I tried it manually and it works fine. Also it made the installation about 5% faster :)

chr.fritsch → created an issue.

When I use this branch and activate "Unlock form using JS", I don't get lock entries in the database when I open a node.

There is nothing we can do about it.

LGTM

Works. Thx :)

chr.fritsch → created an issue.

Just incredible @alexpott 🥳

chr.fritsch → created an issue.

Bringing back src/SchedulerEvents.php and src/SchedulerEvent.php fixed the issue for me.

The MR is only a doc change. How could that help?

I could reproduce it locally and the problem is that .module files are not loaded before a drush updb. So the alias was not registered

I think https://git.drupalcode.org/project/scheduler/-/commit/46b1988b7e87e47188... is the commit that introduced the problem

I am using SCMI 2.x and I get that error during a "drush updb" from scheduler 2.0.1 to 2.2.0.

I am running into the same problem, but I don't understand why we would need this, because the scheduler module itself also adds the aliases.

See https://git.drupalcode.org/project/scheduler/-/blob/2.2.0/scheduler.modu...

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

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

Finally... Thx everyone for your patience

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

chr.fritsch → changed the visibility of the branch 3433828-drupal-11 to active.

chr.fritsch → changed the visibility of the branch 3433828-drupal-11 to hidden.

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

No, on production sites you don't need field_ui, because you don't change the forms displays. But you still need field_group to view the form displays.

I am facing the same with field_group 3.x. It's because of this change in core https://www.drupal.org/node/3473558 → .

I already found out how to fix it and will provide a MR.

Thanks for fixing the tests. I will review them soon. I am still concerned that this only works with the dev version of the select2 library, but there is nothing we can do about it.

chr.fritsch → created an issue.

https://www.drupal.org/project/drupal/issues/3487031 🐛 Performance Degraded after update to twig 3.14.2 Active

Since we are not using this module anymore, I am happy to welcome you as a maintainer.

chr.fritsch → created an issue.

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

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

chr.fritsch → created an issue.

chr.fritsch → created an issue.

chr.fritsch → created an issue.

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

chr.fritsch → created an issue.

+1 for @alexpott's approach

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

chr.fritsch → created an issue.

Tests are all failing. Far away from done...

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

chr.fritsch → created an issue.

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

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

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