emencia / cmsplugin-blocks Goto Github PK

Describe the bug
When publishing a page, blocks plugins can lost their images sources.

To Reproduce
Steps to reproduce the behavior:

1. Create a two Card plugins in a page, both with images;
2. Publish the page;
3. Go back to page edition:
4. Edit only one of the Card plugin, change its images;
5. Publish the page again;
6. The card plugin which has not been edited has lost its image source;

Expected behavior
Image sources from plugin should never been removed if user does not have explicitly cleared them.

Desktop (If applicable):

• OS: Any
• Browser: Any
• Version: Any

Versions:

• Python: Any
• Django: Any
• DjangoCMS: Any

Additional context
This is related to the DjangoCMS way to manage published/draft version, published page use cloned plugin from draft and the previous ones are deleted, which trigger the post_delete signal. The receiver auto_purge_files_on_delete can not know about this cloning method and so legitimately remove files during deletion, even files are used in clones plugin in published page.

I've digged a little on this but DjangoCMS does not seems to pass any useful argument to receiver to know if file purge should be done or not. For true this would be possible but would require making additional queries to retrieved involved object and pages to determine if file is used or not, this seems bloated.

At this point, the only workaround is to remove receiver auto_purge_files_on_delete from all plugins.

Describe the bug
Card, Hero and Container plugins does not have the correct layout on input file as it could be expected from SmartMediaField usage.

It is related to this SmartMedia issue: sveetch/django-smart-media#12

To Reproduce

1. Create a plugin content with a Card, Hero or Container
2. The file input is working but not displayed as it should;
3. Save the plugin content and open it again for edition;
4. The file input is still not displayed as it should

Expected behavior
All input file managed with SmartMediaField should look like the preview from https://django-smart-media.readthedocs.io/en/latest/references.html#preview

Desktop (If applicable):

• OS: Any
• Browser: Any
• Version: Any

Versions:

• Python: Any supported
• Django: Any supported
• DjangoCMS: Any supported
• cmsplugin-blocks: 1.0.0

Additional context
There is two problems here:

1. Plugin form miss the definition of widget in their metaclass attribute widgets , SmartMedia probably can not resolve this since it is probably related to Django Admin/CMS plugin. We have to define this widget on plugin forms;
2. Once defined, the form field endorse SmartMedia widget render but it miss needed CSS+Js as it is reported in SmartMedia issue 12 (as given in introduction);
3. Once asset have been forced on the plugin form, there is a problem with the widget template that miss variable(s) to be able to display the preview;

Album and Slider are not subject to this since they work a little bit differently with their plugin form.

A container plugin with some options which will accept children plugins so it can be used as a block container.

For options, i would like to embrace features from Sveetoy blocks, maybe do it also for Sveetoy boxes.

It does not implement usage of any SlideItem link fields or Slide title.

When using the field to upload a ZIP to import image in an Album, an exception is raised:

'InMemoryUploadedFile' object has no attribute '_size
This is due to recent Django (>=2.0) where _size attribute is not available anymore on InMemoryUploadedFile and have been replaced with size.

Django does not remove image files related to model objetcs since a long time (1.2) and so we can have some orphan media files when their related object has been deleted, even more since we have mass upload feature.

Since plugins keep a hided previous version object (for published/unpublished state), we can't directly remove these files from delete object/form method, so the last way is to have a commandline to delete orphan media files that only remove files that does not belong into any model objects (published or not).

Is your feature request related to a problem? Please describe.
Some user have reported their need for the title to be possibly empty for Slider object.

Describe the solution you'd like
Problem here is that title main purpose was to have something to show a text for each plugin object in CMS plugin structure. Without this we either may have an empty plugin title or the plugin ID as its title, this is not really helpful, not to say this not ergonomic.

And if Slider would receive this change, it would be accurate to do the same for Album which is finally in the same concept.

Describe alternatives you've considered
We stand with required title, this is what i always thought as a good practice. The title is a minimal effort to do and have benefits even it is not used in front integration.

Additional context
Not really an expected feature for not, this is much more a user feedback note i needed to store.

In forms, separator between an object and its inline items is very poor.

