| 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. | 
|  | Install: <module>_installer::install() is called, any necessary tables
are created.
Activate: <module>_installer::activate() is called.  Module
controllers are routable, helpers are accessible, etc.  The module is
in use.
Deactivate: <module>_installer::deactivate() is called.  Module code
is not accessible or routable.  Module is *not* in use, but its tables
are still around.
Uninstall: <module>_installer::uninstall() is called.  Module is
completely removed from the database.
Admin > Modules will install and activate modules, but will only
deactivate (will NOT uninstall modules). | 
|  |  | 
|  | if the page type is album.
Leave a todo if we ever set up a theme default API | 
|  | http://gallery.menalto.com/gallery_3.0_alpha_3_released?page=1#comment-304581
ticket #195 | 
|  |  | 
|  | directly wherever possible instead of access::csrf_token(). | 
|  | reverts to the default theme. | 
|  |  | 
|  | into each theme.  I chose to create methods Theme_View::file($path)
and Admin_View::file($path).  These methods check for a theme override
file in the theme and return a link to it if it exists.  So to
override the themeroller files. just create a lib/themeroller in the
theme and the files will be picked up. | 
|  | which fall through to calling &View::__get() have an lvalue to return,
else you can't return them by reference.
Also, don't show sidebar blocks for pages that don't have an item so
that the rss and tag modules don't break the search page. | 
|  | 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. | 
|  | creating Dynamic Albums.  This name change reflects the usage better
and allows multiple dynamic albums (including tags) to use the same
page template. | 
|  |  | 
|  |  | 
|  |  | 
|  | for us to rename the dashboard helper to be a block helper since
sidebar blocks are not just in the dashboard. | 
|  | eliminates the menu, which is kind of clunky.
While I'm at it, let's call the "regular" themes a "site theme" so we
have "site" and "admin" themes. | 
|  |  | 
|  |  | 
|  |  | 
|  | "view comments" link to the comment menu helper. | 
|  | link added. Also need add the slideshow link to the menu. | 
|  |  | 
|  |  | 
|  | 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. | 
|  | module install/uninstall work and tie it into the messaging system. | 
|  | consistency
with the callbacks in the xxx_block helpers.  So in the theme we have:
admin.html.php:
  $theme->admin_page_bottom()
then in the helpers:
core_block.php:
  function admin_page_bottom() { } | 
|  | the various modules.  In the process, rename xxx_menu::site_navigation() to just
xxx_menu::site().  And add xxx_menu::admin().
The menus are the same as before, but I changed the HTML to be
consistent with the way that we do it in the regular site, and this
broke the superfish styles.  I don't know how to fix this.. help me
Chad! | 
|  | Item_Model and simplifies
file_proxy.  It also means we can stop munging file names in the var/resizes hierarchy.
In the process, rename "thumbnail" to "thumb" everywhere in honor of
Chad (well, ok because it's shorter).. | 
|  | o Copy all the assets from default to default_admin so that they're
  totally separate
o Get rid of $item_theme
o Rename list_users.html.php to users.html.php
o use __call in admin controller to allow us to load any admin page | 
|  | other functionality.  This makes our user/group and access code
fully consistent. | 
|  | new menu code | 
|  | chainable factory interface and retrieve them by ids.  Streamlined the
HTML creation code a little bit in the process, moved the basic menu
functionality into Theme_View and created the option to have different
menus other than site_navigation(). | 
|  |  | 
|  |  | 
|  |  | 
|  |  | 
|  | 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) |