The last update made the assumption that EXIF metadata is in some way
consistent between camera models, images, manufacturers. This update
takes into account that nothing is certain whenever EXIF is involved.
To get us moving towards a MediaManager class, the first
idea is to create a class that wraps our current dict based
manager and makes all users happy.
I think this is legacy code from get_display_media being a utility, or
something. Removed! (Thanks for pointing this out, Elrond!)
This commit sponsored by Tristan Chambers. Thank you!
- Update get_display_media in several ways:
- now uses the media type's own declaration of the order of things
- returns both the media_size and the media_path, as per the docstring
- implicitly uses self.media_files as opposed to forcing you to pass it in
- update videos to use get_display_media
- update images to declare media_fetch_order in the media manager (videos also)
- update stl to use media.media_files['original'] instead of weird
use of get_display_media
- update sidebar to only conditionally show webm_640
TODO still: identify video type information *during* processing, show
that in the <video><source /></video> element.
This commit sponsored by Nathan Yergler. Thanks, nyergler!
Thanks to tchernobog for catching this (it was breaking on postgres)
and Elrond for the suggestion on how to fix it.
This commit sponsored by Caleb Cooper. Thanks Caleb!
Okay, that's a totally confusing statement, but the docstring of this
migration summarizes it well:
Entries without slugs now display differently in the url like:
/u/cwebber/m/id=251/
... because of this, we should back-convert:
- entries without slugs should be converted to use the id, if possible, to
make old urls still work
- slugs with = (or also : which is now also not allowed) to have those
stripped out (small possibility of breakage here sadly)
This commit sponsored by John Sullivan. Thanks johnsu01! :)
If one deletes a media with attachments, there have been
various problems:
1) If the file in the storage did not exist any more (maybe
because due to a previous deletion attempt?), the error
propagation failed, because the wrong thing was
gathered.
2) The attachment database entries were not deleted.
Using cascade for this, for now.
Also add a simple unit test, that tests both by having a
broken attachment on a media.
Instead of doing query by hand, use the relationships on
the models to find the media_data. Is is made possible by
the BACKREF_NAME in each models.py, which lets us know the
local attr to ask for.
Also initialize the relationship attribute on new
media_data instead of the media_id. Also do not add it to
the session. This gives us:
- This automatically initializes the other side of the
relationship, which will allow later acces via that way.
- If the media_data is too early in the session, when the
(new) media_entry is not yet in there, this could get
conflicts. Avoid those by not adding to session.
- Uses cascading to commit media_data together with the
media_entry.
.hex is what we need to access to get at the ascii (hex) version
anyway. Also, not sure why the previous version grabbed starting at
the index of 1... just grab the first characters instead.
Use inspect_table in the new migration. Makes code more
readable, really.
And make the default for the preferred license be None.
This is a userspace thing, so we can even change the
migration here. Changing the migration means, that people
running the migration before this commit get a "" in
User.license_preference, while people running the migration
now get a None. Both values are okay.
None has been designated as "Use the site's default". We're
not actually having a site default right now. Which means
no license is selected in the dropdown.
While "" means "All rights reserved" being chosen by the
user.
Side note: Having no license being selected in the submit
dropdown is as "worse" as before and does not really hurt
much. MediaEntry.license==None means "All rights reserved"
as does "" also do.
This feature is absolutely necessary. Now a user can simply define
their default license and quickly go through a form, as opposed to
stopping to click on the select and choosing the same option over
and over again.
Also added DB migration for the field, so that's working now, too.
Rebased by Sebastian and made the default value to be unicode.
Reviewed-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Merging an old branch, I reintroduced an import of db.sql.util rather than
db.util. Fixing the glitch.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
Set User.collections to her Collections using the backref feature.
This way we can iterate a user's collections and delete them all.
Delete all MediaEntries/Files/attachments/comments/collections etc
before finally deleting the User object. This is the backend work for
issue 302 (allow a user to delete ones own account)
Deleting a MediaEntry instance will automatically
delete all related comments and files/attachments. This moves
implementation logic out of views.py and allows to make use of this
functionality when e.g. deleting a User() account.
Whenever a MediaEntry entry is deleted, this will also sql-delete
the corresponding MediaFile entry.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
- made the mistake of copying some commit message things into the
docstring. Fixed.
- elrond points out that += is nicer and we don't need u"" in this
case since we're not concatenating a variable, we're concatenating
a known ascii string.
This one does not *force* slugs, but usually it will probably result
in a niceish one.
The end *result* of the algorithm will (presumably, I have not tested
it) result in these resolutions for these situations:
- If we have a slug, make sure it's clean and sanitized, and if it's
unique, we'll use that.
- If we have a title, slugify it, and if it's unique, we'll use that.
- If we can't get any sort of thing that looks like it'll be a useful
slug out of a title or an existing slug, bail, and don't set the
slug at all. Don't try to create something just because. Make
sure we have a reasonable basis for a slug first.
- If we have a reasonable basis for a slug (either based on existing
slug or slugified title) but it's not unique, first try appending
the entry's id, if that exists
- If that doesn't result in something unique, tack on some randomly
generated bits until it's unique. That'll be a little bit of junk,
but at least it has the *basis* of a nice slug!
