Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Publishing pages from the tree hierarchy view has different behavior than publishing from the 'Change page' view #1555

kux opened this Issue · 4 comments

3 participants


Reproduced in django-cms 2.3.5

Steps to reproduce:

  1. In an empty site, create the first root page and publish it from the 'Change page' view by ticking the 'Is published' checkbox
  2. In an empty site, create the first root page and publish it by ticking the 'published' column in the page tree hierarchy view
  3. Notice that the value of 'path' in the 'cms_title' table:
    • is EMPTY for the page created at step 1
    • has the value of the slug for the page created at step 2

This difference of behavior has all sort of annoying side effects. The most annoying one is that it messes up CMS_REDIRECTS due to the fact all children of the home page might change their urls depending on the way you publish the home page


Workaround: it can be fixed opening home page change view and saving it (even after publishing); child pages' paths will be modified removing home page slug.
Did you tried on current develop?


I'm aware of the workaround.
However, I don't see the point of having the path rewriting magic at all.

I mean, since cms.utils.page_resolver.get_page_queryset_from_path does:

    home = pages.get_home()
except NoHomeFound:
    home = None
# if there is no path (slashes stripped) and we found a home, this is the
# home page.
if not path and home:
    page = home
    return page

The correct home page is returned for for an empty path even if the paths don't get re-written.

Also, not rewriting the paths ensures the fact that redirects will properly work even after you change the home page.


I've tried it on develop.
The publishing from the page tree hierarchy seems to be consistent with the one in the change page view.
Now they all change the path of pages under the home page.

However, mangling the paths has other ugly side effects.
Take the following scenario:

  1. in an empty site, create page foo
  2. create page bar
  3. publish page foo
  4. unpublish page foo
  5. publish page bar
  6. unpublish page bar => you will have two pages with conflicting EMPTY paths...
  7. create page with slug 'baz' as child of foo and publish it
  8. create page with slug 'baz' as child of bar and publish it => both pages created at steps 7 and 8 will have the same path
  9. Access

=> MultipleObjectsReturned at /baz/
get() returned more than one Page -- it returned 2! Lookup parameters were {}

Though I think should be opened as a separate bug. Apparently you can have two pages with the same slug... This looks like a regression.

@kux kux referenced this issue from a commit in kux/django-cms
@kux kux Fix for issue #1555 and #1620: Page path rewriting when published pag…
…e becomes the HOME page

* when CMS_MODERATOR = True:
  if the draft page is unpublished, the public version is also unpublished
* when determining the home page, ignore publication_date and publication_end_date
  this ensures that the home page path rewriting logic happens even if the page will only become available
     somewhere in the future
* change the post_save_page signal handler so that it also updates the:
  ** paths(titles) of the currently saved page
  ** if the currently saved page becomes the new home page, then update the paths(titles) of the previous home page
  ** if the currently saved page used to be the home page, then update the paths(titles) of the new home page
* add pre/post delete signal handlers that: if the currently deleted page was the home page
  then update the path of the new home page
* Added unit tests for all the above functionality

This ensures that:
* we will always have AT MOST one page with the '' (empty) path
* no matter what publishing method is used (tick the publish/unpublish checkbox in the page hierarchy,
    tick the 'is published' checkbox from the 'change page' view OR click 'publish' while doing frontend editing)
    the generated paths are consistent

seams to be fixed in #1555

@digi604 digi604 closed this
@kux kux referenced this issue in pbs/django-cms

Save home to force removal of first slug. #29

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.