| Age | Commit message (Collapse) | Author |
|---|
|
|
|
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.
|
|
https://github.com/gallery/gallery3/pull/58/files#r72949.
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.
|
|
|
|
some other items belonging to the same parent album are not viewable.
Changed depracated calls to item_Model::get_position() to item::get_position().
|
|
Fixes #1569.
|
|
Allows for cleaner code and fewer function calls.
|
|
Added common increment_view_count() func in item model for reuse
|
|
that the theme can call empty() on it. Fixes #1318.
|
|
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.
|
|
method to set the content type header and encode the response as a json object
|
|
dialog. Convert all the controllers
that create the data to go into a dialog to return the html as part of a json object.
|
|
|
|
|
|
registered users (not to admins though). And show a login form to guests for 404 (incl. insufficient view permissions) errors.
|
|
1009.
Side effect: Renaming auth::required_login() to login_page().
|
|
permission into the common auth::require_login() method.
|
|
to a logon page to allow the user to login. Pass the target url as a session
variable to allow the user to be redirected where they want to go if the login
was successful. Fixes ticket #1009.
|
|
consistency between field names than deal with underlying issues with
Forge bitching about the "name" property.
|
|
|
|
guess how to send the user back. Instead, proxy the originating item
id through the edit forms so that we can tell exactly what page we
were on when we began editing. If we were viewing the item, then
redirect to its new url (in case it changed) to fix ticket #745. But
if we were viewing some other item, then just stay on the current page
to fix #940.
The page_type approach didn't work because you'd have the same
"collection" page_type when doing a context menu edit for an album.
|
|
|
|
|
|
1) The new default route is "albums", and Albums_Controller::index() does the right thing
2) Items_Controller redirects to the appropriate specific controller
3) All item controllers now have show() instead of _show(), so that
the routing code in url::parse_url() can get to it. But that code is protected against
receiving bogus requests.
|
|
|
|
where clauses and adds them to the existing query. Update all
existing queries that take an additional where clause to use it.
|
|
Convert all open_paren() calls to and_open() or or_open() as appropriate.
|
|
Partial fix for ticket #917
|
|
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.
|
|
Was also able to remove the sub-select from the calculation of the current position as we already have the child item containing the sort column value.
Also added a where clause that ignores albums to the get_position, children and children_count method calls in photos.php and movies.php
|
|
from the context menu or from its photo or album page.
Fixes ticket #745. Thanks to jankoprowski for the referrer approach.
|
|
part of the response. This insures that if the internet address changes, then
the page will reload properly.
|
|
If you can change the extension, then you can alter the way the server
handles the file, which is a security problem. So for example, you
can change a .JPG to a .PHP and then if you put some malicious PHP
code in the EXIF data, you can get the server to execute
it. Vulnerability is low because only users who have edit permissions
could do this.
Fixes ticket #846
|
|
|
|
This is not currently necessary (nor is it a security hole) because we
don't constrain permissions at the child level in the core, but it
makes our security audits easier and will enable the scenario where
somebody writes a module to add per-photo permissions.
|
|
row has a null value in the sort field. Fix for #627
Note: this changes get_position() to take an Item_Model instead of an id!
|
|
we're not relying on overriding url::site() to do tricks around item
urls. This means that you won't get item urls by doing
url::site("albums/37"), for example, but it also means that we won't
get pretty urls where we don't expect them (like in the action of a
<form> element).
Incidentally, this will help us move over to using the slug format
because if you've got a bad character in a url, the edit forms will
now work on it since they'll be id based.
|
|
2. Fix up an issue where we were crashing if there were no conflicting rows
3. Amend Item_Model so that if you change the slug, it flushes the cache
for all children
|
|
validation for the fields.
|
|
|
|
|
|
SafeString::purify().
Removing any p::clean() calls for arguments to t() and t2() since their args are wrapped in a SafeString anyway.
|
|
tag_event:item_edit_form to use the new Form_Script library to inject
script into a form.
Signed-off-by: Tim Almdal <tnalmdal@shaw.ca>
|
|
This required putting a wrapper view around the forms and passing
this view as the parameter to the item_edit_form event. The view
contains a $script variable that the modules can add script to be
included in the form html when rendered as part of the ajax response.
|
|
good pattern for allowing modules to add their own hooks to item forms!
1) Album, photo and movie forms now all use edit_item as the group and
we publish item_edit_form and item_edit_form_completed events which
makes it much easier in the module to handle all events. They can
still differentiate based on $item->type if they want to.
2) Added tag::clear_all() and tag::compact() functions which takes the
place of hiwilson's tag::update() function and is now used in
tag_event::item_delete(). This provides a simple API that allows
us to have a lot less event handling code. It's less efficient
than what hiwilson was doing before in that it will delete and
re-add tags, but if that ever turns out to be a performance issue
we can do something about it then.
|
|
functionality. (3)support multi-word tagging.
|
|
related events from within the model handling code. The only
exception to this currently is item_created which is challenging
because we have to save the item using ORM_MPTT::add_to_parent()
before the object itself is fully set up. When we get that down to
one call to save() we can publish that event from within the model
also.
|
|
1) The item_updated event no longer takes the old and new items.
Instead we overload ORM to track the original data and make
that available via the item. This will allow us to move event
publishing down into the API methods which in turn will give us
more stability since we won't require each controller to remember
to do it.
2) ORM class now tracks the original values. It doesn't track
the original relationships (no need for that, yet)
3) Added new events:
item_deleted
group_deleted
user_deleted
|
