|
|
@@ -119,6 +119,7 @@ For the majority of cases, the new StreamField implementation in this release wi
|
|
|
* When customising the form template for a ``StructBlock`` using the ``form_template`` attribute, the HTML of each child block must be enclosed in an element with a ``data-contentpath`` attribute equal to the block's name. This attribute is used by the commenting framework to attach comments to the correct fields. See :ref:`custom_editing_interfaces_for_structblock`.
|
|
|
* If a ``StructBlock`` subclass overrides the ``get_form_context`` method as part of customising the form template, and that method contains logic that causes the returned context to vary depending on the block value, this will no longer work as intended. This is because ``get_form_context`` is now invoked once with the block's default (blank) value in order to construct a template for the client-side rendering to use; previously it was called for each block in the stream. In the new implementation, any Python-side processing that needs to happen on a per-block-value basis can be performed in the block's ``get_form_state`` method; the data returned from that method will then be available in the client-side ``render`` method.
|
|
|
* If ``FieldBlock`` is used to wrap a Django widget with non-standard client-side behaviour - such as requiring a JavaScript function to be called on initialisation, or combining multiple HTML elements such that it is not possible to read or write its data by accessing a single element's ``value`` property - then you will need to supply a JavaScript handler object to define how the widget is rendered and populated, and how to extract data from it.
|
|
|
+* Packages that replace the StreamField interface at a low level, such as ``wagtail-react-streamfield``, are likely to be incompatible (but the new StreamField implementation will generally offer equivalent functionality).
|
|
|
|
|
|
For further details, see :ref:`custom_streamfield_blocks`.
|
|
|
|
Matt Westcott