Tables in Wagtail

[Christoph Lipp]

Hi everyone

We tried to implement a table using the given controls. First assumption was to use the rich-text editor, but somehow it's not supported in the Halo editor(?).

Second attempt was to create a streamfield and to mimic a table by adding pre-built rows to a table. Then you have to add columns in a vertical order, which is rater counter-intuitive since we're used to columns on a horizontal line. I could overwrite the structblock object, but as far as I understand the API might change.

So I wanted to ask you guys how you implemented tables? Is there a way to add table support to halo? We have a few tables on the page but even tough we like the simple editor approach, adding tables is quite a pain right now.

Best regards,
Christoph

[Matthew Westcott]

Hi Christoph,

There's no formal support for tables within Wagtail at the moment. There's some interest in building it as a StreamField component <https://groups.google.com/d/msg/wagtail-developers/f53M_k_1iAE/rs9SEgh2LKMJ>, but nothing exists yet...

It's possible that there are third-party hallo.js plugins available to provide table support, and if so, it would be possible to integrate these into Wagtail with a bit of customisation work (see https://jossingram.wordpress.com/2014/07/24/add-some-blockquote-buttons-to-wagtail-cms-wysiwyg-editor/) - however, I would advise against this approach. The rich text field is not designed to be a container for arbitrary HTML - if you use it like that, you're breaking the principle of separating content and presentation that Wagtail is designed around.

One (rather ugly) workaround we've used is to build the table using an external tool like http://www.tablesgenerator.com/html_tables, and paste the HTML output into a 'raw HTML' streamfield block - that's arguably a cleaner solution than using a rich text area, because it's contained within its own field designed for arbitrary HTML, rather than mixing it with 'regular' article content.

I'd certainly encourage taking a step back and thinking about the purpose of the table. It's not just formatted text on a page - presumably it's data of some kind, so maybe it belongs as a real model in your database. If so, that could be done through snippets - or maybe managing it outside of Wagtail is a better idea. Once you've solved that problem, displaying it as a table is just a matter of looping over the data in template code :-)

Cheers,
- Matt

[Tammo van Lessen]

Hi Matt,

thanks for this answer. I'm also looking for more rich text capabilities, not really because I like this so much but because we have the requirement to enable authors to copy and paste contents from word documents while maintaining the semantics of the document (i.e. strong, italics, headlines, links etc.). Separating that into a linear sequence of streamfield block would siginificantly increase the work load for such authors. I also don't see tables violating the separation between content and presentation, as long as only the table semantics are maintained and the presentation is handled by the template/css.

Do you see any possibility to better support this Copy-from-Word use case? I understand that the Wagtail team may consider this out of scope, but pointers regarding feasibility and implementation options would be very helpful.

Thanks,

  Tammo

[Matthew Westcott]

Hi Tammo,

Allowing people to paste text in from Word, while still capturing all the semantic details required for a well-structured web page - that's probably the Holy Grail of content management systems :-) The problem is that when you paste content from Word into a browser, it's effectively reduced to just a set of <span> elements with font styles attached. I'm not sure what happens with tables, but I'm pretty sure that a bullet list gets reduced to a plain paragraph with line breaks and bullet characters embedded in it, not a <ul>. The best we can do (short of having heuristics to inspect the 'tag soup' HTML and guess what elements they're supposed to be) is to strip the markup to the bare minimum, and rely on editors to re-apply it manually.

In the medium term, I hope that we can improve the StreamField user interface to the point where it's as seamless and natural to use as the rich text field: for example, pressing enter while you're typing into a 'paragraph' block would start a new paragraph block. (And then you could subsequently insert new blocks in between them - including complex elements like tables.) From there, it's not much of a leap to imagine pasting multiple paragraphs of text into a StreamField, and having it divide them into separate blocks. (And *then* we can think about adding those heuristics to determine which of those 'paragraphs' are actually headings, or lists, or tables...)

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/67d79554-b414-4123-88d6-bf65393fceae%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[YusufSalahAdDin]

I  don't understand, if stream field is aslo very complete, then why you provide the RichtextField?

[Matthew Westcott]

RichTextField existed first - StreamField is only just being added in Wagtail 1.0. I believe that StreamField is the better solution for 95% of situations, but we're not going to get rid of RichTextField because a lot of existing sites depend on it.

Cheers,
- Matt