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.
enter a module name, a description and pick the call backs and or
events they want to support and generate the basic module skeleton
with one click.
@todo: clone a module, clone a theme, generate skeleton controller,
view,
creating the page. Provide for a default page title if none is
set. This allows less changes to page.html.php as different modules
want to change the page title.
url:site(url::abs_file(...))
Create a login_page.html to be used when there is no guest access to
the root album. It doesn't have a sidebar nor breadcrumb.
them a nice "Welcome to Gallery 3" dialog. The text in there needs a
little work but it's a start.
In the process, re-build the install.sql using the scaffolding code.
- Show the "Server Add needs configuration" message whenever
there are no paths.
- Un-ajaxify the admin code to remove complexity and allow us to
update the status message as appropriate.
- Rename server_add_admin.html.php to admin_server_add.html.php
for consistency.
- Fix up form to properly display error messages
- Get rid of server_add_dir_list.html.php now that we're
non-ajaxified.
- Change delete <span> to an <a> for non-ajax world.
batch::start() before starting a series of events, and batch::stop()
when you're done.
In batch mode, the notification module will store up pending
notifications. When the batch job is complete, it'll send a single
digested email to each user for all of her notifications.
Updated the scaffold and local_import to use this. Haven't modified
SimpleUploader yet.
* Allow for the "movie" type in all of our text
* Try to follow the pattern of mainly only passing ORM objects
to the view and let it generate its own text (this becomes
even more important when 3rd parties want to customize notification
messages)
* Rename _send_message to be _notify_subscribers to be more acccurate
and have it explicitly take a subject in the API
* Use Item_Model::url() in the views instead of hand crafting URLs
* Reformat HTML in views
* Use $comment->author_xxx() functions instead of replicating that code
* Fix several places where we were encoding data by doing ucfirst($item->type)
with conditionals where we form the text properly. We should *never*
be showing data types to the end user! This is not localizable!
Note that this probably breaks the existing batch processing code. I
am going to redo that in a subsequent pass.
