| 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).
|
|
|
|
|
|
|
|
|
|
vars. We'll eventually turn this into a registry where you can edit
settings directly (at your own risk).
|
|
user/groups admin menu option appears again.
|
|
the links work and it's more helpful.
In the process, rename the Presentation menu to be Appearance because
that makes more sense to me (and at least one other user who wrote
about it on -devel).
|
|
|
|
data creation and the packaging code. The rest ofthe functionality is
either no longer required, or moved to the developer module (MPTT
Tree).
Also provide checking for the active user to be an admin.
|
|
|
|
developer module.
|
|
|
|
it so that it fits on one line.
|
|
|
|
This requires a little trickery to proxy the session id and user agent
through the ActionScript code so that we can assume the same session
in the uploader. It's also using its own path to add photos since
we'll want to have a slightly different protocol for dealing with
responses (as opposed to JSON or HTML).
A work in progress for sure, but it's already better than what we had before.?\024
|
|
Only available to admins at this point.
|
|
anyway
|
|
|
|
Convert all item->type == "photo" to item->is_photo()
|
|
link.
|
|
user has authotization before displaying the view fullsize icon. It
probably needs a better icon, (but u make do with what u have or don't
have :-) )
|
|
have a welcome page.
|
|
|
|
users to groups.
|
|
|
|
|
|
Need edit album methods added to the quick controller.
|
|
File_Structure_Test to make sure we don't regress.
According to the PHP docs, the "public" keyword is implied on static
functions, so remove it. Also, require private static functions to
start with an _.
http://php.net/manual/en/language.oop5.visibility.php
|
|
* Add 'Scaffold' link to make it more obvious what's going on there
* 'Home' link now goes to albums/1
* 'Admin' is now pushed to the far right.
|
|
|
|
- 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.
|
|
|
|
|
|
|
|
"view comments" link to the comment menu helper.
|
|
link added. Also need add the slideshow link to the menu.
|
|
Rename menu "General Settings" -> "Settings"
Rename "Comments Moderation" -> "Comments"
Move "Content" -> "Configure Spam Filtering" -> "Settings" -> "Spam Filtering"
|
|
|
|
up the tree
|
|
yet, but it shows you which items have locked view perms.
|
|
toolkit we use. We only allow users to use one toolkit. The UI needs
work!
|
|
the database. They're started with admin/maintenance/start/[task_name]
which sends down some JS/HTML which regularly pings the task at
admin/maintenance/start/[task_id] until its done.
The UI is still very rough. It works, though!
|
|
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.
|
|
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.
|
|
|
|
Each module now has a "module.info" file that has information about
the module, including the core. We can display the installed version,
and the version in the code.
Also take a first shot at a modules admin page.
|
|
|
|
1) They must all start with "admin_". This pattern is not directly
routable.
2) Their urls must be /admin/xxx.
3) The Admin_Controller will take the xxx and look for Admin_Xxx_Controller
and will delegate to that admin controller, after doing security checks.
Moved the users and dashboard views into individual modules for now.
|