Allow for coexistence with the prefetch_cache module

It looks good. Thank you! Unfortunately, I have a couple of remarks :)

1. +++ b/js/content-lock-form.js
   @@ -0,0 +1,63 @@
   +      $form.find('input, textarea, select').attr('disabled', 'disabled').addClass('is-disabled');
   

   According to the jQuery documentation when setting "disabled" we should use the jQuery prop method instead the attr method.

2. +++ b/src/Controller/LockController.php
   @@ -0,0 +1,90 @@
   + * Created by PhpStorm.
   + * User: karl.fritsche
   

   I think this is not really needed :)

3. +++ b/src/Controller/LockController.php
   @@ -0,0 +1,90 @@
   +      $container->get('content_lock')
   ...
   +      $messages = \Drupal::service('renderer')->renderRoot($status_messages);
   

   Let's add the renderer service through "dependency injection" :).

4. +++ b/src/Controller/LockController.php
   @@ -0,0 +1,90 @@
   +   * @param \Symfony\Component\HttpFoundation\Request $request
   ...
   +  public function createLockCall(Request $request, ContentEntityInterface $entity) {
   

   The $request parameter is not used, therefore it should be removed. If it is not present in the method definition then Drupal will not pass it. @see https://www.drupal.org/docs/8/api/routing-system/using-parameters-in-routes

5. +++ b/src/Controller/LockController.php
   @@ -0,0 +1,90 @@
   +    // Not lockable entity or node creation
   

   -> Not lockable entity or entity creation. :)

6. +++ b/src/Controller/LockController.php
   @@ -0,0 +1,90 @@
   +      $lock = $lockable ? $this->lockService->locking($entity->id(), $this->currentUser()->id(), $entity->getEntityTypeId(), FALSE, $entity->toUrl('edit-form')->getInternalPath()) : FALSE;
   

   If there are multiple forms on which the content lock is enabled, then regardless of the form for which the lock is being broken the user will always be redirected to the edit-form, instead to the form on which she currently is. We have to find a way to redirect the user to the proper destination.

7. +++ b/src/Controller/LockController.php
   @@ -0,0 +1,90 @@
   +        $response->addCommand(new AppendCommand('#edit-actions', $unlock_button));
   

   Could we probably add a specific class to the actions in hook_form_alter and use this class as a selector instead of relying on the element ID being '#edit-actions'?

Just nits :

+++ b/config/install/content_lock.settings.yml
@@ -1,2 +1,3 @@
\ No newline at end of file

+++ b/content_lock.libraries.yml
@@ -0,0 +1,7 @@
\ No newline at end of file

+++ b/js/content-lock-form.js
@@ -0,0 +1,63 @@
\ No newline at end of file

+++ b/src/Controller/LockController.php
@@ -0,0 +1,90 @@
\ No newline at end of file

We have to add the new lines.

Regarding 1. - I've missed that there are two lines where disabled is being set. The other line still should be converted to use the prop method instead the attr method when setting the disabled property.

Beside that it looks good.

Thank you. After going through the patch again I found one last questionable change:

+++ b/content_lock.module
@@ -82,6 +83,36 @@ function content_lock_form_alter(&$form, FormStateInterface $form_state, $form_i
+      $form['actions']['#attributes']['class'][] = 'content-lock-actions';
...
+        $form['actions']['delete']['#attributes']['class'][] = 'content-lock-actions';
...
+        $form['actions']['publish']['#attributes']['class'][] = 'content-lock-actions';
...
+        $form['actions']['unpublish']['#attributes']['class'][] = 'content-lock-actions';
...
+        $form['moderation_state']['#attributes']['class'][] = 'content-lock-actions';

As in JS we just remove the element which has the class "content-lock-actions" we do not really have to add the class to each action, but only to the parent element containing all the actions. Do you agree with that or there is probably some other reason for doing this?

Are there actions which should be available when locked?

Well even if there are actions which should be available then this would be a contrib/custom case, which we don't know. Also currently we would add the class to only core known actions, but not to all actions that have been added through e.g. a form alter hook. Therefore currently I think we should add the class to the parent element and remove or disable (personally I prefer disable with e.g. on hover message that the action is disabled because the form is locked) all the action buttons through JS.

Thank you, I think that this looks good now.