Item_Model::viewable() because it's too dangerous to separate that out, and it's fragile to
rely on only admins doing tag combines.
Revert "Undo the change made in 5ce8563632 because it messes up tag counts"
- This reverts commit 67d2e8081c.
Revert "Move the calculation for item_related_update ahead of the duplicate"
- This reverts commit 5ce8563632.
question mark, so any tags containing an apostrophe won't display
their contents.
Take the simple fix here and change the tag urls to also contain the
tag id, which avoids having to add a slug for the tag and all kinds of
validation code.
Fixes#1636.
don't try to update the tag item count if we didn't change any items
with this change (ie: a tag rename). In that case, we haven't loaded
the related items so we don't have any idea what the count is going to
be.
results of the $theme->css() and $theme->script() calls. This handles
the case where combining scripts/css returns HTML instead of putting
it in the queue for combination. Fixes#1611.
1) We're compacting tags on every deletion which is slow. Since we delete
albums in batch, we should just do one tag compaction at the end. Fixes
#1487.
2) Issue introduced in 3d952f41c8 where
we trigger an item_related_update in tag::clear_all(). Since
tag::clear_all() is called when we delete an item, this causes
the search module to attempt to index a deleted item. Move that
triggering upstream.
when adding a tag to lots of items. Tag_Model::save() would call
item_related_update for every tag related to an item upon save which
is an O(N!) operation. Fixes ticket #1412.
by the following rules:
1) An initial dialog or panel load can take either HTML or JSON, but
the mime type must accurately reflect its payload.
2) dialog form submits can handle a pure HTML response, but the mime
type must also be correct. This properly resolves the problem
where the reauth code gets a JSON response first from the reauth
code, and then an HTML response when you reauth and continue on to
a given form -- try it out with Admin > Settings > Advanced.
3) All JSON replies must set the mime type correctly. The json::reply
convenience function does this for us.
4) By default, any HTML content sent back in the JSON response should be
in the "html" field, no longer the "form" field.
The combination of these allows us to stop doing boilerplate code like
this in our controllers:
// Print our view, JSON encoded
json::reply(array("form" => (string) $view));
instead, controllers can just return HTML, eg:
// Print our view
print $view;
That's much more intuitive for developers.
