A free and open source content management system for publishing
content on the World Wide Web and intranets. It is based on Django
and written in Python.
NOTE: If this package has multiple flavors (see below), then use one of them instead of the name specified above. NOTE: This is a Python port. Instead of py312-django-cms listed in the above command, you can pick from the names under the Packages section.
===> The following configuration options are available for py312-django-cms-5.1.3:
====> Options available for the multi DATABASE: you have to choose at least one of them
MYSQL=off: MySQL database support
PGSQL=off: PostgreSQL database support
SQLITE=on: SQLite database support
===> Use 'make config' to modify these settings
IMPORTANT /
If you're upgrading from a older version of py-django-cms please read the
upgrade instructions at:
http://docs.django-cms.org/en/latest/upgrade/index.html
The described steps further down are a distilled version of "How to install
django CMS by hand" which is available at:
http://docs.django-cms.org/en/latest/how_to/install.html
The manual gives enough information how to setup py-django-cms for
development use. For production environments please consider to read the
full documentation available at:
http://docs.django-cms.org/en/latest/index.html
1. Create a new Django project
$ django-admin.py startproject myproject
2. Edit settings.py
--- Set a SITE_ID by adding the following line:
SITE_ID = 1 # 1 will suffice in most cases
--- Add the next lines to INSTALLED_APPS:
'djangocms_admin_style' # must come BEFORE django.contrib.admin
'django.contrib.sites'
'cms'
'menus'
'sekizai'
'treebeard'
--- Configure the LANGUAGES and LANGUAGE_CODE, e.g.:
LANGUAGES = [
('en', 'English'),
('de', 'German'),
]
LANGUAGE_CODE = 'en' # For simplicity's sake at this stage it is worth
# changing the default en-us in that you'll find in
# the LANGUAGE_CODE setting to en.
--- Add the following lines to MIDDLEWARE_CLASSES:
'cms.middleware.utils.ApphookReloadMiddleware' # Optional, but useful
'cms.middleware.user.CurrentUserMiddleware'
'cms.middleware.page.CurrentPageMiddleware'
'cms.middleware.toolbar.ToolbarMiddleware'
'cms.middleware.language.LanguageCookieMiddleware'
'django.middleware.locale.LocaleMiddleware'
--- Add MEDIA_URL (where media files will be served) and MEDIA_ROOT (where they
--- will be stored):
MEDIA_URL = "/media/"
MEDIA_ROOT = os.path.join(BASE_DIR, "media")
--- See the Django documentation for guidance on serving media files in
--- production.
--- Add a CMS_TEMPLATES section that will be the project's default template:
CMS_TEMPLATES = [
('home.html', 'Home page template'),
]
--- Add the next lines to TEMPLATES['OPTIONS']['context_processors']:
'sekizai.context_processors.sekizai'
'cms.context_processors.cms_settings'
--- Django needs to be know where to look for its templates, so add following
--- line (the appropriate directory will be created in the next step) to the
----TEMPLATES['DIRS'] list:
['templates']
--- In the root of the project, create a templates directory, and in that,
--- home.html, a minimal django CMS template:
{% load cms_tags sekizai_tags %}
<html>
<head>
<title>{% page_attribute "page_title" %}</title>
{% render_block "css" %}
</head>
<body>
{% cms_toolbar %}
{% placeholder "content" %}
{% render_block "js" %}
</body>
</html>
--- Note: See Django's template language documentation for more on how template
--- inheritance works.
3. Edit urls.py
--- Edit urls.py and add url(r'^', include('cms.urls')) to the urlpatterns
--- list. It should come after other patterns, so that specific URLs for other
--- applications can be detected first.
--- You'll also need to have an import for django.conf.urls.include and
--- configure a media file serving for development purposes:
from django.conf import settings
from django.conf.urls import url, include
from django.conf.urls.static import static
urlpatterns = [
url(r'^admin/', admin.site.urls),
url(r'^', include('cms.urls')),
] + static(settings.MEDIA_URL, document_root=settings.MEDIA_ROOT)
4. Setup the relational database backend
--- For testing purpose SQLite can be used and it is configured by default
--- in a new Django project's DATABASES.
--- Refer to Django's DATABASES setting documentation for the appropriate
--- configuration when PostgreSQL or MySQL are used as database backends.
5. Run migrations to create database tables
--- When a database backend has been choosen and set up properly, run the
--- following command:
$ python manage.py migrate
6. Create an admin superuser
--- For maintenance purposes it is necessary to create a admin user:
$ python manage.py createsuperuser
7. Check CMS installation
--- This will check your configuration, your applications, your database and
--- report on any problems:
$ python manage.py cms check
--- When there are no errors continue with the last step.
8. Start the CMS
--- The django CMS project will now run by issuing:
$ python manage.py runserver
--- The CMS can now be reached http://localhost:8000/ and the admin interface
--- at http://localhost:8000/admin/
*: Switch consumers over to Django 5.2
Django 4.2 reached its End-of-Life on 7th April 2026 and Django 5.2 is
the new LTS (= Long Term Support) release which will be supported until
April 2028.
* Switch most ports that use www/py-django42 to www/py-django52.
* Where necessary, remove PORTSCOUT, which is no longer needed because
an update to a newer version that no longer supports Django 4.2 should
now be possible.
* Bump PORTREVISION due dependency change where necessary.
PR: 291707
Reviewed by: sunpoet (python)
Differential Revision: https://reviews.freebsd.org/D56966
python: bump all USE_PYTHON=distutils consumers after RUN_DEPENDS removal
Any missed ports, feel free to bump.
Any ports that need setuptools at runtime can have the devel/py-setuptools
manually added back to RUN_DEPENDS, but understand that this practice
is deprecated; see CHANGES for details.
*: Switch consumers over to Django 4.2
Django 3.2 reached its End-of-Life on 1st April 2024 and Django 4.2 is
the new LTS (= Long Term Support) release which will be supported until
April 2026.
* Switch most ports that use www/py-django32 to www/py-django42.
* Ports that are not compatible with Django 3.2 have already been set
with an expiration date were not taken into account.
* Bump PORTREVISION due dependency change where necessary.
PR: 276319
Reviewed by: dvl, grembo, ultima
Approved by: bofh (implicit), dvl, grembo, Kevin Golding, sunpoet,
ultima, maintainer timeout (remaining maintainers)
Differential Revision: https://reviews.freebsd.org/D44637
all: remove explicit versions in USES=python for "3.x+"
The logic in USES=python will automatically convert this to 3.8+ by
itself.
Adjust two ports that only had Python 3.7 mentioned but build fine
on Python 3.8 too.
finance/quickfix: mark BROKEN with PYTHON
libtool: compile: c++ -DHAVE_CONFIG_H -I. -I../.. -I -I. -I.. -I../.. -I../C++
-DLIBICONV_PLUG -DPYTHON_MAJOR_VERSION=3 -Wno-unused-variable
-Wno-maybe-uninitialized -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong
-fno-strict-aliasing -DLIBICONV_PLUG -Wall -ansi
-Wno-unused-command-line-argument -Wpointer-arith -Wwrite-strings
-Wno-overloaded-virtual -Wno-deprecated-declarations -Wno-deprecated -std=c++0x
-MT _quickfix_la-QuickfixPython.lo -MD -MP -MF
.deps/_quickfix_la-QuickfixPython.Tpo -c QuickfixPython.cpp -fPIC -DPIC -o
.libs/_quickfix_la-QuickfixPython.o
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean
'-Wno-uninitialized'? [-Wunknown-warning-option]
QuickfixPython.cpp:175:11: fatal error: 'Python.h' file not found
^~~~~~~~~~
1 warning and 1 error generated.
Reviewed by: portmgr, vishwin, yuri
Differential Revision: <https://reviews.freebsd.org/D40568>
Remove WWW entries moved into port Makefiles
Commit b7f05445c00f has added WWW entries to port Makefiles based on
WWW: lines in pkg-descr files.
This commit removes the WWW: lines of moved-over URLs from these
pkg-descr files.
Approved by: portmgr (tcberner)
Add WWW entries to port Makefiles
It has been common practice to have one or more URLs at the end of the
ports' pkg-descr files, one per line and prefixed with "WWW:". These
URLs should point at a project website or other relevant resources.
Access to these URLs required processing of the pkg-descr files, and
they have often become stale over time. If more than one such URL was
present in a pkg-descr file, only the first one was tarnsfered into
the port INDEX, but for many ports only the last line did contain the
port specific URL to further information.
There have been several proposals to make a project URL available as
a macro in the ports' Makefiles, over time.
(Only the first 15 lines of the commit message are shown above )
www: remove 'Created by' lines
A big Thank You to the original contributors of these ports:
*
* <hvo.pm@xs4all.nl>
* Aaron Dalton <aaron@FreeBSD.org>
* Aaron Dalton <aaron@daltons.ca>
* Aaron LI <aly@aaronly.me>
* Aaron Zauner <az_mail@gmx.at>
* Abel Chow <achow@transoft.net>
* Adam Weinberger <adamw@FreeBSD.org>
* Ade Lovett <ade@FreeBSD.org>
* Adrian Steinmann <ast@marabu.ch>
* Akinori MUSHA aka knu <knu@idaemons.org>
(Only the first 15 lines of the commit message are shown above )
www/py-django32: Switch consumers over to Django 3.2
Django 2.2 became End-of-Life on 11th April 2022 and Django 3.2 is the
new LTS (= Long Term Support) release which will be supported until
April 2024.
* Switch the most ports that use www/py-django22 to www/py-django32
* Switch www/seahub over to www/py-djangorestframework
* Ports that are not yet ready for Django 3.2 (only three so far) or
those that have already been set with an expiration date were not
taken into account.
* Bump PORTREVISION due dependency change where necessary.
PR: 261313
Reviewed by: bofh, dvl, koobs, ultima
Approved by: bofh, dvl, koobs, ultima, sunpoet, Kevin Golding, Ivan Rozhuk,
Alexander Sieg (maintainers)
maintainer timeout (remaining maintainers)
Differential Revision: https://reviews.freebsd.org/D34859
www/py-django-cms: Update to 3.7.1
* Also assign the port to Django 2.2 because Django 1.11 is End-of-Life
since April. [1]
* Do the same for its dependencies (including www/py-django-classy-tags [2])
and bump PORTREVISION accordingly.
Changelog:
https://github.com/divio/django-cms/blob/3.7.1/CHANGELOG.rst
PR: 245361 [1] 245360 [2]
Approved by: maintainer timeout (14 days) [1] [2]
Convert Python ports to FLAVORS.
Ports using USE_PYTHON=distutils are now flavored. They will
automatically get flavors (py27, py34, py35, py36) depending on what
versions they support.
There is also a USE_PYTHON=flavors for ports that do not use distutils
but need FLAVORS to be set. A USE_PYTHON=noflavors can be set if
using distutils but flavors are not wanted.
A new USE_PYTHON=optsuffix that will add PYTHON_PKGNAMESUFFIX has been
added to cope with Python ports that did not have the Python
PKGNAMEPREFIX but are flavored.
USES=python now also exports a PY_FLAVOR variable that contains the
(Only the first 15 lines of the commit message are shown above )
Remove UNIQUENAME and LATEST_LINK.
UNIQUENAME was never unique, it was only used by USE_LDCONFIG and now,
we won't have conflicts there.
Use PKGBASE instead of LATEST_LINK in PKGLATESTFILE, the *only* consumer
is pkg-devel, and it works just fine without LATEST_LINK as pkg-devel
has the correct PKGNAME anyway.
Now that UNIQUENAME is gone, OPTIONSFILE is too. (it's been called
OPTIONS_FILE now.)
Reviewed by: antoine, bapt
Exp-run by: antoine
Sponsored by: Absolight
Differential Revision: https://reviews.freebsd.org/D3336
- let user to change database backend via options (default is sqlite)
- bump PORTREVISION
- trim Makefile header while here
PR: 169248
Submitted by: Matthew X. Economou <xenophon+freebsd at irtnog dot org>
(maintainer)
Feature safe: yes
- update to version 2.3
- update dependency upon www/py-django-sekizai (at least 0.6.1 is needed)
- fix directories at pkg-message
- use @dirrm (not @dirrmtry) for the port's own directories
- don't try to use @dirrmtry to other ports directories
while here:
- use CHEESESHOP shortcut
- remove unnecessary MASTER_SITE_SUBDIR
- strict python version to 2.x only
PR: 169599
Submitted by: bsam
Approved by: maintainer timeout (6 weeks)
A free and open source content management system for publishing
content on the World Wide Web and intranets. It is based on Django
and written in Python.
WWW: http://django-cms.org/
PR: ports/164624
Submitted by: Matthew X. Economou <xenophon+fbsdports@irtnog.org>