Can't move pages in admin. Throws an internal server error (500).

Traceback:
File "/var/www/blank/www/local/lib/python2.7/site-packages/django/core/handlers/base.py" in get_response
  132.                     response = wrapped_callback(request, *callback_args, **callback_kwargs)
File "/var/www/blank/www/local/lib/python2.7/site-packages/django/utils/decorators.py" in _wrapped_view
  110.                     response = view_func(request, *args, **kwargs)
File "/var/www/blank/www/local/lib/python2.7/site-packages/django/views/decorators/cache.py" in _wrapped_view_func
  57.         response = view_func(request, *args, **kwargs)
File "/var/www/blank/www/local/lib/python2.7/site-packages/django/contrib/admin/sites.py" in inner
  233.             return view(request, *args, **kwargs)
File "/var/www/blank/www/local/lib/python2.7/site-packages/django/utils/decorators.py" in _wrapper
  34.             return bound_func(*args, **kwargs)
File "/var/www/blank/www/local/lib/python2.7/site-packages/django/views/decorators/http.py" in inner
  45.             return func(request, *args, **kwargs)
File "/var/www/blank/www/local/lib/python2.7/site-packages/django/utils/decorators.py" in bound_func
  30.                 return func.__get__(self, type(self))(*args2, **kwargs2)
File "/var/www/blank/www/local/lib/python2.7/site-packages/django/utils/decorators.py" in inner
  145.                     return func(*args, **kwargs)
File "/var/www/blank/www/local/lib/python2.7/site-packages/cms/admin/pageadmin.py" in move_page
  857.         page.move_page(target, position)
File "/var/www/blank/www/local/lib/python2.7/site-packages/cms/models/pagemodel.py" in move_page
  217.         moved_page = self.move(target, pos=position)
File "/var/www/blank/www/local/lib/python2.7/site-packages/cms/models/pagemodel.py" in move
  1237.         super(Page, self).move(target, pos)
File "/var/www/blank/www/local/lib/python2.7/site-packages/treebeard/mp_tree.py" in move
  1037.         return MP_MoveHandler(self, target, pos).process()
File "/var/www/blank/www/local/lib/python2.7/site-packages/treebeard/mp_tree.py" in process
  444.         if self.target.is_descendant_of(self.node):

Exception Type: AttributeError at /admin/cms/page/250/move-page/
Exception Value: 'NoneType' object has no attribute 'is_descendant_of'

Django Version: 1.8.4 Affected versions: django-cms==3.1.1 and django-cms==3.1.4.dev

While Django 1.6 is still unreleased, we can try to see what's going to happen. Still a work in progress and only addresses python-level issues. All dependencies should be 1.6 ready now. ~~Biggest issues at the moment are django-reversion (PR opened for 1.6 support) and django-mptt support. djangocms-text-ckeditor (opened PR for support) and django-hvad looks more easy to fix. 1.6 support fixed in django-hvad.~~ ATM code is django 1.4 compatible. Django 1.6 added to build matrix to track the progress.

Bootstrap 3 introduced a navigation bar, where on mouse over, the sub/pulldown-menu does not automatically pop up. This brought to some controversial discussions on the Bootstrap mailing list, but considering the importance of touch devices (no mouse over possible), I agree with dropping support for this.

The menu system in django-cms is built in a way, which in practice requires the mouse over effect. The reason is, that one can not create a CMS "page", whose purpose is to only act as a node in the menu tree, without offering any page content.

For instance, consider the menu system of a typical site build with Bootstrap 3: https://www.angularjs.org/ . Here the main menu contains items: 'Learn', 'Develop', 'Discuss', which actually do not offer any page content. Now, assume one of the above items shall additionally offer some page content. This can be achieved by adding a copy of an item from the main menu, into its own pulldown menu. Here, the first click onto the main menu's item opens the pulldown menu. Then, a second click on the copy of that item, opens the requested page.

In django-CMS we could use the flag "in menu", but when this is turned off, then all menu items below that item are unselectable, and that's definitely not want we want.

My proposal is to add another magic template. Currently django-cms has a built-in magic template "Inherit from Parent". We could add another magic template, say "Empty Page", which then tells the menu system to act as a clickable menu item, but not offering any page content. Then, while building the menu, the template tag menu can distinguish a page acting as pure navigation node from a real cms page.

If this proposal is accepted, I can implement it.

EDIT (by ojii): Note, the title of this issue was changed by me.

I add little changes for may changing "?edit" variable (and "?edit_off", "?build") to custom variable (eq. "?admin_on") in project started with Django-CMS. I need it's for hidden login form on sites for "hackers" and make happy our customer (change variable to company name).

This pull request is related to #1798 and #1916.

I've updated the documentation, tests, and relevant parts of the code to support custom user models as long as the name of the model is User. In addition to a simple customuserapp.User model which adds a single field, I also included a emailuserapp.User which uses the email field as USERNAME_FIELD.

Lastly, I updated the test runner in develop.py to support a new command line arguement, --user, which allows for specifying the user model. By default, django.contrib.auth.User is used.

