- jQuery 1.90
- jQuery UI 1.10
- Superfish 1.5.1 (minus all plugins)
- jQuery Form 3.26.0-2013.01.28
Deleted all other jQuery plugins for now.
- Reworked autocomplete to use the latest jQuery code.
- Deleted references to $.browser.msie, no longer supported
- Basic CSS support for autocomplete - lots more work needed there
In MySQL queries, _ and % characters are treated as wildcards (similar to ? and *, respectively).
- Added escape_for_like function to MY_Database.php
- Added unit test to Database_Test
- Corrected the five unescaped instances in the code using this function.
against UTF-7, and create a $.gallery_autocomplete variant of jQuery's
autocomplete that expects the first line to be a <meta> tag and
discards it. More complete fix for #1871.
1) Move the display context code into the controller themselves so that it's
more logically a continuation callback from the original controller
rendering code.
2) Simplify the display context set/get code and put it in the item helper,
it's just a couple of lines of code now.
3) Add more descriptive breadcrumb strings
Create the concept of a Photo_Display_Context. If the user is browsing a dynamic album (i.e. tags) and chooses to
look at an image in that album. The display of the image happens correctly, but the 'next' and 'previous' buttons
are no longer consistent. When one of these is clicked, Gallery will open the adjacent image in the actuall album,
not the dynamic album.
- Breadcrumb::build_from_item becomes Breadcrumb::array_from_item_parents
- Eliminate Breadcrumb::$id -- it's no longer necessary
- Fold Breadcrumb::generate_show_query_strings into Breadcrumb::array_from_item_parents
- Create Breadcrumb::set_first() and Breadcrumb::set_last()
- Breadcrumb::build_from_list goes away, we just use arrays for this
- Change Search_Controller and Tag_Controller to just create an array
of Breadcrumb instances with the first/last marked appropriately
- Breadcrumb_Test loses a bunch of complexity.
Create a Breadcrumb library which has two static methods for_item (which takes a an item and builds the entire
breadcrumb for the item) or build (which takes a variable number of Breadcrumb elements and creates a breadcrumb
based on the specified elements).
Used tag->url() to build the tag album url. Escaped the query string for the search. Tightened up the breadcrumb code
in page.html.php.
When adding the show query parameter, we can't blindly concatenate using the ? separator. We have to check that we
use a & if a query parameter already exists.
- Breadcrumb::build_from_item becomes Breadcrumb::array_from_item_parents
- Eliminate Breadcrumb::$id -- it's no longer necessary
- Fold Breadcrumb::generate_show_query_strings into Breadcrumb::array_from_item_parents
- Create Breadcrumb::set_first() and Breadcrumb::set_last()
- Breadcrumb::build_from_list goes away, we just use arrays for this
- Change Search_Controller and Tag_Controller to just create an array
of Breadcrumb instances with the first/last marked appropriately
- Breadcrumb_Test loses a bunch of complexity.
Create a Breadcrumb library which has two static methods for_item (which takes a an item and builds the entire
breadcrumb for the item) or build (which takes a variable number of Breadcrumb elements and creates a breadcrumb
based on the specified elements).
Used tag->url() to build the tag album url. Escaped the query string for the search. Tightened up the breadcrumb code
in page.html.php.
When adding the show query parameter, we can't blindly concatenate using the ? separator. We have to check that we
use a & if a query parameter already exists.
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.
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.
1) Controller::$input is gone -- use Input::instance() now
2) Handle new 'database.<default>.connection.params' parameter
3) Handle new 'cache.<default>.prefix' parameter
types, and a subtype for specifics. Currently the top level bucket
collection, item, other
Here are the core subtypes so far:
collection: album, search, tag
item: movie, photo
other: login, reset, comment-fragment, comment
It's legal to create new page_subtypes whenever you want. Use the
appropriate page_type to get the coarse grain behavior that you want.
1) Only allow 1 in place edit to be active at a time (gets around the issue of using an id to identify the form
2) remove the add_ prefix from some of the api methods
3) clean up inconsistent naming
