| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far templates required a very complex blurb to simply insert a
thumbnail URL, exposing much of the internal logic to the template
designer. In addition, we would fail with an error if for some
reason the media_files['thumb'] entry was never populated.
This adds the MediaEntry.thumb_url property that template designers
can simply use. It will do the right thing, either fetching the proper
thumbnail or hand back a generic icon specified in a media's
MEDIA_MANAGER as "default_thumb".
Add an image default fallback icon (stolen from Tangos, which are
Public Domain since version 0.8.90 as I understand) since the one
we referred to was not existing. Perhaps, a "broken image" icon
would be better, but I'll leave that to our capable designers.
All templates have been modified to make use of the new thumb_url
function.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
|
| | |
|
| |
|
|
| |
instead of incorrectly getting the session user
|
| | |
|
| |
|
|
|
|
| |
- It is now possible to actually see what's processing, due to a bug fix
where __getitem__ was called on the db model.
- Removed DEPRECATED message from the docstring, it wasn't true.
|
| |
|
|
| |
This commit makes test_submission mostly warning-clean.
|
| |
|
|
|
|
|
|
| |
Oh well:
tools.exif -> processing -> db.util -> db.models -> db.mixin -> tools.exif
So import tools.exif locally in exif_display_iter()
|
| |
|
|
|
|
|
|
| |
MediaEntry.media_data.exif_all will contain all the
"clean" EXIF data.
MediaEntry.exif_display_iter() is an iterator that fetches
the most interesting entries for display from that data.
|
| |
|
|
|
|
|
|
|
|
| |
Using the new check_media_slug_used it is possible to have
one generic generate_slug in the mixin class instead of in
each db class.
In the sql variant self.id is not always set: If the slug
alone would create a dupe the current code decides for "no
slug at all".
|
| |
|
|
|
|
|
|
|
|
|
| |
After a bit of discussion, we decided to drop the
pre-rendered html from the database and render it on
the fly.
In another step, we will use some proper caching method to
cache this stuff.
This commit affects the MediaComment.content_html part.
|
| |
|
|
|
|
|
|
|
|
|
| |
After a bit of discussion, we decided to drop the
pre-rendered html from the database and render it on
the fly.
In another step, we will use some proper caching method to
cache this stuff.
This commit affects the MediaEntry.description_html part.
|
| |
|
|
|
|
|
|
|
|
|
| |
After a bit of discussion, we decided to drop the
pre-rendered html from the database and render it on
the fly.
In another step, we will use some proper caching method to
cache this stuff.
This commit affects the User.bio_html part.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The upcoming SQL database will allow having media without a
slug again. This might especially be useful for API
support, where the uploaded image (media) does not have
*any* information to generate a slug from.
This code change mostly allows the sql backend to have no
slug in its model and improves some parts to properly
handle that.
It specifically does not have any web frontend support to
edit/create MediaEntries with no slug.
|
| | |
|
| |
|
|
| |
translation tags to license template.
|
| |
|
|
|
| |
Move changes from mongo/models:url_for_self back into
mixin:url_for_self.
|
|
|
A bunch of functions on the db objects are really more like
"utility functions": They could live outside the classes
and be called "by hand" passing the appropiate reference.
They usually only use the public API of the object and
rarely use database related stuff.
Goals:
- First, simple: Share the code with the SQL objects, so
that the code doesn't need to be duplicated.
- Second, it might unclutter the db models and make them
more into "model only" stuff.
- Doesn't really hurt.
|
