| Age | Commit message (Collapse) | Author |
|---|
|
|
|
directly wherever possible instead of access::csrf_token().
|
|
|
|
the task only has one step from zero to 100.
|
|
|
|
In order to make the class static, I had to remove the index cache.
I'll restore that and cache the index keys in the task context in a
subsequent change. For now, I've put in a @todo to add the caching
back in.
|
|
E.g. "%link_startClick here%link_end" is now '<a href="%url">Click here</a>'.
Note: This isn't always the best solution. E.g. consider "Foo <a href='%url' class='gDialogLink'>bar</a>." Now the translator has to deal with
preserving CSS classes too...
|
|
|
|
ordering and known values. This way subsequent packaging runs won't
have any differences unless there's a real data change.
|
|
core_installer::install() now takes an $initial_install param that
allows us to enforce that we're doing a clean install. Use this in
both the scaffolding and the unit test code.
Greatly simplify the scaffolding uninstall/reinstall code.
|
|
|
|
|
|
- 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!)
|
|
bypassed.
|
|
|
|
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.
|
|
developer module.
|
|
item. ticket #118.
|
|
task::create method call
|
|
|
|
|
|
|
|
the item model and always pass the orderby fields. This insures that
all children or descendant calls will respect the album sort order.
|
|
as two separate columns in the item table.
|
|
|
|
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.
|
|
Fixes ticket #120.
|
|
This helps us to make sure that we only see the welcome message once.
|
|
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.
|
|
|
|
* Remove mime type and type as sortable fields
* Change the internal representation to serialized array
* Shorten the database field to varchar(64)
|
|
Date, Update Date, Random Key, Title, Mime Type, Item Type & Number of views)
|
|
|
|
|
|
|
|
|
|
specify a single type and ask for it appropriately in
admin_maintenance. Specify a type for every existing task.
|
|
|
|
|
|
swf file for now
|
|
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.
|
|
|
|
generating random albums and images
|
|
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
|
