| Age | Commit message (Collapse) | Author |
|---|
|
|
|
module installers don't have to know the grotty details of how it works.
|
|
* Refactor blocks so that they have a separate id vs css_id. This way
we can have a unique identifier for each visual block.
* Store blocks with a random id as their unique identifier
* Add Admin_Dashboard::remove_block() and modify
themes/admin_default/views/block.html.php to call it when you click the
remove box.
|
|
both the sidebar and the center content area from a dropdown at the
top of the dashboard sidebar.
|
|
admin.html.php looks for $sidebar and renders the page appropriately
if one exists. But only admin_dashboard has one currently.
|
|
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.
|
|
place for it, but it'll do for now.
Do CSRF checking in the Admin controller so that we're safe across the
board on the admin side.
|
|
all dashboard blocks are stored in modules.
|
|
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.
|
