Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
# Summary
# Project URL
https://www.drupal.org/project/content_lock
# Where is the code?
The code is in these issue patches, which currently is generated from this GitHub pull request: https://github.com/juanolalla/content_lock/pull/1/files
# Estimated completion date
# Dependencies
# Who's doing the port?
# What help do they need?
# D8 roadmap
# Background and reference information
Comment | File | Size | Author |
---|---|---|---|
#18 | content_lock_content-2606858-18.patch | 77.98 KB | juanolalla |
#15 | content_lock_content-2606858-15.patch | 76.76 KB | juanolalla |
#11 | port_content_lock_d8-2606858-11.patch | 75.96 KB | mtift |
#7 | port_content_lock_d8-2606858-7.patch | 75.57 KB | flocondetoile |
#4 | content_lock-d8-start-2606858-4.patch | 7.99 KB | brenk28 |
Comments
Comment #2
mgiffordComment #3
brenk28 CreditAttribution: brenk28 commentedHere is a patch that make the D8 module functional until this gets updated. It against the 1.x-dev version from March 1 of 2016. It's not really an update of the existing module, though it does use it's schema (well, not the ajax column).
Here's how it works:
Considerations:
Comment #4
brenk28 CreditAttribution: brenk28 commentedThere were a couple typos in the last one causing the permission not to work. Here is a new one.
Comment #5
dawehnerI'm currently working on a port of the 7.x-2.x branch, which support multiple entity types, for example.
Comment #6
dawehnerThe work is tracked on https://github.com/dawehner/content_lock
Comment #7
flocondetoileI worked on a D8 port of content lock module for a project, starting from #2606856: Drupal 8 Release? patch #3. My needs was to support node, block_content and taxonomy term entity. And the deadline was short.
The patch attached is used on a production site, and permit to lock these entities from simultaneous editing. I worked only the main feature on content lock module, so without the ajax feature, lock by format or the path protected feature, or others features may be.
I wanted to share this work that could be a first step to a D8 port, but the @dawehner work (I just saw writing these lines) seems more interesting (ajax feature for unlock a content entity if the user quit the page without submitting the form, seems that it will support any content entity, using a content entity type instead of a custom table, lock by format).
Content lock timeout module is also included. And some basic integration with views for node entity type is supported too (this was already in the patch #2606856: Drupal 8 Release?).
Some functional tests cover the main feature, but there is not yet tests about preventing an entity deletion if currently edited, and the timeout feature.
@dawehner may be you could use some parts of this patch, even if your approach is different.
Comment #8
flocondetoileIf the maintainer (@Joseph Zhao) can enable the automated tests on the 8.x branch, we could see the results.
Comment #9
mtiftThe patch from #7 works for us, too. However, to help protect against orphaned locks, the attached patch adds a sentence to the message so that it reads:
Comment #10
mtiftOoops, missed a spot.
Comment #11
mtiftWell, it seems a bit weird to be patching my patch, but since we can't really open up issues against a patch, I'm going to offer a slightly different solution.
We are having problems with editors accidentally saving locked nodes, which can also bring them back to the seemingly unlocked node where they can make changes to the locked node. Consequently, the attached patch removes not just delete, but also publish and unpublish functionality when content is locked.
Comment #12
flocondetoileWould be nice if we could have a first 8.x-1.x version committed, and why not a first alpha ?
Comment #13
m4oliveiThis hook implementation needs to be re-thought. hook_entity_predelete will run any time a delete is triggered, including via code. I'm currently running into a situation where my Behat test suite is failing b/c the code in content_lock_entity_predelete recognizes a lock violation and sends a redirect response.
This logic should be limited to the UI somehow. Maybe form altering and adding a validation callback.
Comment #14
flocondetoileIt would be easier to work on a dev version, instead of working on a big patch.
Comment #15
juanolalla CreditAttribution: juanolalla at Lullabot commentedAfter using the site with content lock for a few days, it's become clear that a cancel button is needed. Consider this scenario:
In this case, the content is locked. The only way for the content to unlock is to save the node, which isn't always the desired action. You may wish to leave the node without changing it, and end the lock.
For this reason it appears we need a cancel button on nodes where the user has a lock, so they can clear the lock without saving.
I've implemented this button link over the patch #11, since it is working very well but we don't have anything of this committed to the D8 version of the project yet.
I've had to change the previous default redirection to the entity edit form, otherwise the user would be trapped in redirection, locking the content from the edit form, and coming back to the edit form which would be again locked by him or her. I've added destination query parameter as an option for redirection (as when coming from admin/content), otherwise it would be redirected to the canonical route of the entity (view).
I've made some adjustments for consistency, and fixed a couple of minor things, as a unused "use" statement and a misplaced var type annotation.
Comment #16
dawehnerConceptually this really reminds me of the locking feature in views. We are using the tempstore functionality in the user module for that (service: ```user.shared_tempstore```), which should make all the DB storage here redundant.
Is there a reason you don't support any entity type? Oh I see, this is bound to the particular form structure, too bad. As a follow up we could move this logic into a new handler type on entity types, so you can implement your own logic if needed.
inline_entity_form
does something similar.Nitpick: You can use
$entity->isNew()
for thatComment #17
juanolalla CreditAttribution: juanolalla at Lullabot commentedThanks @dawehner!
I've cloned the content_lock 8.x-1.x branch in GitHub and the patch in the 2606858 branch, so we can work on issues through that branch / pull request, and the patch can be generated from it.
I've actually opened three issues, one with some pending work on the unlock button, other with the improvements suggested by @dawehner, and a third with other proposed changes required for testing by the D8 Strict Schema
https://github.com/juanolalla/content_lock/issues
Comment #18
juanolalla CreditAttribution: juanolalla at Lullabot commentedAttaching a new patch with my last work, which corresponds with this GitHub pull request: https://github.com/juanolalla/content_lock/pull/1/files
The differences are:
1. https://github.com/juanolalla/content_lock/pull/6/files
I've solved the problem described in https://github.com/juanolalla/content_lock/issues/2#issuecomment-266821561, implementing a custom access for the break lock forms that doesn't require the general permision for breaking any content lock, allowing also the access to user that currently has the content locked.
2. https://github.com/juanolalla/content_lock/pull/7/files
I've addressed the config changes needed for the new Strict Schema testing that is enabled by default for Drupal 8 tests (GitHub issue https://github.com/juanolalla/content_lock/issues/4).
Comment #19
jazzdrive3 CreditAttribution: jazzdrive3 at Lullabot commentedI've reviewed the patch and it works great. Marking this as ready.
Comment #20
chr.fritschLooks quite good. One thing i noticed, that the module should not have a hard dependency on the block_content module
Comment #21
mkolar CreditAttribution: mkolar for Hubert Burda Media commentedHello guys, thanks for your work :)... As I wrote this already as comment to pull request on GitHub: route content_lock_timeout.settings_form should require "administer content lock" permission or something like this instead of "access administration pages". What do you think? For example with this permission my editors (they have access to admin pages) will be able to setup timeout for locks.
Comment #22
juanolalla CreditAttribution: juanolalla at Lullabot commentedI think you're right @chr.fritsch, as @dawehner already mentioned too. I've created an specific issue for that in GitHub: https://github.com/juanolalla/content_lock/issues/9
The same with your comment @mkolar, created issue https://github.com/juanolalla/content_lock/issues/8
If this patch were commited sooner we would recreate those issues in Drupal.org content_lock project, but while this is still a big patch in this issue queue it makes more sense to me to be able to work separately on GitHub issues and merging one by one into the main pull request, corresponding to this patch.
Thanks both!
Comment #23
chr.fritschI recently got push access to this module.
So i just pushed #18 to the D8 branch.
Thank you @juanolalla for the awesome work. Would be nice if you could create issues in the d.o. issue queue for all outstanding tasks.
Comment #24
juanolalla CreditAttribution: juanolalla at Lullabot commentedThank you, and also thanks for creating the issues in d.o. I've deleted those in GitHub since we no longer need that repo.