This leads to mismatch between object contents and inline items contents when there are more than one inline item.

A very light background color like #f0f0f0 on each inline item would be a good start.

Project now collect many plugins and starts to be a little messy.

There is some improvements we can think about:

• New package structure with setup.cfg, proper makefile and correct environment;
• We need at least factories and basic tests on models, and maybe plugin checks;
• Use FileField instead of ImageField to enable SVG file support;
• Some plugin templates (at least Card) try to reach some field value like image.url without to check it's not an empty value;
• Drop any Python2 support if any (at least decorator for models);
• Research to improve plugin form layout and ergonomy, so we could add a little more field on components without making them too complicated;
• (cancelled) Organize each plugin in its own module, like Hero form, models, default and choices stored in a hero/ ? (I'm not sure about this org, what about admin/ or models/ that Django automatically lurking?)
• Better documentation (update, improve component descriptions, include component sketch images, publish on RTFD, etc..);
• Keep away to use helper default value in migrations when it's is None in model, Django assume this is a change, even the helper method return a None value. Else it trigger a new pending migration forever;

TextEditorWidget widget used in Hero, Card and SlideItem does not use the CKeditor config from djangocms-ckeditor.

Currently image from mass upload are only validated from PIL but:

• PIL can accept image type like bmp or other non web types;
• File extension is a good basic filter to avoid requesting PIL for validation (and so less memory usage);

This will be similar to Album (inline item, mass upload, structure, etc..) but with additional "content" field for Album and item.

So Album still be simple to use and Portfolio will exists for cases where item description is needed.

Describe the bug
This setting should not be used anymore since we ported the media file field stuff and validation to SmartMedia package.

To Reproduce
Not Available

Expected behavior
There is probably a few stale settings in defaults.py and documentation, this needs to be cleaned

Currently there is no limit on ZIP file upload from mass upload field, only the webserver can limit this with the appropriate option.

But big ZIP file involves big memory usage since image are processed in memory too until object has been saved.

Mass upload field should implement a file size limit (defined from settings) to ensure it does not make to much memory usage without to level down webserver request limit for other ressources.

To avoid conflict usage within project which include also easy-thumbnails:

jazzband/sorl-thumbnail#480

However it should be done once in the new to come template "smart format" as related in #11

Could you add a field "lien" in cards please ?
This field should be not required.

This is to resolve issue with added inline field that miss CKeditor initialize.

https://github.com/emencia/cmsplugin-blocks/blob/master/cmsplugin_blocks/templates/cmsplugin_blocks/album/default.html#L3

Describe the bug
When performing migrations for the first time, it fails on an exception caused by a change from Django 4.0 and since the requirements does not set any version rule for Django, it may install the 4.0 (if project does not already pin it).

To Reproduce
Steps to reproduce the behavior:

1. Clone repository
2. Execute "make install"
3. Fail with exception during migrations

Expected behavior
At least, a version rules should be "<4.0" or better we include support for Django 4.0 but it must not drop support for Django 3.x

Versions:

• Python: Any supported
• Django: >=4.0.0
• DjangoCMS: 3.9.0

To enforce a better nomenclature since in practice background field could be used as a simple image.

This background field exist in Slider and Hero components.

Is your feature request related to a problem? Please describe.
Current documentation is a bit short on details, it would need improvements.

Describe the solution you'd like

• Add an overview document to describe some mechanic;
• Expose almost everything with autodoc, not just the plugin classes;
• Add a field schema and a basic sample preview for each plugin to improve block understanding;
• Try to differentiate "plugin" and "block", block is a layout component, plugin is a part of component along some other things;

Describe alternatives you've considered
Current documentation structure is almost sufficient so it is not critical, but a better doc could help for understanding and adoption.

Is your feature request related to a problem? Please describe.
Version 1.0.0 has been released but due to some hurry, it missed some refinements.

Describe the solution you'd like

• Update PO;
• Remove usage of "os" module in profit of "pathlib";
• Fix plugin form layouts #20;
• Fix missing right widget from SmartMedia fields in some plugin forms (Hero, Card,
  Container) #20 ;