Exclusive locks are nothing new. It is a basic concept that tons of multi-user programs, tools, and systems use so that users don’t step on each other’s toes when they’re trying to work on something. It would be awful if you spend 30 minutes editing an article only to find that someone else stepped in and blew away your edits because they saw a typo and jumped in to quickly fix it. Sitefinity is no different in this regard: Pages, built-in content, and custom content all have built-in locking functionality. If you’ve worked with other content editors on a Sitefinity site in the past, you’ve probably run across this message when attempting to open something up for editing:
This is a great, simple way to inform you that someone else is currently working on something and the content is otherwise unavailable for edit at the moment. However, that might not end up being the case all the time in Sitefinity. Due to the method of implementation, the above image could actually be displaying incorrect information about the current state of the content item: Perhaps that user actually stopped working on the content hours ago and has long since signed off. Let’s explore what Sitefinity is up to, how to work around it, and how to prevent this scenario from happening in the first place.
The Problem
The biggest issue regarding locks in Sitefinity is that locks never expire. If I go in to edit a Page, for instance, then I get pulled away to work on another task, or I inadvertently close my browser, Sitefinity will happily keep that Page locked under my name indefinitely. Sitefinity does this because the lock guarantees that your current Temp copy (using Sitefinity content lifecycle terminology) of the Page is only preserved for as long as you are the only one editing the Page. If someone were to come in and edit it, my Temp copy would get blown away.
At face value this makes sense: If my computer loses power or my browser crashes, I definitely do not want Sitefinity to instantly release the lock and lose my changes. But if I close my browser without realizing the edit is still open, and go about my day, that content is staying locked and there’s no value to preventing others from accessing it. Sitefinity will happily close it off from everyone else forever. This is not good! While Sitefinity will let me back in to the Page to continue editing without a fuss, other users will be greeted with a Locked message:
Sometimes this can even happen by accident. If I close my browser/tab thinking the content will get unlocked simply by leaving the session, I would be gravely mistaken! So what can we do if I’m out of office saving the world and rescuing the President, therefore having no time to log into Sitefinity to undo my locks?
The Nuclear Option (Administrators Only)
Users with higher privileges like Administrators in Sitefinity see the world a bit differently. When they run into locked content, they actually have a skeleton key at their disposal.
An administrator can, at any time, unlock any locked content to make it available. This option should not be taken unless you have confirmation from the user locking the content or if you absolutely have to make an edit. Forcibly unlocking content will permanently destroy the Temp copy that user was working on. Much like the intended scenario described above, unlocking in this manner eliminates the Temp copy, restoring the content to its original state. It is good that this skeleton key is available, but it must be used wisely, or else you’ll have some angry content editors to deal with!
A Better Way: Using Best Practices when Working with Content
The optimal solution to this is actually to teach proper editing etiquette when working in Sitefinity. Locks should only be seen as “someone is presently actively working on this content”, as opposed to the potential “someone left the door locked and escaped through the window, so there’s no way in” scenario that Sitefinity locks enable.
The following tips should be followed when editing Sitefinity content, so that locks are always meaningful, and nobody is left permanently locked out. The basic solution is to always use the navigation options presented within Sitefinity itself, as opposed to using your browser to accomplish the task. Detailed explanations follow below.
If you wish to abandon your changes, then you must exit the page properly, in order to communicate to Sitefinity that you no longer wish to have the content locked. To do so, click the red link at the top of the Sitefinity page when editing, which typically reads “Back to {Content Type}.” This safely backs you out of the currently-editing content, destroys your Temp copy, and frees the content up for editing by other users.
If you wish to save your changes to work on them later, you’ll want to click the “Save as Draft” button, again available at the top of the page. This will change the visible status of the content from “Locked by ” to “Draft (newer than Published).” Your Temp copy is transferred to a Draft copy, which is non-volatile and safe from automatic deletion. Not only does this free the current version of the content up for edits by others (should the need arise), but it also clearly informs other users that you have saved changes, but are not currently working on the content in question.
Always keep in mind: Never use your browser’s back button, or close your active session/browser/tab! This circumvents any methods Sitefinity has built in to prevent locks from being created indefinitely, and leads to the confusing/blocking scenarios described earlier in this post. Sitefinity is generally good at giving you an alert or warning when attempting to use these, and they should be heeded!
Summary
Sitefinity locks serve the same purpose that other system exclusive locks do and help prevent changes from getting lost, but due to their indefinite implementation can lead to some frustrating scenarios. Administrators can brute force their way past locks, but that comes at the cost of losing the locked content changes. Arming content editors and all Sitefinity backend users with the knowledge of how to properly destroy their own unwanted changes, or save their changes for later, can help alleviate and avoid these situations altogether. Using the navigation options and tools within Sitefinity should always be done in lieu of closing your browser or using the back button.
Good luck, and happy content editing!
The post Locks in Sitefinity: Keeping Content Free appeared first on Falafel Software Blog.