| Age | Commit message (Collapse) | Author |
|---|
|
Order the finished tasks by update time in the task list.
|
|
Task library class as a data structure to hold task definitions.
|
|
|
|
t($message, $options=array()) into 2 separate functions:
- the new t($message, $options=array()) is for simple strings, optionally with placeholder interpolation.
- t2($singular, $plural, $count, $options=array()) is for plurals.
|
|
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.
|
|
inside a string. We could do "{{{$key}}}" but that's misleading.
|
|
|
|
more intuitive.
Renamed Translations_Incoming to Incoming_Translation to suit.
|
|
* 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.
|
|
|
|
|
|
|
|
- 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.
|
|
- Using DB table translations_incomings as translations storage (file cache to be added)
- Removed overly complex i18n code which will be unnecessary with the future compiled cache files
- Added t() as a translation function (global refactoring from _() to t() to follow)
|
|
|
|
|
|
|
|
"view comments" link to the comment menu helper.
|
|
link added. Also need add the slideshow link to the menu.
|
|
|
|
Added support from http://forum.kohanaphp.com/comments.php?DiscussionID=164
|
|
|
|
toolkit we use. We only allow users to use one toolkit. The UI needs
work!
|
|
|
|
into site_status. Show site status in the header in the admin theme.
|
|
|
|
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.
|
|
changed.
|
|
module install/uninstall work and tie it into the messaging system.
|
|
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.
|
|
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() { }
|
|
|
|
block.
|
|
|
|
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)..
|
|
wasn't benefitting us, and it will get in the way when we want to add
implicit view protection to our queries.
|
|
o Add model_cache::get() which caches models avoiding duplicate lookups
o Stop using ORM relationships for Item_Model::owner so that we can use caching
o For Item_Model::xxx_edit fields, don't make them editable for guests
o Other minor stuff.
These optimizations reduce the number of queries for a 9-photos page from ~200
to ~45. Still way too many!
|
|
|
|
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.
|
|
|
|
1) separate the classes that are generated by the Menu class from what is used for the rendering. The classes that are generated are gMenu, gMenuElement, and gMenuDialog for the Menu, Menu_Element and MenuDialog classes respectively.
2) Changed the ui.init.js to add the appropriate rendering classes to the above classes. All gMenu elements have the sf-menu class added. All elements of class gMenuDialog have the gDialogLink class added.
3) Use Superfish for the menus so they now float properly.
|
|
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().
|
|
faster and tighter.
|
|
(Menu's, Menu_Link, Menu_Dialog)
|
|
|
|
with a #. this results in a modal dialog box being opened. At this point the url is not retrieved and the text just shows up in the dialog box... need to look at that
|
