tangentlabs / django-fancypages Goto Github PK

There's quite a few use cases for blocks that link through to a handpicked list of objects such as images or products. Currently these are either hard-coded or defined using some add_to_class magic.

This could be wrapped up in a nice metaclass that can be used for these types of blocks providing a few helpful convenience functions on the model as well.

Ideally, the block definition would look something like this and the magic happens in it's metaclass:

class ImageListBlock(ContentBlock):
    related_objects = {
        'images': {'num': 8, 'field_name': 'image_{0}'}
    }

This will create 8 foreign keys with field names image_1, image_2, etc. and provides a property images on the model that return the related models as list.

Currently each widget that requires a form that is different from the auto-generated ModelForm has to implement its on form. This is a bit cumbersome when creating new widgets. Each widget should provide a simple method that provide custom settings for form field that are then used by a form creator to generate the corresponding from derived from WidgetForm.

Optional redirect for a page when not visible or 404 (moved URL):

• specify redirect type
• specify destination URL
• how to catch 404 for fancypage ? (research)

Hey,

the PageDeleteView does not have set the context_object_name to page but the template page_delete.html uses page as the context variable. This raises an Exception in rendering the breadcrumbs in the delete page because page.pk is referenced but there is no page object in the context.
Quick fix would be to set the context_object_name in the PageDeleteView.

Also not all dashboard views do have context_object_name set. Is this on purpose? Would you rather use context_object_name or stay with default django behaviour (object and object_list).

What do you think @elbaschid ?. I can come up with a PR.

Also in the delete template there are properties used that the default FancyPage model doesn't have - like title.

The asset manager currently available in fancypages is very rudimentary and has a lot of limitations, e.g. it uses an iframe to display the upload interface. The underlying model structure of the asset manager need to be reviewed and the front-end integrated with Backbone/Marionette.

• Review the model structure used in fancypages.assets.models
• Replace the asset manager iframe with appropriate Marionette views.
• Review if additional file types for attachments are required.

The sitemap template tags, line 42 is:

return FancyPage.objects.visible_in(visibility_type_instance)

The PageManager used here no longer has a visible_in method.

The new backbone implementation handles the loading of the image asset manager in a model which uses an iframe to display the uploader. The WYSIWYG editor in the editor panel also relies on an iframe.

When selecting the image asset manager to upload/select an image, the asset manager iframe is correctly displayed in the modal but all other iframes on the page also display the asset manager.

The problem seems to be that not just the modal iframe's src attribute is updated but the src of all iframes.

I've come across a very neat way of providing default settings in an app by wrapping the Django settings in a LazySettings object that applies the django.conf.settings on top of the default values. It's used in sorl-thumbnail might be worth looking into to avoid the from fancypages.defaults import * we currently have to do in the settings.

Updating one of your projects to use Django 1.7 RC2 broke fancypages when trying to retrieve the edit form for a page. The corresponding stacktrace is:

Traceback (most recent call last):
  File "/home/elbaschid/.virtualenvs/dimeo/local/lib/python2.7/site-packages/django/core/handlers/base.py", line 111, in get_response
    response = wrapped_callback(request, *callback_args, **callback_kwargs)
  File "/home/elbaschid/.virtualenvs/dimeo/local/lib/python2.7/site-packages/django/views/generic/base.py", line 69, in view
    return self.dispatch(request, *args, **kwargs)
  File "/home/elbaschid/.virtualenvs/dimeo/local/lib/python2.7/site-packages/django/views/decorators/csrf.py", line 57, in wrapped_view
    return view_func(*args, **kwargs)
  File "/home/elbaschid/.virtualenvs/dimeo/local/lib/python2.7/site-packages/rest_framework/views.py", line 400, in dispatch
    response = self.handle_exception(exc)
  File "/home/elbaschid/.virtualenvs/dimeo/local/lib/python2.7/site-packages/rest_framework/views.py", line 397, in dispatch
    response = handler(request, *args, **kwargs)
  File "/home/elbaschid/.virtualenvs/dimeo/local/lib/python2.7/site-packages/rest_framework/generics.py", line 434, in get
    return self.retrieve(request, *args, **kwargs)
  File "/home/elbaschid/.virtualenvs/dimeo/local/lib/python2.7/site-packages/rest_framework/mixins.py", line 108, in retrieve
    return Response(serializer.data)
  File "/home/elbaschid/.virtualenvs/dimeo/local/lib/python2.7/site-packages/rest_framework/serializers.py", line 575, in data
    self._data = self.to_native(obj)
  File "/home/elbaschid/.virtualenvs/dimeo/local/lib/python2.7/site-packages/rest_framework/serializers.py", line 351, in to_native
    value = field.field_to_native(obj, field_name)
  File "/home/elbaschid/.virtualenvs/dimeo/local/lib/python2.7/site-packages/rest_framework/fields.py", line 1035, in field_to_native
    value = getattr(self.parent, self.method_name)(obj)
  File "/home/elbaschid/.virtualenvs/dimeo/src/django-fancypages/fancypages/api/serialisers.py", line 78, in get_model_form
    form = self.get_form_class(obj)(instance=obj)
  File "/home/elbaschid/.virtualenvs/dimeo/src/django-fancypages/fancypages/api/serialisers.py", line 75, in get_form_class
    return modelform_factory(model, form=form_class)
  File "/home/elbaschid/.virtualenvs/dimeo/local/lib/python2.7/site-packages/django/forms/models.py", line 541, in modelform_factory
    return type(form)(class_name, (form,), form_class_attrs)
  File "/home/elbaschid/.virtualenvs/dimeo/local/lib/python2.7/site-packages/django/forms/models.py", line 284, in __new__
    opts.help_texts, opts.error_messages)
  File "/home/elbaschid/.virtualenvs/dimeo/local/lib/python2.7/site-packages/django/forms/models.py", line 210, in fields_for_model
    formfield = f.formfield(**kwargs)
  File "/home/elbaschid/.virtualenvs/dimeo/local/lib/python2.7/site-packages/django/db/models/fields/__init__.py", line 1063, in formfield
    return super(CharField, self).formfield(**defaults)
  File "/home/elbaschid/.virtualenvs/dimeo/local/lib/python2.7/site-packages/django/db/models/fields/__init__.py", line 822, in formfield
    defaults['choices'] = self.get_choices(include_blank=include_blank)
  File "/home/elbaschid/.virtualenvs/dimeo/local/lib/python2.7/site-packages/django/db/models/fields/__init__.py", line 733, in get_choices
    named_groups = self.choices and isinstance(self.choices[0][1], (list, tuple))
TypeError: 'itertools.tee' object has no attribute '__getitem__'

There've most likely been changes to the Django internals that break an assumption made in fancypages. I've got to investigate the issue for this.

Blocks in FP make use of multi-table inheritance for blocks. This can cause orphaned entries in the ContentBlock table when e.g. reverting migrations. It would be nice to have management command that looks for orphaned ContentBlock rows and removes them. Similar to the unreferenced_files in django-extensions.

Django 1.7 is about to be released and with the great work in migrations. To support the changes introduced with migrations and the new app configuration, fancypages needs some work to be ready for Django 1.7 in a backward-compatible way.

• Move "old" South migrations into a new directory and configure SOUTH_MIGRATION_MODULES accordingly
• Create a new migrations directory for Django 1.7 migrations.
• Put migration tests in place that ensure migrations work for both
• Add app config modules to fancypages and fancypages.contrib.oscar_fancypages

When adding a link, we should allow the users control on whether the link is to open in a new window or not.

The sitemap tags library is still relying on Oscar's categories rather than the FancyPage model. There's no test coverage for this which is why it's not been found earlier. So this need proper test coverage and fixing 😄

Currently, blocks are not available in the Django admin and have to be registered separately. Since all blocks are subclasses of ContentBlock it's simple enough to register all subclasses that are concrete models.

When responses with streaming_content are passed through the middleware, an exception is raised when checking for 'editable-container' in the content body.

The middleware needs to ignore streaming response objects.

A simplified version of handling forms for content blocks, especially with customisation has been added to release/0.3 specifically for a project that relies on this branch and can't be ported to master (for the time being).

The implemented changes in 0110206 should be ported back into master together with some proper documentation.

Several templates that are specific to the Oscar integration in fancypages.contrib.oscar_fancypages are broken. They need to be fixed and some the static files checked for correct paths.

Branch: refactoring

Looking at some dashboard related templates I saw that fancypages/templates/fancypages/dashboard/partials/page_select_link.html uses the category variable in the context. This won't work with the refactoring branch changes.

This need to be confirmed, fixed and tested.

Using django-configurations makes it simple to extend settings for different purposes. It should therefore be possible to create a combined sandbox for both standalone FP and Oscar FP. This will also help setting up demo sites.

Documentation is still a big issue with fancypages. We need to address this for the 0.5 release to make it easier for people to adapt fancypages.

As @funkybob pointed out, there are some occurrences of CharField with null=True. Since this is bad practise, these instances should be removed.

