StreamField within an Inline Panel causing object is not iterable error.

[Caroline Simpson]

Hi, 

  I'm running into an error when I try to add a related model that has a StreamField defined.  When ever I try to go to the admin page to edit or create a page of this type I get a "'NoneType' object is not iterable" error.

I'm not sure if I'm doing something wrong or if this is a bug.  Has any one found a way to do this sort of thing?  I've tried this a few times and have run into the same issue each time.  

Below are the (simplified) models in question for a better idea of what we are trying to do. ChapteredArticlePage is the type of page I am trying to create when I run into the error:

class ChapteredArticlePage(Page):
    excerpt = RichTextField(blank=True, default="")

   body = BodyField()


ChapteredArticlePage.content_panels = Page.content_panels + [
    FieldPanel('excerpt'),
    StreamFieldPanel('body'),
    InlinePanel('chapters', label="Chapters"),
]


class Chapter(models.Model):
    heading = models.CharField(max_length=512, blank=True)
    body = BodyField()

    content_panels = [
        FieldPanel('heading'),
        StreamFieldPanel('body'),
    ]

    class Meta:
        abstract = True

class ArticleChapter(Orderable, Chapter):
    page = ParentalKey(ChapteredArticlePage, related_name='chapters')


class BodyField(StreamField):
    def __init__(self, block_types=None, **kwargs):
        block_types = [
            ('Heading', HeadingBlock()),
            ('Paragraph', ParagraphBlock()),
            ('Image', ImageBlock()),
            ('Embed', EmbedBlock(icon="site")),
            ('List', blocks.ListBlock(
                blocks.RichTextBlock(label="item"), icon="list-ul")
             ),
        ]

        super(BodyField, self).__init__(block_types, **kwargs)

(omitting the block class code, because it doesn't seem to matter what types of blocks are included for the error to occur). 

Thanks, 
  Caroline Simpson

[Matthew Westcott]

Hi Caroline,
Unfortunately putting a StreamField inside an inline child object isn't something we've tested or are able to support right now. As far as I know there's no fundamental reason why it *couldn't* be made to work, but it involves some complicated interactions between different components of Wagtail - both server-side, and in the Javascript that powers the edit interface - so I wouldn't be at all surprised to find some bugs lurking in there.

One thing that does work - although the UI for it will be rather ugly - is nesting a StreamField (or rather, a StreamBlock) within a StreamField. You could have a 'chapters' StreamField as a field of ChapteredArticlePage, where the only available block type is BodyBlock, a StreamBlock with all of your block types. In other words, you're using an outer StreamField as the repeating mechanism, rather than an inline model:

# a refactored version of your BodyField, which makes the underlying StreamBlock available to be re-used:
class BodyBlock(blocks.StreamBlock):
Heading = HeadingBlock()
Paragraph = ParagraphBlock()
Image = ImageBlock()
Embed = EmbedBlock(icon="site")
List = blocks.ListBlock(blocks.RichTextBlock(label="item"), icon="list-ul")

class BodyField(StreamField):
def __init__(self, **kwargs):
super(BodyField, self).__init__(BodyBlock(), **kwargs)

class ChapteredArticlePage(Page):
excerpt = RichTextField(blank=True, default="")
body = BodyField()

# a StreamField where the only available block is BodyBlock
chapters = StreamField([
('Chapter', BodyBlock()),
])

ChapteredArticlePage.content_panels = Page.content_panels + [
FieldPanel('excerpt'),
StreamFieldPanel('body'),

StreamFieldPanel('chapters'),
]

(incidentally, I'd recommend using lower-cased names for your block identifiers - 'heading', 'paragraph' etc - as those are the equivalent of model field names, and will be capitalised automatically when they appear as labels in the admin. I've kept them capitalised here for consistency.)

Once your page model reaches this level of complexity, though, I'd be more inclined to look for ways of breaking down the content into smaller individually-editable units. Perhaps Chapter could be a page type of its own, which you create as a subpage of ChapteredArticlePage? That doesn't necessarily mean that it has to be presented as multiple pages on the front-end - the subpages would just be containers for the page data, and the parent ChapteredArticlePage would retrieve that (as an index page would) and output the complete article.

Cheers,
- Matt

> --
> You received this message because you are subscribed to the Google Groups "Wagtail support" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to wagtail+u...@googlegroups.com.
> To post to this group, send email to wag...@googlegroups.com.
> Visit this group at http://groups.google.com/group/wagtail.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/wagtail/7fd950bf-86f6-4575-9cb6-2fde7bc85c9f%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Caroline Simpson]

Thanks Matt.

I've used the embedded StreamFields inside StreamFields previously to do something similar.  It makes some of the things we are trying to accomplish trickier (but not impossible), but will probably make the most sense for the editors in this use case.  I think having to jump back and forth between pages to edit the document will make it harder for them (chapters are fairly short in this case).

Would there be value in my logging this issue in GitHub for future development?

Thanks, 

 Caroline

[Matthew Westcott]

Yes, it would be worth adding this to GitHub - I can't say when we'd be likely to get round to investigating it, but it would be good to keep it on our radar.

Cheers,
- Matt

> To view this discussion on the web, visit https://groups.google.com/d/msgid/wagtail/e1c9cf38-8443-497b-9f4b-3b2548acae8e%40googlegroups.com.

[Caroline Simpson]

Finally added to github:  https://github.com/torchbox/wagtail/issues/1735