| Age | Commit message (Collapse) | Author |
|
Kohana makes this type of transition fairly straightforward in that
all controllers/helpers/etc are still located in the cascading
filesystem without any extra effort, except that I've temporarily
added a hack to force modules/gallery into the module path.
Rename what's left of "core" to be "application" so that it conforms
more closely to the Kohana standard (basically, just
application/config/config.php which is the minimal thing that you need
in the application directory)
There's still considerable work left to be done here.
|
|
Fixes ticket #278.
|
|
accuracy
|
|
the album title.
|
|
|
|
when adding photos/movies/albums
|
|
if the page type is album.
Leave a todo if we ever set up a theme default API
|
|
at thumbnail creation. This will remove the upscaling effect
|
|
150. Use this in the the default theme, or any other, to reduce the size of CSS widths and heights in albums, including .gItem.
|
|
|
|
We now have two clear and separate login approaches:
login/ajax
login/html
Choose the one that's appropriate. Totally simplified the maintenance
page to be separate from the theme and dead simple, and use login/html
approach there. Totally simplified the top level login
(login_page.html.php) to just be a login page, not the rest of the
chrome on the page and use the login/ajax approach there.
Don't use access::required in albums and then catch the exception,
instead use access::can and check the return code.
Improve the text for maintenance mode.
|
|
item. ticket #118.
|
|
the item model and always pass the orderby fields. This insures that
all children or descendant calls will respect the album sort order.
|
|
as two separate columns in the item table.
|
|
This helps us to make sure that we only see the welcome message once.
|
|
* Remove mime type and type as sortable fields
* Change the internal representation to serialized array
* Shorten the database field to varchar(64)
|
|
Date, Update Date, Random Key, Title, Mime Type, Item Type & Number of views)
|
|
This fixes a bug where deleting the last photo on a page would take
you to a 404.
|
|
|
|
|
|
album_created, photo_created -> item_created
album_updated, photo_updated -> item_updated
|
|
|
|
- And refactor printf to our string interpolation / pluralization syntax
- Also, a slight change to the translations_incomings table, using binary(16) instead of char(32) as message key.
|
|
can do comparisons
|
|
|
|
Introduce a "show" parameter which contains the id of the item that we
want to show when we go to the parent's page.
|
|
directly help since text/html works just as well for our JSON communications
|
|
|
|
|
|
1) they now have their own matching severity constants
2) they both have convenience functions success(), info(), warning() and error()
3) they both have severity_class()
|
|
communicate. Almost all controllers now use JSON to speak to the
theme when we're dealing with form processing. This means tht we only
send the form back and forth, but we use a JSON protocol to tell the
browser success/error status as well as the location of any newly
created resources, or where the browser should redirect the user.
Lots of small changes:
1) Admin -> Edit Profile is gone. Instead I fixed the "Modify Profile" link
in the top right corner to be a modal dialog
2) We use json_encode everywhere. No more Atom/XML for now. We can bring those
back later, though. For now there's a lot of code duplication but that'll be
easy to clean up.
3) REST_Controller is no longer abstract. All methods its subclasses should create
throw exceptions, which means that subclasses don't have to implement stubs for
those methods.
4) New pattern: helper method get_add_form calls take an Item_Model,
not an id since we have to load the Item_Model in the controller
anyway to check permissions.
5) User/Groups REST resources are separate from User/Group in the site
admin. They do different things, we should avoid confusing overlap.
|
|
|
|
their results, as opposed to having them return their view back
upstream. This is a little more code in every controller, but it's
much less magical and more consistent.
Look up the active_theme and active_admin_theme inside the view
itself, no need to do that in the controllers. This makes view
initialization easier in the controllers.
|
|
1) Deleted in-place-editing. We'll be replacing this with a real edit
system that groups settings together and is more coherent.
2) Tweaked the way that dialog boxes work to get the ajax stuff working
again. It's imperfect and does not work properly for uploading images.
This is going to get redone also, but this is a good resting point.
3) Created edit forms for albums and photos. Moved _update and _create out
of Items_Controller and into the individual subclasses.
4) Created access::required which is a shorthand for:
if (!access::can(...)) {
access::forbidden();
}
5) Added validation rules to Items_Model
6) Converted login to use the regular modal dialog approach in the theme.
|
|
|
|
|
|
just items viewable by the active user. Ie:
ORM::factory("item")
->where("name", "foo")
->find_all()
Would get all items with the name "foo".
ORM::factory("item")
->viewable()
->where("name", "foo")
->find_all()
Restricts it to just the set of items that the user is allowed to see.
|
|
resulting in
loading all photos in an album on a single page and updating the var on every page load.
|
|
"page size" in the vars table and initializing when the core module is installed
|
|
minimize reloading objects from the database.
|
|
|
|
the album tree. I haven't had a chance to figure out why the form does get any styling or why a textarea is no included as a list item.
|
|
|
|
class with the View class.
2) Only define the form.html.php::DrawForm method once if there are multiple forms on the page (i.e. comments and add tags)
|
|
|
|
Create the concept of "page types" which let us specify the kind of
page that we're rendering in high level terms. Currently there are
three page types: album, photo and tag.
The tag page type uses slightly different variables. It has a $tag
but no $item. Adjust all sidebar_block() functions to avoid printing
stuff that's dependent on the item if there is no item.
Simplify the tag code to stop trying to fake an item.
Update the theme slightly to use $item and $tag where appropriate
(notably, for making the <title> element).
|
|
1) We now use __call() in REST_Controller to handle any requests to a controller
that were not already handled. In the case of RESTful controllers, this should
be the only entry point (although they're free to break the model and add other
ones.. nothing stops them).
This means that we can remove all the catch-all routes in
routes.php which greatly simplifies it.
2) Move request_method() and output_format() out of REST_Controller and into the REST
helper in core/helpers/rest.php
3) Experiment with letting the various subclasses check the output_format and deal with
it themselves. This simplifies the API, but it might be a bad idea in that it might
push too much work to the individual controllers. It's a balancing act, time will tell,
I'm willing to change it back later.
|
|
in order to follow the convention that controllers that refer to a collection of resources have plural names.
* Added a bug workaround to routes.php
|