* Front end development according to the mockup
* Save changes in ajax
* Implement the delete album behaviour with Jconfirm in ajax
* Adding a new Css component : infos (factorized in the tag page)
* Add a new general admin template variable : ADMIN_PAGE_OBJECT_ID (adding the id of an object on the page)
* Modify the pwg.categories.setInfo api method to fit the need of the album edition pages
* Slightly change the method time_since, add a parameter to display only the greates time unit
* Popin to change parent album, and changed it as a re-usable component
* Dropdown to replace the checkbox for comments
* migration task to update activity.performed_by (with object_id) for logout action (was always user guest instead of the real user)
* activities: use the actual regrouped lines to list filter users (instead of performing a separate SQL query)
* at the end of the upload of after a maximum duration, move the photos from the lounge to their actual categories.
* do not invalidate user cache when photos are added in the lounge, thus avoiding to rebuild cache on every photo uploaded
* the lounge system activates itself only beyond 50k (by default) photo
In order to change from versions 2.10.x to 11.x.y, Piwigo needs to only consider 11 as the branch, and not 11.x. Or else it will mess up with minor and major updates.
Every 1000 log entry inserted, Piwigo performs an history summarize.
The summarize process has also been optimized: no longer used column
history.summarized (no longer need to update it, which took a lot in time),
we now save the history_id_from and history_id_to in history_summary table.
This way we know from where to start on next summarize.
For now, for a simple performance reason, we keep column history.summarized,
because removing it may take a long time on huge tables. Once we will have
automatic purge on history, it will be safer to drop this column.
By reducing frequency of update on user_infos.last_visit. Instead of updating
on each page visit, we wait at least a session length, which is 30 minutes by
default.
@modus75 suggested to use function log_user instead, which is a better design.
Unfortunately it would lead to much less accuracy, because on many systems PHP
sessions are never purged (Debian with default settings). It would be possible
to come back everyday and never update the last_visit, as long as the web
browser is not closed.
This will speed up user edit popin opening, by avoiding to search in history for the last user visit.
The column user_infos.last_visit_from_history true/false says if the last_visit has already been search in history (to avoid making it twice). I could have implemented the search of last_visit for all users in the migration task 149 but in case of many users and long history, it would have taken years to execute...
When a user successfully performs an authentication with an auth_key, Piwigo
registers it in the history table.
For now, it is not shown/searchable in the history screen, but we can add it
in the future and we can provide a plugin with specific details about
authentication keys usage.
* if formats are available, replace the download link on picture.php by a switchBox with all formats
* register format in the history table for future statistics
* new table piwigo_image_format (each photo can have 0 to many formats)
* only compatible with synchronization for now. Formats must be in sub-directory pwg_format
* formats are visible on edition page only for now
