emencia / cmsplugin-blocks Goto Github PK
View Code? Open in Web Editor NEWA set of DjangoCMS plugins for structured contents in CMS pages
Home Page: https://cmspluginblocks.readthedocs.io/
License: MIT License
A set of DjangoCMS plugins for structured contents in CMS pages
Home Page: https://cmspluginblocks.readthedocs.io/
License: MIT License
This is to resolve issue with added inline field that miss CKeditor initialize.
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
Currently image from mass upload are only validated from PIL but:
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.
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
.
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.
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.
Describe the bug
When publishing a page, blocks plugins can lost their images sources.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Image sources from plugin should never been removed if user does not have explicitly cleared them.
Desktop (If applicable):
Versions:
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.
Project now collect many plugins and starts to be a little messy.
There is some improvements we can think about:
hero/
? (I'm not sure about this org, what about admin/
or models/
that Django automatically lurking?)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
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.
Could you add a field "lien" in cards please ?
This field should be not required.
It does not implement usage of any SlideItem link fields or Slide title.
TextEditorWidget widget used in Hero, Card and SlideItem does not use the CKeditor config from djangocms-ckeditor.
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.
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).
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:
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:
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
To avoid conflict usage within project which include also easy-thumbnails:
However it should be done once in the new to come template "smart format" as related in #11
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
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):
Versions:
Additional context
There is two problems here:
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;Album and Slider are not subject to this since they work a little bit differently with their plugin form.
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.
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.