sveetch / django-smart-media Goto Github PK

The SVG just does not display anymore since their tag does not define any size attribute and dont have any size in CSS, resulting in an image of 0x0 pixels.

This may not occurs with all SVG but not sure. However it sure indeed reproduced with generated images from demo, which use common options so this is to fix.

We need to enforce a specific size to ensure every image formats is correctly displayed.

As seen in #13 , signals are not always a proper way to purge stale files.

As a new workaround solution, a new command management could be added to analyze objects from database against stored media files to determine if there are stale files to remove or not.

The command won't be a magic thing that will crawl database itself to find stale files, there is just too many possibilities in applications to implement a fully working versions.

At least, we can add a command to launch "purge processors", where each purge processors is dedicated to a model and will know exactly how to work with model attribute and workflow.

A settings for this command would allow to define purge processors for a project. Despite called "purge processor" here, a processor would in fact retrieve used files that will be added to a global list filled from processors. At the end of processors collection, command would list all existing media files and remove all files that have not been collected by processors.

This is still a draft idea, it may need more research and study.

Proposal

A new setting which define shared sizes for thumb alike:

{
    "article-detail-cover": (320x240),
    "category-item-media": (300x200),
}

Template tags will have to recognize size name when given instead of explicite dimensions. Or at least a new tag dedicated to use named sizes.

Pros

It will promotes standardized sizes through templates and avoid to have 42 different sizes among all templates.

Also it will help to pre generate thumb and avoid Sorl retaining page loading until it finished to generate every thumb cache.

Cons

From previous experienced thumb libraries, i know some web designers dont like to change settings when trying to find a proper size, often leading to stale size setting.

There may be some other cons (or pros) but it would need some thought about implementation.

Even the references contains example, a more complete tutorial would be more helpful. At least a one for implementation with the model field. Another one for the widget, and maybe field could be nice too.

The Javascript code should be 100% vanilla Javascript.

This is almost already done except for the surrounding "on ready" function :

$(function($) {
    ...
});

Need to investigate situation, but purge signal only care about model files, however since we are using Sorl thumbnail, it creates some thumb cache but they are not explicitely removed so they may still remain, i don't know yet really how Sorl manage thumb cache.

Encountered issue with SmartMediaField usage on a DjangoCMS plugin form which define an additional css asset in Media.css meta class attribute.

It seems to override the asset definition previously done from widget ClearableFileInputButton and so the image file input is almost broken.

A proper workaround need to be found and documented.

It should be instead :

from smart_media.mixins import SmartFormatMixin

SmartModelAdmin can not work with admin class that are not registered to the admin since it inherits from base class Admin.

This results to error when using it with an inline class admin, this can be resolved with using directly SmartModelAdmin.formfield_overrides instead of admin class inheriting from SmartModelAdmin.

However it may be more useful to have something like a mixin or something else we can use in inline class.

Here we should link to Sorl documentation : https://sorl-thumbnail.readthedocs.io/en/latest/examples.html

This would be helpful in Django admin which stands on Bootstrap with CSS variables and enable the browser "dark mode".

Currently the stylesheet hardcode its own colors, it is safely usable in dark mode but always with a "light" look.

A proper solution have to be found to easily use the right stylesheet from widget implementation.

It has been proved at least the receiver auto_purge_files_on_delete connected on post_delete signal can be harmful when used with some very specific models.

This is especially the case with model from an application that may clone objects and delete original. As a example, there is a plugin from DjangoCMS, during publishing a page where a plugin has changed, the original plugin object from draft is cloned and original is removed.

The problem is that cloned object has copied the media paths but the original one is deleted so the auto_purge_files_on_delete delete its media since it don't know the media is still used from cloned object.

From implementation of auto_purge_files_on_delete it won't never been able to manage these specific case, developer should have to implement a new receiver which could manage it. But in the DjangoCMS plugin case, there is just not any argument passed to receiver that would allow to manage it well.

Signals should have a clear warning about these situation so developer could know about it possible problems before to add it into their applications.

Sorl and easy-thumbnail are the two main image resizing libraries.

The second one is very common with a DjangoCMS project, since it is implied in django-filer.

The first is more common every where else, but then it is common to see it as a requirement from a non CMS application into a DjangoCMS project.

However, the two share the same base name for their tag library but does not have the same tag argument syntax, it leads to
conflicts. Hopefully, the two ones have an alternative tag library name to use instead to avoid conflicts.

But finally, easy-thumbnail could be alternative resizer backend so it may help to do a full easy-thumbnail project.

Smart media will have to manage this and especially the different tag argument syntax.

Should be smart_image instead.

Or change the template tag to smart_media instead ? (seems more accurate)