Tested with Django 1.4, 1.5, and 1.6.

Starting a project with Django 1.7 and DjangoCMS 3.0.6 will result in Django's makemigrations creating another migration file for the cms app. You can see the the created migration file here:

http://paste.awesom.eu/ZnyI

This gets annoying when creating custom plugins which then automatically depend on the locally created 0004 cms migration: It breaks deployment on a remote machine. My current fix is to manually edit the custom plugins' migration files to depend on the shipped 0003 cms migration.

I noticed that Django's migration system is more sensitive to changes than South, so could you please run makemigrations on all your cms apps (noticed a similar issue with djangocms_link) before the next release? Thanks!

I noticed that after upgrading from 3.0.10 to 3.0.12 that a CMSAttachMenu was not registering on a page. It would periodically appear and disappear. In the advanced settings sometimes I would see zero, one, or two options for the same menu. I only have one CMSAttachMenu menu defined in a single app in my project. I attempted to delete and recreate the page to no avail. I noticed in the database, if there was only one option available in advanced settings, the page record showed UserMenu for navigation_extenders. If there were two options, it would be UserMenu:190 or UserMenu:193 depending which option I selected.

Ultimately I reverted to 3.0.10 and the issue went away.

My menu class:

from menus.base import NavigationNode
from cms.menu_bases import CMSAttachMenu
from menus.menu_pool import menu_pool
from django.utils.translation import ugettext_lazy as _

class UserMenu(CMSAttachMenu):

    name = _('User Menu')

    def get_nodes(self, request):
        nodes = []

        menu_id = 1
        root_id = menu_id

        # root node
        greeting = 'Hello, {0}'.format(request.user.get_full_name() or request.user) if request.user.is_authenticated() else 'Log in'
        title = '<i class="fa fa-user hidden-xs hidden-md hidden-lg"></i><span class="hidden-sm">{0}</span>'
        n = NavigationNode(title.format(greeting), "/user/", menu_id)
        nodes.append(n)

        # anonymous menus
        menu_id += 1
        n = NavigationNode(_('Log in'), "/login/", menu_id, root_id, attr={'visible_for_authenticated':False})
        nodes.append(n)

        menu_id += 1
        n = NavigationNode(_('Register'), "/register/", menu_id, root_id, attr={'visible_for_authenticated':False})
        nodes.append(n)

        menu_id += 1
        n = NavigationNode(_('Help'), "/help/ticket/new/guest/", menu_id, root_id, attr={'visible_for_authenticated':False})
        nodes.append(n)

        # authenticated menus
        menu_id += 1
        dashboard_id = menu_id
        n = NavigationNode(_('Dashboard'), "/user/dashboard/", menu_id, root_id, attr={'visible_for_anonymous':False})
        nodes.append(n)

        menu_id += 1
        n = NavigationNode(_('Log out'), "/logout/", menu_id, root_id, attr={'visible_for_anonymous':False})
        nodes.append(n)

        # user section dashboard sub-menu
        menu_id += 1
        n = NavigationNode(_('Dashboard'), "/user/dashboard/", menu_id, dashboard_id, attr={'visible_for_anonymous':False})
        nodes.append(n)

        menu_id += 1
        n = NavigationNode(_('Projects'), "/user/projects/", menu_id, dashboard_id, attr={'visible_for_anonymous':False})
        nodes.append(n)

        menu_id += 1
        n = NavigationNode(_('Help Desk'), "/user/help/", menu_id, dashboard_id, attr={'visible_for_anonymous':False})
        nodes.append(n)

        menu_id += 1
        n = NavigationNode(_('Profile'), "/user/profile/", menu_id, dashboard_id, attr={'visible_for_anonymous':False})
        nodes.append(n)

        return nodes

menu_pool.register_menu(UserMenu)

This Pull Request proposes to remove develop.py (and it's related functions in cms.test_utils) with a file called manage.py that can be used like a manage.py file in a Django project.

While develop.py works fine, it is a lot of code that has nothing to do with the actual CMS to maintain and it only supports a few commands, new commands need to be added one-by-one. django-app-manage allows to externalize that problem. It's also a project that could be used by 3rd party cms plugins, making testing easier there (this obviously doesn't require this PR to be merged, all this would do is put some weight behind it).

develop.py also set up the magic --parallel and --isolated flags for the test command, but those flags resulted in odd output. For this, I wrote django-better-test which provides those two flags, but keeps the output nice and tidy.

django-better-test also is a lot smarter about distributing the load of the tests (by keeping track of how long each test method takes), has a --failed flag to only re-run failed tests, a --retest flag to re-use the last configuration and more exciting things!

TODO:

• [x] add manage.py
• [x] remove develop.py
• [x] remove old code from cms.test_utils

References

https://github.com/ojii/django-app-manage https://github.com/ojii/django-better-test

In django-CMS version 3.4, the method to determine if plugins are allowed as child and/or parent plugins, has changed a lot.

