Make content editing in Django fancier
Project description
=======================================
Fancy CMS-style page editing for Django
=======================================
.. image:: https://travis-ci.org/tangentlabs/django-fancypages.png?branch=master
:target: https://travis-ci.org/tangentlabs/django-fancypages?branch=master
.. image:: https://coveralls.io/repos/tangentlabs/django-fancypages/badge.png?branch=master
:target: https://coveralls.io/r/tangentlabs/django-fancypages?branch=master
.. image:: https://requires.io/github/tangentlabs/django-fancypages/requirements.png?branch=master
:target: https://requires.io/github/tangentlabs/django-fancypages/requirements/?branch=master
:alt: Requirements Status
**Note:** This is a work in progress and part of this project will likely
change and could potentially break things. Be careful with using it.
Fancypages provides an easy way to edit content in your Django project.
Another content management system, you ask? No it is not! Rather, it is a
*content enhancement system* (CEnS) because it provides a user with the
controlled ability to edit content on a page.
The way this Django app works is inspired by `django-frontend-admin`_,
`django-content-blocks`_ and other similar apps. Especially, the use of
template tags to define customisable sections in a Django template is
based on the ideas in the two apps mentioned above.
**Warning:** There's currently an issue with *django-model-utils* 2.0+ and
Django 1.5.5. Until this is resolved, we advise to use **version 1.5** with
that specific version of Django.
.. _`django-frontend-admin`: https://github.com/bartTC/django-frontendadmin
.. _`django-content-blocks`: https://github.com/KevinBrolly/django-content-blocks
Oscar and Fancypages
--------------------
Fancypages has originally been developed to extend the functionality of
`django-oscar`_ by giving a the client limited control over content editing and
complement the Oscar dashboard. The need of other (non-Oscar) projects for a
similiar content editing funtionality lead to the separation of
`django-oscar-fancypages`_ into a separate app.
After several months of experience with maintaining both apps separately, we've
made the decision to maintain the Oscar integration as part of fancypages
available in ``fancypages.contrib.oscar_fancypages``. This should make it
easier to maintain both code bases and provide better integration for both.
**Note:** `django-oscar-fancypages`_ is now deprectated and will no longer
receive feature updates.
Screenshots
-----------
.. image:: https://raw.github.com/tangentlabs/django-fancypages/master/docs/source/images/screenshots/homepage_editor_hidden.png
.. image:: https://raw.github.com/tangentlabs/django-fancypages/master/docs/source/images/screenshots/homepage_editor_opened.png
.. image:: https://raw.github.com/tangentlabs/django-fancypages/master/docs/source/images/screenshots/homepage_edit_block_form.png
.. image:: https://raw.github.com/tangentlabs/django-fancypages/master/docs/source/images/screenshots/homepage_block_menu.png
Documentation
-------------
Installation instructions and documentation are hosted on the incredible
`readthedocs.org`_:
https://django-fancypages.readthedocs.org
.. _`readthedocs.org`: http://readthedocs.org
Projects Using Fancypages
-------------------------
* The Chocolate Box: https://www.chocolatebox.com.au
* Which Right Choice: https://www.whichrightchoice.com
* Freetix: https://www.freetix.com.au
* Agatha Christie: http://www.agathachristie.com
License
-------
``django-fancypages`` is released under the permissive `New BSD license`_.
.. _`New BSD license`: https://github.com/tangentlabs/django-fancypages/blob/master/LICENSE
.. image:: https://d2weczhvl823v0.cloudfront.net/tangentlabs/django-fancypages/trend.png
=========
Changelog
=========
0.3.1
-----
* Remove the ``target="_blank"`` attribute that used to be added by
``wysihtml5`` when sanitising link tags.
* Rename the ``advance.js`` config file for ``wysihtml5`` to
``wysihtml5-config.js``.
* Minify ``wysihtml5-config.js`` used for customising ``wyshtmls5`` to
reduce size.
* Fixes #25 (1): getting the child pages of a ``FancyPage`` used the
``PageNode``'s method ``get_children`` which would return a queryset
of ``PageNode`` instances. ``FancyPage`` now provides its own
``get_children`` method that returns the corresponding queryset of
``FancyPage`` instances.
* Fixes #25 (2): using the API to move pages in the hierarchy failed with
an internal server error caused by changes during refactoring. The calls
to the API are now using the UUID as expected instead of the model's PK.
0.3.0
-----
* Provide the actual object for a block in the ``rendered_block`` tuples to
allow more flexibility in the templates, especially in ``container.html``.
* Move the block selection modal markup from within the container into the
body of the page. This means we only need a single modal including all
available blocks. Also it avoids problems with displaying the modal.
* Switch the models for ``FancyPage`` and ``TreeNode`` to use Django's
swappable API and loosen the relationship between the two. previously, the
``FancyPage`` model was a subclass of both the ``AbstractFancyPage`` and the
``AbstractTreeNode`` which caused issues in *django-oscar-fancypages* when
integrating with the ``Category`` models. The use of the swappable API
simplifies the handling of this relationship and makes customising the tree
node used for the ``FancyPage`` easier.
This adds two settings ``FP_NODE_MODEL`` for the tree node model class that
will default to ``fancypages.PageNode`` and the ``FP_PAGE_MODEL`` which
defaults to ``fancypages.PageNode``.
* Interacting with blocks and containers has completely moved to the RESTful
API for blocks and containers. This makes the use of AJAX calls to create,
update and delete blocks more consistent. ``FancyPage`` models are still
edited through the dashboard and are currently not available via the REST
API.
* Fancypages provides a *Twitter* block that allows to specify a username and
pull the user's twitter feed. This requires the ``twitter-tag`` django app
which has caused issues before. This requirement has now been removed and
the *Twitter* block is now only available when the ``twitter-tag`` app is
installed. If it is not, the block won't be registered with fancypages and
won't be available to be added.
* UUIDs are now available on all models that are exposed via the REST API as
well as the ``FancyPage`` model. This makes sure that content blocks,
containers and pages are uniquely identifyable. This will support later
features such as versioning and import/export.
* Major improvements to the integration tests to run Selenium test using
saucelabs. It now covers a few fundamental use cases such as adding a new
content block, deleting a content block and changing the content of a text
block. The plan is to run these tests against various browser versions on
saucelabs to make sure that the UI is working consistently on the most common
browsers.
* Integrate `django-oscar-fancypages`_ as ``contrib`` package into fancypages.
The main reasons for this decision was to ease maintainability for both
projects and to avoid duplication between the two projects. The official
integration of fancypages with Oscar now lives in
``fancypages.contrib.oscar_fancypages`` and should be used instead of the
external package. As a result the configuration required to use fancypages
in a standalone or an Oscar project has changed and will need to be updated
when migrating from a previous installation. We have tried to provide full
backwards compatibility but there might be potential hickups in moving to
this version of fancypages. If you come across any issues or use cases that
we haven't anticipated, please open an issue on github.
* Containers in fancypages are now language aware by having a ``language_code``
attribute that is available on the model. The language code **has** to be
set and default to the ``LANGUAGE_CODE`` setting of your project. The main
principle for dealing with multi-language sites is to have a separate
container for each available language to allow total flexibility in setting
up content for different languages. This might seem like a lot of additional
work but there is a good reason for it. Different languages come with
different cutural habits and experiences, e.g. what people in Britain might
find hilarious might not work in the same way for people from Germany.
Therefore, the content addressed to users speaking different languages often
has to be adapted to work in the same or similar way. As a result we decided
to allow complete freedom in the way the "same" content is presented for
users speaking different languages. More details on this will be available in
the docs.
.. _`django-oscar-fancypages`: https://github.com/tangentlabs/django-oscar-fancypages
0.1.0
-----
The first public release.
Fancy CMS-style page editing for Django
=======================================
.. image:: https://travis-ci.org/tangentlabs/django-fancypages.png?branch=master
:target: https://travis-ci.org/tangentlabs/django-fancypages?branch=master
.. image:: https://coveralls.io/repos/tangentlabs/django-fancypages/badge.png?branch=master
:target: https://coveralls.io/r/tangentlabs/django-fancypages?branch=master
.. image:: https://requires.io/github/tangentlabs/django-fancypages/requirements.png?branch=master
:target: https://requires.io/github/tangentlabs/django-fancypages/requirements/?branch=master
:alt: Requirements Status
**Note:** This is a work in progress and part of this project will likely
change and could potentially break things. Be careful with using it.
Fancypages provides an easy way to edit content in your Django project.
Another content management system, you ask? No it is not! Rather, it is a
*content enhancement system* (CEnS) because it provides a user with the
controlled ability to edit content on a page.
The way this Django app works is inspired by `django-frontend-admin`_,
`django-content-blocks`_ and other similar apps. Especially, the use of
template tags to define customisable sections in a Django template is
based on the ideas in the two apps mentioned above.
**Warning:** There's currently an issue with *django-model-utils* 2.0+ and
Django 1.5.5. Until this is resolved, we advise to use **version 1.5** with
that specific version of Django.
.. _`django-frontend-admin`: https://github.com/bartTC/django-frontendadmin
.. _`django-content-blocks`: https://github.com/KevinBrolly/django-content-blocks
Oscar and Fancypages
--------------------
Fancypages has originally been developed to extend the functionality of
`django-oscar`_ by giving a the client limited control over content editing and
complement the Oscar dashboard. The need of other (non-Oscar) projects for a
similiar content editing funtionality lead to the separation of
`django-oscar-fancypages`_ into a separate app.
After several months of experience with maintaining both apps separately, we've
made the decision to maintain the Oscar integration as part of fancypages
available in ``fancypages.contrib.oscar_fancypages``. This should make it
easier to maintain both code bases and provide better integration for both.
**Note:** `django-oscar-fancypages`_ is now deprectated and will no longer
receive feature updates.
Screenshots
-----------
.. image:: https://raw.github.com/tangentlabs/django-fancypages/master/docs/source/images/screenshots/homepage_editor_hidden.png
.. image:: https://raw.github.com/tangentlabs/django-fancypages/master/docs/source/images/screenshots/homepage_editor_opened.png
.. image:: https://raw.github.com/tangentlabs/django-fancypages/master/docs/source/images/screenshots/homepage_edit_block_form.png
.. image:: https://raw.github.com/tangentlabs/django-fancypages/master/docs/source/images/screenshots/homepage_block_menu.png
Documentation
-------------
Installation instructions and documentation are hosted on the incredible
`readthedocs.org`_:
https://django-fancypages.readthedocs.org
.. _`readthedocs.org`: http://readthedocs.org
Projects Using Fancypages
-------------------------
* The Chocolate Box: https://www.chocolatebox.com.au
* Which Right Choice: https://www.whichrightchoice.com
* Freetix: https://www.freetix.com.au
* Agatha Christie: http://www.agathachristie.com
License
-------
``django-fancypages`` is released under the permissive `New BSD license`_.
.. _`New BSD license`: https://github.com/tangentlabs/django-fancypages/blob/master/LICENSE
.. image:: https://d2weczhvl823v0.cloudfront.net/tangentlabs/django-fancypages/trend.png
=========
Changelog
=========
0.3.1
-----
* Remove the ``target="_blank"`` attribute that used to be added by
``wysihtml5`` when sanitising link tags.
* Rename the ``advance.js`` config file for ``wysihtml5`` to
``wysihtml5-config.js``.
* Minify ``wysihtml5-config.js`` used for customising ``wyshtmls5`` to
reduce size.
* Fixes #25 (1): getting the child pages of a ``FancyPage`` used the
``PageNode``'s method ``get_children`` which would return a queryset
of ``PageNode`` instances. ``FancyPage`` now provides its own
``get_children`` method that returns the corresponding queryset of
``FancyPage`` instances.
* Fixes #25 (2): using the API to move pages in the hierarchy failed with
an internal server error caused by changes during refactoring. The calls
to the API are now using the UUID as expected instead of the model's PK.
0.3.0
-----
* Provide the actual object for a block in the ``rendered_block`` tuples to
allow more flexibility in the templates, especially in ``container.html``.
* Move the block selection modal markup from within the container into the
body of the page. This means we only need a single modal including all
available blocks. Also it avoids problems with displaying the modal.
* Switch the models for ``FancyPage`` and ``TreeNode`` to use Django's
swappable API and loosen the relationship between the two. previously, the
``FancyPage`` model was a subclass of both the ``AbstractFancyPage`` and the
``AbstractTreeNode`` which caused issues in *django-oscar-fancypages* when
integrating with the ``Category`` models. The use of the swappable API
simplifies the handling of this relationship and makes customising the tree
node used for the ``FancyPage`` easier.
This adds two settings ``FP_NODE_MODEL`` for the tree node model class that
will default to ``fancypages.PageNode`` and the ``FP_PAGE_MODEL`` which
defaults to ``fancypages.PageNode``.
* Interacting with blocks and containers has completely moved to the RESTful
API for blocks and containers. This makes the use of AJAX calls to create,
update and delete blocks more consistent. ``FancyPage`` models are still
edited through the dashboard and are currently not available via the REST
API.
* Fancypages provides a *Twitter* block that allows to specify a username and
pull the user's twitter feed. This requires the ``twitter-tag`` django app
which has caused issues before. This requirement has now been removed and
the *Twitter* block is now only available when the ``twitter-tag`` app is
installed. If it is not, the block won't be registered with fancypages and
won't be available to be added.
* UUIDs are now available on all models that are exposed via the REST API as
well as the ``FancyPage`` model. This makes sure that content blocks,
containers and pages are uniquely identifyable. This will support later
features such as versioning and import/export.
* Major improvements to the integration tests to run Selenium test using
saucelabs. It now covers a few fundamental use cases such as adding a new
content block, deleting a content block and changing the content of a text
block. The plan is to run these tests against various browser versions on
saucelabs to make sure that the UI is working consistently on the most common
browsers.
* Integrate `django-oscar-fancypages`_ as ``contrib`` package into fancypages.
The main reasons for this decision was to ease maintainability for both
projects and to avoid duplication between the two projects. The official
integration of fancypages with Oscar now lives in
``fancypages.contrib.oscar_fancypages`` and should be used instead of the
external package. As a result the configuration required to use fancypages
in a standalone or an Oscar project has changed and will need to be updated
when migrating from a previous installation. We have tried to provide full
backwards compatibility but there might be potential hickups in moving to
this version of fancypages. If you come across any issues or use cases that
we haven't anticipated, please open an issue on github.
* Containers in fancypages are now language aware by having a ``language_code``
attribute that is available on the model. The language code **has** to be
set and default to the ``LANGUAGE_CODE`` setting of your project. The main
principle for dealing with multi-language sites is to have a separate
container for each available language to allow total flexibility in setting
up content for different languages. This might seem like a lot of additional
work but there is a good reason for it. Different languages come with
different cutural habits and experiences, e.g. what people in Britain might
find hilarious might not work in the same way for people from Germany.
Therefore, the content addressed to users speaking different languages often
has to be adapted to work in the same or similar way. As a result we decided
to allow complete freedom in the way the "same" content is presented for
users speaking different languages. More details on this will be available in
the docs.
.. _`django-oscar-fancypages`: https://github.com/tangentlabs/django-oscar-fancypages
0.1.0
-----
The first public release.
