I have now confirmed that this is wymeditor-specific -- TinyMCE works fine.

can you edit the plugin after you "moved" it with drag&drop?

curiously, yes. In fact I can edit it once, then get the error message when trying again, then drag and drop it to somewhere else and then it will work again (once). Dragging/dropping seems to fix the error, but editing again always brings it back.

this is soooooo a wymeditor bug. I hate wymeditor more and more

this will not be fixed in 2.0 as this is a wymeditor bug and really out of the scope of this project. if somebody will take a shot at it... go for it.. but I don't have time and the energy for this.

Yeah, I've switched to TinyMCE now too. Maybe that's the best way to make it go away :)

This might well be useful for this bug; https://developer.mozilla.org/En/Same_origin_policy_for_JavaScript

http://wiki.moxiecode.com/index.php/TinyMCE:Cross_domain_loading

what is you DB type?

mysql

MyIsam or InnoDB?

InnoDB utf8

Only MyIsam is working at the moment for migrations. Never had the time to make it work on InnoDB. postgres should be working as well

work around:

remove south from installed apps.
reset db
manage.py syncdb
add south to installed apps again
manage.py syncdb
manage.py migrate --fake

is this still the case with newest trunk?

ok i tryd to fix this... but either south has troubles with InnoDb or there is something else fundamentally flawed

could you try with RC3 and InnoDB... it should be working now

how is the support for sqllite in south nowadays? if you define a default value... does everything else run?