This is causing major problems in djangocms-cascade, since there I have to determine possible relationships dynamically. This means that depending on where inside the placeholder tree a plugin is located, possible parent and/or child relations can be allowed or denied.

Therefore I looked for alternatives and one proposal to fix it, would be to optionally pass in the current plugin instance to the classmethods CMSPlugin.get_child_classes(...) and CMSPlugin.get_parent_classes(...). Additionally I have to deactivate the placeholder caching for these plugins, since the list of allowed child- and parent-classes then has to be build dynamically.

This PR depends on #5799. If we can agree on it, I'll add some documentation and tests.

This would have many advantages:

• Faster compilation times, some say up to 11x faster.
• No need for Ruby gems and that stuff, everything is installable through pip.
• Files ending in .scss are referenced directly in the templates, rather than having to refer an autogenerated css-file.
• Only one file has to be revisioned in git: the scss-file. The css file is generated on the fly and kept in the compressors cache.
• No daemon, watching a subtree of the filesystem, must be started. The library django-compress and libsass will handle everything for us.

For more information refer to this post: https://groups.google.com/forum/#!topic/django-cms/KO7K1iMIjmo

This provides a Advanced Setting which allows you to specify a specific X-Frame-Option for a page. The options for X-Frame-Options are:

• Inherit from parent
• Allow
• Deny
• same origin (this website only)

The default is inherit from parents.

Description

The requirements to build the docs are fixed with pip-compile always pinning the installed django-cms version (presumably to the latest version when running pip-compile).

Issues

• When building docs the current version might not be published.
• When building docs for an update on an older version, say 3.10.2, the documentation is pulled from the latest version (which soon may be 4.x)

Solution

• Always install the current branch when building docs
• Since pip-compile always pins a pypi version for django CMS in requirements.txt the make-release command replaces whatever version is used there with the current branch at . (current folder)

Related resources

• #...
• #...

Checklist

• [x] I have opened this pull request against develop
• [x] I have added or modified the tests when changing logic
• [x] I have followed the conventional commits guidelines to add meaningful information into the changelog
• [x] I have read the contribution guidelines and I have joined #workgroup-pr-review on Slack to find a “pr review buddy” who is going to review my pull request. Pop

Bumps socket.io-parser to 4.2.1 and updates ancestor dependency karma. These dependencies need to be updated together.

Updates socket.io-parser from 2.3.1 to 4.2.1

Updates karma from 0.13.22 to 6.4.1

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps qs to 6.11.0 and updates ancestor dependency karma-sauce-launcher. These dependencies need to be updated together.

Updates qs from 2.4.2 to 6.11.0

Updates karma-sauce-launcher from 0.3.1 to 4.3.6

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Updated steps for installing and configuring sekizai

Description

Related resources

• #...
• #...

Checklist

• [x] I have opened this pull request against develop
• [x] I have added or modified the tests when changing logic
• [x] I have followed the conventional commits guidelines to add meaningful information into the changelog
• [x] I have read the contribution guidelines and I have joined #workgroup-pr-review on Slack to find a “pr review buddy” who is going to review my pull request.

Description

Work in progress on https://github.com/django-cms/django-cms/issues/7460.

Upgrading diffDOM seems to resolve the issue, however, is not compatible with UglifyJS.

Related resources

The issue seems to be related to variable naming in diffDOM:

I belive it is due to the variable called node:

https://github.com/fiduswriter/diffDOM/blob/v4.2.8/src/diffDOM/dom/fromVirtual.js#L2

Which UglifyJS does not like. I am seeking help with getting this fix across the finish line.

Checklist

• [x] I have opened this pull request against develop
• [x] I have read the contribution guidelines and I have joined #workgroup-pr-review on Slack to find a “pr review buddy” who is going to review my pull request.
• [ ] I have added or modified the tests when changing logic
• [ ] I have followed the conventional commits guidelines to add meaningful information into the changelog

Description

We are experiencing issues with the CMS refresh. For certail plugin configurations and post-plugin modification, the browser tab first freezes, later to crash due to out of memory error. We have confirmed the same on Google Chrome / Mozilla Firefox.

Steps to reproduce

1. Trigger content/structure board refresh
2. Tab crashes

Expected behaviour

The page content to update.

Actual behaviour

The diff between incoming document and actual document freezes up:

https://github.com/django-cms/django-cms/blob/develop/cms/static/cms/js/modules/cms.structureboard.js#L1291

Only tab restart fixes the issue.

Screenshots

Additional information (CMS/Python/Django versions)

Django CMS 3.11.0 or 1, Django 3.2.

Tested on Mozilla Firefox and Google Chrome

Do you want to help fix this issue?

We have looked into this further and the issue seems to be down to DiffDOM version 2.5.1. We have tried upgrading to the latest version 4.2.8, which works in debug mode, however, is not compatible with the current UglifyJS config.

• [x] Yes, I want to help fix this issue and I will join #workgroup-pr-review on Slack to confirm with the community that a PR is welcome.
• [ ] No, I only want to report the issue.