If a @transaction method makes calls to other @transaction
methods, and one of those nested calls makes a commit, and then
the outer call raises an exception, then the outer call will
not rollback properly because its savepoint is no longer in
the savepoint stack. So let's warn the user if that happens.
Should this raise an exception instead of just warn? Not sure,
I mean the data is already committed.
I didn't know about these! Now we don't have to roll all the way
back in case of problems. This allows for raising exceptions as
control flow since they won't undo unrelated stuff.
Any element with class clipboard_size will have its text updated;
Removed the call to on_pageload from save_ because it redundantly
causes a load. Separate those update hooks.
There was a bug where moving an album out of its determined parent
caused future digests to fail because I wanted to use the GroupExists
for control flow, but due to the @transaction decorator it was rolling
back the changes.
Moved some of the logical pieces of the function into subfunctions
as a visual and readability aid.
Appearing on search and album pages, the tray is where you can
remove items from your clipboard without having to click on its
checkbox -- that photo card may not even be on the current page.
add photo and search css for narrow screens; incorporate new expressionmatch kit; entry_with_history cursor moves to end; albums indicate total filesize; etc