I first used sqlite with django-cms-2.0 and had no problems. but without using south.
because of the recent changes I had to use south/migrations. this seems not to work atm with sqlite :(
so this bug is maybe a south-issue, but why does all 14 migrations before work smoothly?
So since yesterday I'm using postgres to run my testsite with django-cms-2.0.

could you check with RC3 if this works with sqllite?

I can confirm that the problem is still there for sqlite with the rc3

I had (what looks to me), like a slightly different manifestation of this problem with the error:

sqlite3.IntegrityError: south_migrationhistory.id may not be NULL

I'm trusting that the person who marked my original as a dup is more in-the-know than I.

Is there a simple workaround that I could use for now? Or is the whole notion of using sqlite with south for local development really not a good idea at this juncture?

have a look here for a possible workaround: http://github.com/digi604/django-cms-2.0/issues/#issue/142

This can be easily fixed:

--- a/cms/migrations/0015_modified_by_added.py
+++ b/cms/migrations/0015_modified_by_added.py
@@ -112,8 +112,8 @@ class Migration:
     'user': ('models.ForeignKey', [], {'to': "orm['auth.User']", 'null': 'True', 'blank': 'True'})
     },
     'cms.publicpage': {
-            'changed_by': ('models.CharField', [], {'max_length': '70'}),
-            'created_by': ('models.CharField', [], {'max_length': '70'}),
+            'changed_by': ('models.CharField', [], {'max_length': '70', 'default': '""'}),
+            'created_by': ('models.CharField', [], {'max_length': '70', 'default': '""'}),
     'author': ('models.ForeignKey', [], {'to': "orm['auth.User']"}),
     'creation_date': ('models.DateTimeField', [], {'default': 'datetime.datetime(2009, 6, 30, 4, 55, 13, 502271)'
     'id': ('models.AutoField', [], {'primary_key': 'True', 'blank': 'True'}),

However this only gets you a little further down the path...

django version?
was the db migrated with south?

sorry, i forgot to mention:

• django trunk, rev: 11723
• django-cms trunk, commit: 3205b6d
• using example project
• south was not installed (uncommented from settings.py before syncdb)

django trunk is not supported at the moment. we will migrate to 1.2 as soon as a beta is out

This can be relatively simple from a backend perspective.

All that needs to happen to get things linking up correctly is making the Placeholder model link to any model. This could be done with contenttypes (slow) or it could be done by changing the object reference (page, currently an FK on Page) to a string and doing some simple serialisation.

So instead of storing a page pk (eg 3), it stores "Page:3".

This does mean that Placeholder wouldn't be easily able to look up the tree (ie access the Page object). I'm not sure if that's an issue but it would be anyway as if Placeholders are bound to non-page objects, they're not going to have Page-like footprints anyway. I would suggest making Placeholder completely independent.

The second and larger point to all of this is editing the Placeholders. There would need to be some interface. There could be an admin widget that gets thrown around but I think this would be a great opportunity to explore some on-page editing.

It would be relatively simple from there for non-CMS views to load the editing framework.

the problem we have at the moment is that we only can link to existing rows. So if you would use this in a blog for example. You would need to save the blog entry first before you can add plugins. This is very ugly on my point of view and I probably will do something like a generic foreign key and a custom edit-inline... something similar that feincms has but with our interface. Instead of placeholders we would make the whole thing a model.field or form.field.

You would need to save the blog entry first before you can add plugins

I don't see that as a major issue. The model I'm basic this on is Concrete5.
http://www.concrete5.org/

It's a PHP CMS that has a few things wrong with it (PHP for one) but its editing interface is pretty awesome (see the video on their homepage).

To create a page in that model, you have to create the page first and then you're presented with edit zones (placeholders if you will) that you can add "blocks" (plugins here) to. It works really well as an editing route.

I am not sure I understand fully. You're not talking about something like http://code.google.com/p/django-rosetta/ for example? Are you?

no.. just copy and paste for plugins... over languages

ah, I see, meanwhile I also read #67 and I do say that this certainly (#67) would be a great thing to have

I second this, having to save several times is confusing.

this is similar to #13. I would propose a cut / copy / paste.
The problem is: CMSPlugin only has a foreign-key to the page... and would need to be replaced with a m2m field. Or we could just introduce a new kind of plugin: Clone or Duplicate... that just refers to the original plugin. This way if the plugin gets deleted not all instances get deleted... or maybe this is desired?

Although it could make the admin page quite messy if implemented for all plugins, I like the way django-dbforms uses a model for settings up forms via admin, then from a page you add a form plugin and pick the content to add.
This could be applied to text etc, to allow a list of content to be assembled independent of the pages.

I am against doing that. There are certain places where this is very helpful, but most of the times it's probably a better choice to implement this in the plugin itself. Similar to what agentk suggested.

An example is the picture plugin. sure copying this would be useful and all, but why not just change it so that you get the option to upload a new image upon creating the plugin instance OR choose from an already uploaded one.

I think it's wiser to leave this part to the plugin itself. It makes more sense IMO, because on the plugin level, you have more flexibility. To go with the picture example: you might want to reuse the image that you already have on Page X but here you want a different caption, this is not easily possible with your proposed solution.

if, in case, you want a different caption, you go use GenericForeignKeys http://docs.djangoproject.com/en/dev/ref/contrib/contenttypes/#id1

This way you could have one image (read "the same") on the filesystem/database/whatever and different captions.

Imho it would be nice to have the opportunity to not have duplicates -- this is especially true for things like images, videos etc. as they eat up a lot of diskspace. Where and how exactly to put this kind of code ... hm ... plugin level sounds reasonable to me i.e. Clone (basically a link ie no duplication) and Duplicate sounds good to me.

generic foreign key will be implemented in 2.2.. they are already in new_admin branch

2 step wizard for page creation needed

use placeholder conf for this

I second this, it would be incredibly useful to be able to construct pages like this

define media like in widget or forms in plugin class that get included on the frontend site

I was wondering about fixing this, but I got some questions for you. Do you want the media to be "static" like in the admin, or returned from a function of the modeladmin that takes request or request and the plugin instance as arguments.

def get_media(self, request):

# or

def get_media(self, request, obj):

# or just a media property/class

class PluginMedia:
     js = ()
     css {}

# or a combination of the three

This also brings up the question of number of db_hits, should the query be a distinct just to get the plugin types or hould all plugins be loaded and cached for later use in the templatetag. This also depends a lot on if the media should be based on the plugin instance or not.

i think loading them beforehand and caching them is the only way. But we don't know yet if a plugin will be displayed as a placeholder may be inside an {% if %} or a plugin is assigned to a placeholder the the current template does not provide anymore. But i think this are edge cases and can be overlooked. request and instance as function parameter are good and should cover all possible cases. returning a Media Class is preferred.

made a branch for this in my repo, works with the example app so should be easy to try out, i want to add some docs, where should templatetags/plugin config be documented?

there is cms/docs/custom_plugins.txt i think.. or create a new .txt file.
Could merge with frontedit instead of master? New features: frontedit, bugfixes: master

i am not sure we should limit it to boolean fields

maybe a possibility to raise an exception and middleware that will handle it

Right now this does not work as expected, as raising an exception in a plugin raises a TemplateSyntaxError. So no way to do anything.

we could set a variable on the request and the middleware could look for if this variable is present.

This works, but still it would be more convenient if there was the possibility to return a HttpResponse in the plugin, as

1) it's cleaner and easier
2) Django doesn't have to process the entire response

Why do we have to return the context anyway, if we can modify the context directly?

The problem is that at the moment when the plugin is rendered we are not anymore in a view but already in render_to_response. This is needed for 3th party app support. We could check if the render function returns a HttpResponse.... and if it does wrap it like described above... would make the api simpler and more intuitive..

We also could assign the response to the request and then raise an exception... this would eliminate the render to the end problem.

What do you mean by: if we can modify the context directly?

I did not take a look at the django-cms code, but the context variable is passed to the render method, that's why we could just update it and not return it. That way, the return value of render() would be reserved for a HttpResponse. But I agree that we shouldn't change the behaviour, so a check isinstance(retval, HttpResponse) might be an option.

There's also HTML Diff from lxml, which, at least for the Text plugin, would probably be better understood by non-technical users.

http://codespeak.net/lxml/lxmlhtml.html#html-diff

Another possibility would be Aaron Swartz's HTMLDiff, which wouldn't introduce a dependency on lxml

http://www.aaronsw.com/2002/diff/

I agree. It is slightly confusing that the plugin closes.

hey vinilios.

read here http://github.com/digi604/django-cms-2.0/blob/e1e2dcd0cd0d981cd950d061a86505dafb6d5474/cms/docs/contribution.md on how to contribute so we would be able to have a look at it and integrate it into master branch

as a workaround, you could wrap the breadcrumb template tag in an {% if…%} tag to test if you are in the right template

I must check a var to use if tag.

But I don't know what var I can check. I'm using the same template because I need to integrate django-cms with other django content. I think it's a pretty standard need.

But It always shows the root page, which is not the root of my site (I have a blog in the home, I only need to say the home is another page).

I've used {% if current_page %} but it filters out the page that django-cms thinks the root. So it's not a workaround.

please read here: http://www.django-cms.org/en/documentation/2.0/contribution/

if you want this to be in RC2 push to github

I agree that there should be some sort of cascading portlet system. Even the "rule system" mentioned in the post would be a step in the right direction.

in frontedit branch we now have a inherit plugin... this takes the plugins of an other page and displays them... you can do template pages... and select those template pages then...

filebrowser integration is on the todo list... do you know if the filebrowser Fields extend now ImageField?

the problem is if the filebrowser fields do not extend ImageField or FileField the database signature changes ... but this may be handled with custom forms and hiding / showing the right field....

be sure to base your work on frontedit branch

it would make sense to use django-dbtemplates for this.

I am also interested in this. I tried to have a look at the code but I do not currently have the time to attempt and get this working well. I am however willing to donate $100 to anyone who is able to get this working well with grappelli (working well and fitting in with the rest of grappelli).

As an added note, I would accept it as either optional templates that i have to manually replace the default ones, or preferably integrated into django-cms with a setting (or better yet autodetection of django grappelli).

they normally use the __unicode__ function of the plugin model

do you mean in the admin?
Why you don't just overwrite the template for certain placeholders?

Yeap, in the admin. Well, it seemed a common use, as the link field gives you a hyperlink to the image to have a way to edit it's rel. Just the first line of the default template woulf have to change. Something like this works:

{% if link %}{% endif %}

I support this as well, all the link / picture items should have all the attributes available (but optional) like rel, class, etc.

I would support this if this fields are hidden in an advanced tab

Seems like a good deal to me ^^

just before someone goes ahead and implements it....
why don't you solve it over the template?

what do you mean? why don't we override the template for pictures? If so mostly because i don't want the rel="shadowbox" attribute on all of my pictures which is where i would use this at.

do you don't want it on pictures that are in the same or in different placeholders?

Depends on the image, often times i will have images in the same placeholder that i want some of them to have a rel attribute and other ones not too. I don't really see a reason not to allow this so i think i'll try to get this done over this weekend. It's really the only local patch i have left that i have to apply to a checkout.

because this feature is not backwards compatible to 1.1 we wait till 1.2 is out as a beta till we make the compatibility switch to 1.2. If you find a way on how to do this without breaking compatibility to 1.1 i gladly accept patches