Page editing breaks on monolingual sites

[acdha]

The documentation says:

If your site is not multilingual you can leave out 'cms.middleware.MutilingualURLMiddleware'.

With the current master, if you actually do this the admin area will break when you attempt to update a page because cleaned_data won't have a key "language".

[digi604]

was this fixed in one of your commits?

[pcicman]

works for me without cms.middleware.MutilingualURLMiddleware

acdha, can you please provide more details? what is in your settings.py?

[acdha]

Grrr - GitHub dropped my first message about 2 hours ago. The good news is
that I've fixed another bug, too.

The first problem is simple. example/settings.py sets LANGUAGE_CODE='en-us'
(the Django default) and so I had that in my project, too. What I didn't
notice until I enabled cms.middleware.MultilingualURLMiddleware was that this
breaks things because en-us isn't in LANGUAGES - the example still works
because LANGUAGE is actually set a second time further down to "de", which is
in LANGUAGES. The solution for my demo was simple but it seems like the
"LANGUAGE_CODE in LANGUAGES" (and probably DEFAULT_LANGUAGE) checks should
happen somewhere in the core CMS so you always get an informative error rather
than silent failures.

To reproduce:

1. copy example
2. remove the LANGUAGE="de" and MultilingualURLMiddleware
3. edit a page in the admin

I found a second, nastier bug which I just fixed. On monolingual sites plugin
addition will appear to work but the content won't display on the page or the
next time you open the page in the admin area. This is really two bugs, both
of which are fixed in this commit:

http://github.com/acdha/django-cms-2.0/commit/cf78beea701e1a3a21f9b12b4f60052166f11b4b

The first is that the plugin editing view doesn't verify that the POST
variable "language" is in settings.LANGUAGES. I added a check to to
cms/admin/views.py for this.

The second was the reason I noticed the validation failure in the first place:
the add plugin JavaScript normally gets the language value from the language
selector, which doesn't exist if only one language is defined. This resulted
in entries in the cms_cmsplugin table with language="undefined".

I added a simple fallback which looks for the hidden language input if the
first check fails.

Chris

[pcicman]

great, now i can reproduce it, there were some fix for this one, i'm just not sure whats the state... @Stefan, can u check this?

[pcicman]

should work after yesterdays merge