django-blog-zinnia / cmsplugin-zinnia

Bridge between django-blog-zinnia and django-cms
BSD 3-Clause "New" or "Revised" License
53 stars 46 forks source link

CMSPlugins added to entries using Sekizai addtoblock fail to include CSS/JS #3

Closed zakpatterson closed 11 years ago

zakpatterson commented 11 years ago

Hello,

I am using the packaged EntryPlaceholder, and everything appears to work in the admin, however when sekizai's render_block is done, the CSS and JS in the plugin template are not included in the final rendering.

Steps to reproduce:

  1. Have a project with cmsplugin_zinnia and cms.plugins.googlemap and their dependencies
  2. Create a new entry
  3. Add GoogleMap to the entry's placeholderfield
  4. Save and view entry. Body of plugin template, including the div google map plugin will be in the source, however the JS to initialize the map will not appear at the bottom of the page, and the google maps api javascript will not be at the top.

I have attempted to write a new EntryPlaceholder, using cms.plugin_rendering.render_placeholder, but I am not sure how it would work as the HTTPRequest + context are not available to the EntryAbstractClass. I think there is a problem as html_content is supposed to return finished html, and all it is returning from that placeholder field is the div elements, etc. I think this is because the template is processed with the addtoblock calls as a new template (i.e. not within the context of a base.html or something like that which has render_block calls in the right places).

I will continue to work on it and try to find a solution, and perhaps I am doing something wrong. Thanks for zinnia and your projects.

Zak

aarcro commented 11 years ago

I have the same issue.

More than this issue. The rendered output of the plugin is storred in the content field in the database. I made changes to a template used by a plugin on the page, and the changes were not reflected.

jbazik commented 11 years ago

The patch from aarcro does not fix this problem for blogs within django-cms. Within the blog app, zinnia's own templates are used and they render entries directly from the stored content (which is the admin html representation of the plugins). I can work around this by overriding zinnia's entry_detail template and using captureas, but that's hardly the best solution. There are numerous templates in zinnia that access entry content.

zakpatterson's summary at the top identifies the real issue. Zinnia's Entry model's html_content property is the problem. Overriding it in EntryPlaceholder and calling django-cms' render_placeholder to produce the content would fix this issue everywhere.

I think the best way to fix this is to first change zinnia to replace html_content with a render method that takes a request and is not a property. Then it could be overridden in EntryPlaceholder.

One other thing. According to a django-cms issue (https://github.com/divio/django-cms/issues/1130), it seems to be an accident that the database representation of nested plugins is the admin html rendering. They used to be stored as templatetags. The issue is unresolved, but if they decide to fix it, cmsplugin-zinnia will break.