Django-cms installs, but pull-downs and other JS doesn't work - ideas for fixing?

Question

I've installed Django-CMS onto an existing site and while it isn't throwing errors, it isn't working. In particular, the header on a given page appears when I use "/?edit" but none of the pull down menus work, and very little (possibly none) of the JavaScript works.

Other facets:

• I've done this on a local install of Django with largely development components (for example, SQLite, and the server provided via the django tutorial)
• I've done this with the same result on an install on WebFactional using MySQL and an apache server
• The install is basically the process described here:

http://docs.django-cms.org/en/support-3.0.x/how_to/install.html

• The DB install worked w/out errors and the /admin site has a section for CMS
• The CMS check showed 1 test skipped, and all other tests passed.
• I'm using Django 1.6.5
• This isn't the only time I've had trouble getting django to deliver javascript in a way that executes properly on a project - I had problems with fairly simple drop down menus in the past that I never resolved.

Any ideas on what I could be doing wrong? My configuration changes could be seen here:

https://github.com/bethlakshmi/GBE2/compare/GBE-398

The Local Settings (recent edit)

DEBUG = True
TEMPLATE_DEBUG = False

ALLOWED_HOSTS = ['*domain of server*']
LOGIN_REDIRECT_URL = '/'

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': '*db name*',
        'USER': '*username*',
        'PASSWORD': '*password*',
        'HOST': '',
        'PORT': '',
    }

}

STATIC_ROOT = '*path to the static host in the file system*'
#STATIC_ROOT = '/'


EMAIL_HOST = '* email settings*'
EMAIL_HOST_USER = '*email settings*'
EMAIL_HOST_PASSWORD = '*email settings*'
DEFAULT_FROM_EMAIL = '*valid email*'
SERVER_EMAIL = '*valid email*'

• domain of server - the site is hosted on a subdomain: - prototypecms.gbeadmin.webfactional.com, the Allowed Host is "gbeadmin.webfactional.com"

• db name, username, password - the correct settings for the locally hosted database. The website itself works just fine with these database settings. I can log in with the same info using PHP Admin from the console. And when I look in the DB, I see the cms_* tables that came from django-cms during a syncdb.

• path to the static host in the file system - its a valid location in the server's file system. The CSS and JS are there and when I download the source page in the browser and look at /static links it references, I get the correct JS or CSS that I would expect from the server. The host recommends a particular separate area for static files and a particular configuration - which I've followed and gotten working successfully in the pre-django-cms application. If it wasn't working, I believe the CSS would not render correctly, and it works fine.

• email settings - are the email settings for the server. Right now they are not working and need to be tested and fixed, but I have a large amount of doubt that email settings could be a factor here.

• valid email the various email settings used by django in creating a mail. These are valid addresses relevant to the business.

Answer 1

After staring at this for about 1.5 weeks, I think I found the answer.

The eventual process to the solution was to get the tutorial up and running in the same environment and start slavishly comparing settings and templates. With a working tutorial, I could see what was there and slavishly imitate it.

The settings.py and local_settings.py was a rat hole - they worked just fine.

Eventual answer was that the pre-existing site and django-cms were contending over base.html and the block for "content" - there was a mapping for "/" in the base site urls and that meant that it didn't connect to a template, and it didn't have any content blocks. This really seemed to confuse Django-CMS site to the point where it would offer no pulldowns. Once I got base.html (now base.tmpl) to more closely imitate the tutorial, I was able to get the pull downs working.

The commit of the original solution was:

https://github.com/bethlakshmi/GBE2/commit/8286a9afd6e3ba8688dfefc4c9d888f5a2fd320f

And on the branch here:

https://github.com/bethlakshmi/GBE2/tree/GBE-398

There have been many more refinements.

The areas to look at would be gbe/base.tmpl, and also the landing and landing_page areas as the first thing that got executed was predictably the url resolution of "/" - so that was a particular blocker.

This is the leap forward I needed, but still a partial solution as there is a massive amount of integration yet to be done here.