Drupal7 port

For D7 it will be rather a completely rewrite. Its not planned in the very near future

Is there any other module out there with similar functionality? This is a very natural functionality to have in larger sites. Vel.. in all sites with more then one editor :)

subscribe

My best advice is to do a straight port to D7. Mark it bugfix only, and then start a new branch.

@EugenMayer: What do you think about agentrickard's suggestion? Also see http://drupal.org/node/1088340?

I'm interested in/planning on porting content_lock to D7 when I find time, which will hopefully be soon. If a complete refactoring is to be done, that can be done later.

I needed this functionality and started to port it. Here's the patch. I redid the DB queries and hook changes. I haven't tested it much but hopefully this will help others.

Thanks for your work dbarar, but that kind of port does not help here. This is a complete detach of th D6 branch and means, to version of content_lock have to be maintained. Also you changed the package, which is not part of the Port, and a lot more things which do not belong to the port, but adjustments / features - that should never happen during a port.

If we port, we need something maintainable. When you port, make as few changed as possible. If you make changes like adjustments, be sure to make them on the D6 branch BEFORE you branch of for 7 ( or rebase ).

subscribe

subscribe

I'd be happy to help with testing once a -dev release is available.

Subscribe

See the 7.x-1.x snapshot release. Please test the parts that are supposed to work (pretty much everything ;-)).

The ability to disable locking based on the type of input one has chosen for a node does not work. If someone understand fields.module and its interaction with node.module -- how to determine the input filter being used for a node, help with that would be appreciated :-). The D6 version of node.module just stored the filter's name in $node->format but now nodes' content is moved to a ``text field''. I would like to fix this before posting a stable release -- and this waiting time will hopefully let bugs in more critical code be fixed in the meantime.

Great! Thank you for taking this work on your shoulders.

With D7 we should def. be able to clock on lock-types, not only nodes. So a touple (type, object-id, user-id), not only (nid, uid). This is needed a lot, actually also for Drupal 6 so we can lock on comments, Taxonomy-editing or whatever people think about. This should become a more general api of "checking object / checkout", so we have a much wider use-case.

Thanks ohnobinki. This is awesome!

I've done a round of basic testing and everything seems to be running great on a clean D7 install. I have tested simple content locking, lockable content types, javascript detection of leaving the node form, breaking locks with the 'Administer Checked Out Documents' permission, and lock timeouts (including 'Break stale locks on edit').

The only thing I've seen is a tiny typo in the permissions UI. It should be "Administer Checked Out Documents" not "Aminister".

The only thing I've seen is a tiny typo in the permissions UI. It should be "Administer Checked Out Documents" not "Aminister".

Thanks, that triviality is fixed in git :-).

I hope to get to the disabling locking based on input-format soon...

Hello:

I am non-programmer using D7.2
with all of the Core Modules enabled (except Overlay)
and no other contrib modules enabled.

I noticed that when I accidentally had two tabs open
in the same browser to edit the same page,
and when I had saved one page and then in the second tab/ page
my clicking "Preview" (or "Save") resulted in a warning...

The content on this page has either been modified by another user,
or you have already submitted modifications using this form.
As a result, your changes cannot be saved.

... and so I wonder if that means you need no longer worry about this module for D7.

... little that I know.

All the best to you.

-Chris

@495096, the same exact form checking happens on drupal6. The point of content_lock is to prevent this from happening accidentally when two distinct users try to edit the same form. It'd be quite unfeasible to prevent a single user from editing the same form twice, which is how you caused drupal to output this error.

Also, if you open multiple tabs for editing the same node in drupal, you hopefully have an idea of what you're doing. When two different users go to edit the same node at the same time, neither would have any idea that the other user is trying to edit the same node unless if a node-locking mechanism like content_lock is used.

Thanks for looking at this module in D7 :-).

ohnobinki:

Thank you. I was wondering if indeed my error was limited
to my being a single user with two instances open.

And the extent of my knowing what I am doing is debatable.

lol. But yeah. I've been fighting with D7 since Beta 6,
so I do have half-a-clue anyway. I know D8 is where the dream now is,
and I almost hate to even bring up any D7 issues since that just takes
time and energy away from you developers
who would be serving the future better
by leap-frogging right on over D7.

All the best to you. Thanks again
for your work... I know D8 is 5 years away
at least.. and I insist on using Drupal only..
and I refuse to go back to learn D6.

-c

Thanks to http://drupal.org/node/889058 I was able to restore node input format discrimination in e5be723, and that change should show up in the dev snapshot within 24 hours.

@EugenMayer, it would be nice to make the locking API more generic. But I think it's more important to just have any stable 7.x-compatible release at all and I plan on rolling one in the next few days ;-). Could you open another issue/bug for this "locking on a tuple instead of just nodes" concept? Thanks!

done #1180278: Make the Locking API generic

content_lock-7.x-1.0.

Issues discovered with this release are to be reported as separate bugs :-).

Awesome! Thanks ohnobinki.