- Get / verify API Key from l10n server
- Submit translations
- Fetch translations / updates
Reference: Tasks: 75, 76, 55
TODO: Move out of core (and a series of other tasks).
uploader. This is modeled on
http://codex.gallery2.org/Gallery3:Upload_UX but is not yet complete.
Notes:
* Changed #gProgressBar to .gProgressBar to support multiple progress
bars on the same page
* Added a bunch of CSS to the "needs a home" section in
themes/default/css/screen.css
because we need those to make a package.
Fix the packaging code to ignore whatever prefix is being used by the
developer who is doing the packaging.
Update the install.sql file (there were a variety of small
inconsistencies, probably from hand-editing. Don't hand-edit this
file!)
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.
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.
Don't join through to the users table; that won't work in embedded
mode. Instead, add Tasks_Model::owner() that calls user::lookup() and
refer to the object directly in the view.
Add Admin_Maintenance:remove_finished_tasks() so that we can easily do
old task cleanup.
Hide Running / Finished sections if there aren't any running or
finished tasks.
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.
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.
Starting a batch call batch::operation(name, item). In the case of
adding photos name = add and item is the parent of the new items.
When the operation is finished the batch::end_operation(name) is
called.
operation and end_operation events are called. Handlers
(i.e. item_created) can call batch::in_progress(name) to determine if
a batch is being processed.
start_batch and end_batch add and remove the batch id from the
session. Modules wishing to do batch processing, just need to fire
the start_batch and end_batch events. Other modules that need to be
aware of batches (i.e. notifications) just check the session for "batch_id".
events: start_add_batch and end_add_batch. The parameter is a batch
id which is generated on the first add request. The protocol is call
the add_photo as many times as required and then call finish when
done.
Also renamed the add method in local_import to add_photo so it is
consistent with simple_uploader
task.php
* Added a owner_id field to the task database
* Modified the admin maintenace to show the owner of the task
<<**** Requires a reinstallation of core ****>>
idea. Instead convert movies to jpeg before doing any
transformations, which keeps the graphics functions clean and abstract
and dealing solely with image types. Lighter/simpler solution.
