modules, and have an admin subdirectory that is treated like a Kohana
module (as distinct from a Gallery module).
The main advantage of creating the separate admin subdirectory is that
we will not load an admin theme and a site theme at the same time.
We'll only load a few specialized bits of the site theme while the
admin theme is active.
Concrete examples. A site theme named "xxx":
- will receive events at themes/xxx/helpers/xxx_event.php
- will have working controllers at themes/xxx/controllers/xxx.php
If theme xxx has an admin subdir, then in admin mode it:
- will receive events at themes/xxx/admin/helpers/xxx_event.php
- will have working controllers at themes/xxx/admin/controllers/xxx.php
PATH_INFO and pass it to the theme::load_themes method. If it starts with
\"/admin\", then set the theme to the active admin theme, otherwise set it to
the active site theme. Fixes ticket #841: Themes cannot overload event classes."
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.