Fancypages currently does not provide a way of saving a page with a pre-defined set of widgets. This could be used when creating a page to save this configuration as a Template that can then be used to create new pages with the configured widgets.

Ideally, the user can create a page as they would normally. The editor provides a button to save the current page as a template and creates a clean copy (without any content). This page is flagged as template. When a user now creates a new page, in addition to just create a blank page, the user can select a pre-configured page to use.

Reported by @a-musing-moose in django-oscar-fancypages#90.

When you try to delete a user in admin it warns that certain widgets and image assets are also going to be deleted.

Check all models in fancypages for foreign keys related to users and set the on_delete attribute appropriately.

The current state of the frond-end, especially JavaScript, is not optimal and in dire need of more structure. Recent experience with Marionette has me convinced that it is going to be the way forward on the FE for fancypages. So that's what needs to be done 😄

Users need the ability to justify text either left, right or centre when creating text widgets anywhere.

Playing with sandbox. When uploading a new image asset, the following traceback occurs:

Internal Server Error: /dashboard/fancypages/assets/image/upload/
Traceback (most recent call last):
  File "/home/izidor/.virtualenvs/django-fancypages/local/lib/python2.7/site-packages/django/core/handlers/base.py", line 115, in get_response
    response = callback(request, *callback_args, **callback_kwargs)
  File "/home/izidor/downloads/django-fancypages/fancypages/utils/decorators.py", line 30, in _checklogin
    return view_func(request, *args, **kwargs)
  File "/home/izidor/downloads/django-fancypages/fancypages/utils/decorators.py", line 30, in _checklogin
    return view_func(request, *args, **kwargs)
  File "/home/izidor/.virtualenvs/django-fancypages/local/lib/python2.7/site-packages/django/views/generic/base.py", line 68, in view
    return self.dispatch(request, *args, **kwargs)
  File "/home/izidor/.virtualenvs/django-fancypages/local/lib/python2.7/site-packages/django/views/generic/base.py", line 86, in dispatch
    return handler(request, *args, **kwargs)
  File "/home/izidor/.virtualenvs/django-fancypages/local/lib/python2.7/site-packages/django/views/generic/edit.py", line 199, in post
    return super(BaseCreateView, self).post(request, *args, **kwargs)
  File "/home/izidor/.virtualenvs/django-fancypages/local/lib/python2.7/site-packages/django/views/generic/edit.py", line 163, in post
    form = self.get_form(form_class)
  File "/home/izidor/.virtualenvs/django-fancypages/local/lib/python2.7/site-packages/django/views/generic/edit.py", line 35, in get_form
    return form_class(**self.get_form_kwargs())
  File "/home/izidor/.virtualenvs/django-fancypages/local/lib/python2.7/site-packages/django/forms/models.py", line 238, in __init__
    raise ValueError('ModelForm has no model class specified.')
ValueError: ModelForm has no model class specified.

Pages need to allow for non-unique page titles. At least between parent categories.

Experience with categorisation schemes such as BIC2 suggest that category names are repeated within different parent categories.

i.e. the following should be allowed:

• Fiction
  • Crime
  • Fantasy
• Non-Fiction
  • Crime
  • Art

but this should not:

• Fiction
  • Crime
  • Crime
• Non-Fiction
  • Crime
  • Art

It seems that select2 drop-down menus are not showing up in the dashboard for fancypages. This needs to be investigated.

Since django compressor is in setup.py does it make sense to add compress blocks to extrascripts and extrahead?

MP_Node get_children just returns a query_set, so is_visible for child pages in the Dashboard view doesn't work.

btw, really dig this project, nice and simple cms.

Creating migrations in Django 1.7 introspects that field definition and adds the choices iterable of a CharField into the migration. This causes an issue for fields like the form_selection field in the FormBlock because it is configured in the settings.

We need to make the current settings available to the migration via a function call or generated constant at runtime.

• Add/Remove page from group
• Should be possible to create a group for pages (menu group)
• In the page settings, groups should only be displayed when there's at least one available

We need to add the ability to create a google map with a marker placed within the map.

Currently FP still relies on bootstrap for the Javascript (e.g. for modal). This should be removed and replaced with FP's own JS. I've got to look into this to figure out what the best solution is.

The test rendering block subclasses currently fails when running against django-model-utils 2.0+ and Django 1.5.5. It reaches maximum recursion depth in when trying to render layout blocks. This needs further investigation to be fixed. For the time being, version 1.5 of django-model-utils seems to fix the problem (at least in the tests).