display:none for modal content in django cms 3

[sthzg]

I fully understand that no support might be given for a product that is in beta but still wanted to ask if someone has an idea. Using django suit on a django cms 3 installation two elements in the modal window that is opened when using the django cms structure view to insert/edit a plugin are hidden by display:none.

The first one is an <h2 />. This seems to be completely in the ballpark of the django cms-team, because their stylesheet cms.toolbar.modal.css features this selector

#content h2:first-child { display: none; }

Given the very semantic nature of a container with ID #content I think they should use a more restricted namespace for this.

The second one however I am not sure where it comes from. It is the <form /> tag that has display:none set as an inline style. This indicates an origin by some javascript. Do you have an idea where this could come from?

[sthzg]

Okay, I think I am getting a little bit closer. Due to different markup between the django admin and suit the django cms scripts can't find certain elements within the iframe that is displayed in the modal. That's why it can not finish its setup-tasks.

In case of the modal window the following script searches for the submit button with a selector like this:

var row = iframe.contents().find('.submit-row:eq(0)');
var buttons = row.find('input, a');

While .submit-row is still present in suit, the submit button is neither an input nor a link, but a <button type="submit" />element (bootstrap). I think that is the spot where things fall apart. I'll play around a little with the templates of suit and try to find an 'ugly' workaround until django cms 3 reaches stable and will be officially supported by suit.

[sthzg]

Not pretty but it works. I went about it in a few steps

1. Created a /proj/proj/templates/admin directory to modify some suit templates (see below)
2. Created a /proj/proj/static/cms/js/pluginsdirectory to overwrite the cms.modal.jsfrom django cms 3
3. Checked order in INSTALLED_APPS to make sure that my version of the cms.modal.js gets priority

The suit templates I had to copy over to the directory (step 1) were

• base.html
• delete_confirmation.html
• submit_line.html

base.html

This had to be modified in order to make the django cms modal window close after deleting a plugin. In cms.modal.js they analyze whether a certain flag is set and if there are messages on the screen. This behavior is hardcoded through a selector that doesn't match the bootstrap/suit markup. Thus the window doesn't close. To have a unique identifier for all message types I added a class message-item to the messages-div(s) (currently line 114). In order to reflect this I updated cms.modal.json line 485 to alternatively search for the new class

485: var messages = iframe.contents().find('.messagelist li, .message-item');

delete_confirmation.html

When deleting a plugin from the structure pane the content inside of the modal does not show due to an incompatibility between the django cms toolbar-css and the suit markup. That could be easily "fixed". Just put the <form action... /> tag down so that it sits right above the two <input />s (line 54)

submit_line.html

Again this is due to the fact that the django cms javascript explicitly searches for certain classes in order to strip out the buttons and attach them to the bottom of their modal (which structurally means ripping it out of the iframe into the parent frame). I had to add default to the class-attribute of the save button.

Since the javascript in cms.modal.js searches for <input />s or <a />s but suit uses <button />s the selector doesn't return an element and the necessary events are not bound. Due to that content is hidden when the plugin modal shows up (and hitting save dos not work, even when forcing the content to show through the developer tools css panel). To work around this I edited the cms.modal.js on line 398 to include the <button /> element in its query.

398: var buttons = row.find('button, input, a');

Again: this is nothing more than a messy workaround but maybe a starting point for better solutions or at least a short term workaround if the current state blocks parts of the development where plugins/suit are involved.

[dreipol]

In the version 3.0c1 the file cms.modal.js has changed slightly. The lines which have to be adjusted are:

508: var messages = iframe.contents().find('.messagelist li, .message-item');
423: var buttons = row.find('button, input, a');

[sthzg]

Just as a side note, I find the usage of the new Django CMS admin interface interesting. It uses a vertical split screen for many small tasks in admin. This split screen works in relatively small horizontal space (like suit does too with the inputs defaulted to a width of 220px) and stacks the otherwise columnized layouts. I think the same behavior could be achieved quite easily in suit once it changes to Bootstrap 3 and it might definitely worth picking this up. Due to many small issues (that need update-blocking tweaks like the above) I currently prefer the native Django CMS interface, but in all other application areas and in the backend I miss suits features and appearance very much.

[darklow]

Since Django CMS with v3 is starting to move away from default Django layout (they even have additional extended design theme), it get's harder and harder to maintain it. Very soon i will start moving Django Suit to BS3 (it won't be just changing classes, it will be redesign and new features and alternative layouts will be introduced). Therefore i am not sure i will support Django CMS in the future, they are just getting too big, and i will look for some other, simpler CMS apps to support. Supporting Django CMS from the beginning was an experiment and it took almost same amount of time to make support for CMS as to make whole Django Suit. I will consider supporting it in future, but i cannot promise anything. It also depends on direction Django CMS will go (See http://www.aldryn.com/en/ for example). And to be honest, i don't like the direction they are going...

[sthzg]

Thanks for the update on this issue. Looks like they are building a rather big stack around it. It's perfectly understandable that support might be dropped when maintenance eats up too much time (and I am sure there are enough ideas to push suit forward in its own place). I am quite new to both of them, but my feeling was that suit seemed like an accessible frontend for the backend opposed to Django CMS being a well made backend for the frontend. :-)

[Hedde]

@darklow you might want to consider feincms (https://github.com/feincms/feincms). It's an extremely stupid cms in terms of layout, but has most of the key features that django-cms supports and is very very modulair. I doubt it will ever move into the direction that Django-CMS has been going lately.

[darklow]

@Hedde yes, feincms would be first on the list as i see on app suggestion issue #3

[leesolway]

This would be very sad.. We use suit + django-cms on many projects, and was really looking forward to support for CMS3 :(.

[leesolway]

A little extra.. With the CMS moving most things to front end editing, wouldn't it be easier to maintain than the old CMS version?

[jab3z]

+1 suit + CMS 3

[jpotterm]

I recommend evaluating Fluent Pages as a replacement for Django CMS. It's simpler and sticks more closely to stock Django but it has a lot of the same features as Django CMS or FeinCMS.

[SalahAdDin]

use Wagtail, is good.