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.
I discovered that werkzeug stores cookies in lists, with its .get
returning only the first item of the list. By converting the cookies
to a plain dict, I was breaking that functionality of cookies.get.
So, using werkzeug's MultiDict is the correct choice.
At some point, I changed tag_export.flat_dict from using strings as
keys to using actual Tag objects as keys. The tag expression handler
never got updated, so frozen_children[tagname] raised KeyError as
it was looking for a string.
I considered using tag_expression_tree.map to convert all the tree
tokens into tag objects, but when we render the tree back into text
it will say "Tag:name" instead of just "name" throughout the whole
expression, and I don't want to deal with converting those back.
voussoir