I'm having some performance issues with button_with_confirm on /tags.
This won't magically make that faster but I'm trying to stop the main
thread from dragging at least.
I am also considering applying the opposite effect when ungrouping.
Should a photo with A.B get A when A and B are ungrouped? There are
some cases where the answer is yes, and others no, depending on the
reason you're ungrouping the tags. Whereas this change is non-
controversial and simply enforces the existing standard of adding
more specific tags to a photo.
I wrote this because I felt it would be a useful shorthand, as a way
of nuking all tags of a subtree off a photo, but it's too easy
to cause collateral damage when composing remove_tag with other
functions. So, when you remove tags from a photo, you'll have to be
more specific.
That should not have been there!
Needed to add the BAIL sentinel so that Tag methods would only
reset the cache if the internal method actually did made any changes.
add_children was calling add_child in a loop. Since this is a parent
class, that call would actually call the subclasses' add_child method,
which has a transaction decorator, and create unnecessary transactions.
Foolishly, I was checking the length of the outputted easybake format,
which included lines for synonyms and multi-parent tags that shouldn't
be part of the tag count.
I'm currently running an experiment where albums are also included in
search results, but they don't cost you any of your limit parameter.
So the len(results) was often bigger than limit and tricking this
paginator into thinking we needed a next page when really we didn't.
This workaround can be undone when I decide how to make the album
results more official.
I skipped them during the commit where I added return to all onclicks
because I figure I won't be wrapping these kinds of attributes.
But I feel like it's better to be consistent and you never know when
it might happen.
Instead of requiring a page refresh to see the new tags. They
just won't be sorted.
Slight bummer, the datalist dropdown pretty much obscures the
whole thing anyway.
Following the previous commit about the checkbox on the /photo page,
this fixes all of the code assuming that we're dealing with photo_card
divs, the majority of which was doing nothing but accessing the id.
