Wagtail 3.0 release candidates #8362
Replies: 9 comments 51 replies
|
Just upgraded the staging environment for a site I manage to 3.0rc1. Went quite smooth! Bit more work than a regular upgrade, but nothing unmanageable 👍 The |
|
Looks fantastic, the UI finally feels like it got that modern touch. |
|
Release candidate 2 is now available. Changes from rc1 are:
|
|
Aha - according to https://docs.python.org/3.7/library/functions.html#open (via this stackoverflow answer) the encoding used is system-dependent, which I'm guessing means it defaults to Windows-1252 on Windows and fails even if you did the correct Python-3-compliant thing and saved it as UTF-8... I'll fix this so that it specifies utf-8 explicitly. |
|
OK, great. I'm on Python 3.9.4 if that makes any difference. I'll see if I can track down where it trips up. |
|
"Smart" quote characters in a template tag (“”). The file is saved in UTF-8 for sure. I'll use the unicode escape char instead. |
|
I can run it in each of my subfolders, but still get the same error in the root. There's only manage.py in the root - not sure where to look next ... |
|
PR now opened to hopefully fix this: #8450 |
|
regarding use_json_field doesn't apply to sqlite db, as it doesn't support it, if this is a BUG, let me rais an issue the above is the errors that shown dureing ./manage.py migrate command (edited) |
|
I am having the same issue on windows: wagtailcore.ModelLogEntry: (fields.E180) SQLite does not support JSONFields. yet I am using python's latest version. Is there another fix identified for this issue? Thanks |
|
@marcdc123 Just to confirm - did you use the Windows installer package from https://www.python.org/ ? (And is it version 3.11.1?) |
|
I did, based on hazho question, I checked the version and reinstalled it from the official website just to be sure |
|
With the virtual environment activated, what's the output of if you put it in the command prompt? Also, what's the output when you launch the Python shell? (it should tell you the Python version and build date). I'd be surprised if the latest version somehow still doesn't include JSON1. But if it's really the case, you can follow the instructions at https://code.djangoproject.com/wiki/JSON1Extension#windows |
|
Can't really understand what happened but after following the instructionsfor windows, it is working. Thanks |
|
I've run through all the instructions on the release notes, site renders fine, but I run into an error trying to edit either pages or snippets: Error detailsSite settings and user edit page is fine, just snippets and pages I can't edit. |
|
This is a deprecation that happened in Wagtail 2.15. Assuming you haven't customised the action menu yourself (check your project for any references to |
|
Ok, no custom action menu, but I was on wagtail-localize 1.0.1, upgraded to 1.1.1 and now raising an error trying to make migrations: File "C:....venv\lib\site-packages\wagtail_localize\models.py", line 67, in I guess wagtail-localize still has some way to be 3.x compatible. |
|
That is correct. Latest main still has that particular import has been fixed in latest main and I will release 1.1.2 with a |
|
Ok, great, thanks for that |
|
@zerolab 1.1.2 did the trick! I can edit all now. Many thanks! |
|
Release candidate 3 is now out! Changes from 3.0rc2:
Please give it a try and let us know your feedback! All things being well, 3.0 final will be out during the week of 16th May. |
|
Not sure if I have something goofy going on in my own setup (aka my development environment, no static files in the way) just yet but is it expected that the old green header appears in some views? I was viewing the new edit page, then clicked on the breadcrumb to head back to the root and found it jarring to go back to the old green UI:
Again, not sure if this is just an oddity in my setup but there isn't any spacing between icons and text labels:
Old version:
Other than that, so far so good on a fairly complicated site with customizations that have bit us in the past so🤞 |
|
There seems to be several visual regressions in this release compared to rc2 wagtail 3.0rc2 wagtail 3.0rc3
The header style issues appear on:
Header appears as expected on /admin/pages/* modeladmin/inspect.htmlI have been working on updating https://github.com/neon-jungle/wagtail-birdsong to be compatible with wagtail 3.0 and have noticed there is also a header issue on views that extend "modeladmin/inspect.html" with rc3 extending "modeladmin/inspect.html" on wagtail 3.0rc2 extending "modeladmin/inspect.html" on wagtail 3.0rc3 |
@jsma Yep, that's expected - the switch to the new styling is a work in progress and will be completed in the next release (4.0). The issue with the icon spacing in the action menu has been reported, and a fix is on the way: #8467 |
|
Could Someone help me out with the new BoundPanel class? I'm not fully understanding the code example in the release notes. It starts off with an example declaration But that second line is always going to fail since the CustomPanel isn't an attribute of Panel. Next thing I can't see is if the entire custom panel should sit inside the Bound Panel subclass. Here's the simplest of my panels to amend: It just passes on some attribute to the template for JavaScript rendering. Should the RegEx panel subclass Panel (or remain as FieldPanel) and then the entire body be inside a BoundPanel subclass with the set_attr moved up into init? Thanks for any input. |
|
@gasman ahh ... perfect, that has it working now, and the next one with dynamic dropdowns ... thanks for your help! Much appreciated. Just my EditHandler subclassed components to figure out now. |
I inherited the custom from Image itself.. |
|
@hazho OK, yep - if you've not followed the recipe in the documentation then that's custom code, and it's your own responsibility to update that for 3.0. |
|
but pythonically, it shoild be fine, because it's parent is the one that new changes of 3.0 working with without any issue, then why not for it's decendants? |
|
@hazho If you think there's a bug with Wagtail's handling here, please open a Github issue with detailed steps to reproduce it - I can't troubleshoot based on one line of code at a time. |
|
Seems EditHandlers are the hardest part of the upgrade for me ... I have two more custom panels that do some HTML rendering which both throw the error I don't think the HTML rendering has anything to do with the error as I can disable all the methods and be left with only init and clone and still get the same error. The line of code that throws the error is in django, yield trips it up The error traces back to Code for the panelclass ReadOnlyPanel(EditHandler):
""" ReadOnlyPanel EditHandler Class
Usage:
attr: name of field to display
style: optional, any valid style string
add_hidden_input: optional, add a hidden input field to allow retrieving data in form_clean (self.data['field'])
If the field name is invalid, or an error is received getting the value, empty string is returned.
"""
def __init__(self, attr, style=None, add_hidden_input=False, *args, value=None, **kwargs):
# error if attr is not string
if type(attr)=='str':
self.attr = attr
else:
try:
self.attr = str(attr)
except:
pass
self.style = style
self.add_hidden_input = add_hidden_input
super().__init__(*args, **kwargs)
def get_value(self):
# try to get the value of field, return empty string if failed
try:
value = getattr(self.instance, self.attr)
if callable(value):
value = value()
except AttributeError:
value = ''
return value
def clone(self):
return self.__class__(
attr=self.attr,
heading=self.heading,
classname=self.classname,
help_text=self.help_text,
style=self.style,
add_hidden_input=self.add_hidden_input,
value=None,
)
def render(self):
# return formatted field value
self.value = self.get_value()
return format_html('<div style="padding-top: 1.2em;">{}</div>', self.value)
def render_as_object(self):
return format_html(
'<fieldset>{}'
'<ul class="fields"><li><div class="field">{}</div></li></ul>'
'</fieldset>',
self.heading('legend'), self.render())
def hidden_input(self):
# add a hidden input field if selected, field value can be retrieved in form_clean with self.data['field']
if self.add_hidden_input:
input = f'<input type="hidden" name="{self.attr}" value="{self.value}" id="id_{self.attr}">'
return format_html(input)
return ''
def heading_tag(self, tag):
# add the label/legend tags only if heading supplied
if self.heading:
if tag == 'legend':
return format_html('<legend>{}</legend>', self.heading)
return format_html('<label>{}{}</label>', self.heading, ':')
return ''
def get_style(self):
# add style if supplied
if self.style:
return format_html('style="{}"', self.style)
return ''
def render_as_field(self):
# render the final output
return format_html(
'<div class="field" {}>'
'{}'
'<div class="field-content">{}</div>'
'{}'
'</div>',
format_html(self.get_style()), self.heading_tag('label'), self.render(), self.hidden_input()) As said, I can comment all the methods other than init and clone and still get the error. I don't see anything there that would be causing this, while working fine in 2.x. |
|
The solution for the above was to push everything but the init and clone into an class ReadOnlyPanel(EditHandler):
def __init__(self, fieldname, style=None, add_hidden_input=False, *args, **kwargs):
# error if fieldname is not string
if type(fieldname)=='str':
self.fieldname = fieldname
else:
try:
self.fieldname = str(fieldname)
except:
pass
self.style = style
self.add_hidden_input = add_hidden_input
super().__init__(*args, **kwargs)
def clone(self):
return self.__class__(
fieldname=self.fieldname,
heading=self.heading,
help_text=self.help_text,
style=self.style,
add_hidden_input=self.add_hidden_input,
)
class BoundPanel(EditHandler.BoundPanel):
def get_value(self):
# try to get the value of field, return empty string if failed
try:
value = getattr(self.instance, self.panel.fieldname)
if callable(value):
value = value()
except AttributeError:
value = ''
return value
def render_html(self):
# return formatted field value
self.value = self.get_value()
return format_html('<div style="padding-top: 1.2em;">{}</div>', self.value)
def render(self):
# return formatted field value
self.value = self.get_value()
return format_html('<div style="padding-top: 1.2em;">{}</div>', self.value)
def render_as_object(self):
return format_html(
'<fieldset>{}'
'<ul class="fields"><li><div class="field">{}</div></li></ul>'
'</fieldset>',
self.panel.heading('legend'), self.render())
def hidden_input(self):
# add a hidden input field if selected, field value can be retrieved in form_clean with self.data['field']
if self.panel.add_hidden_input:
input = f'<input type="hidden" name="{self.panel.fieldname}" value="{self.value}" id="id_{self.panel.fieldname}">'
return format_html(input)
return ''
def heading_tag(self, tag):
# add the label/legend tags only if heading supplied
if self.heading:
if tag == 'legend':
return format_html('<legend>{}</legend>', self.panel.heading)
return format_html('<label>{}{}</label>', self.panel.heading, ':')
return ''
def get_style(self):
# add style if supplied
if self.panel.style:
return format_html('style="{}"', self.panel.style)
return ''
def render_as_field(self):
# render the final output
return format_html(
'<div class="field" {}>'
'{}'
'<div class="field-content">{}</div>'
'{}'
'</div>',
format_html(self.get_style()), self.heading_tag('label'), self.render(), self.hidden_input()) I guess, for me, it wasn't clear in the release notes that all custom panels would be affected by the change, I read "The methods on_request_bound, on_instance_bound and on_form_bound are no longer used. " and figured only these panels were affected. |
|
Almost, you need to change “render_html” |
|
I've just tested 3.0rc3 with an application that previously caused a bundle of UI issues with Wagtail 2.16. See #7971 (comment) particularly issue 1 where the alignment of the "Comment notifications" text wraps with an indent that depends on the browser width: Narrow enough to wrap: Even narrower, but the text is now better aligned: It might be worth a quick review of all the noted UI issues in #7971 to see if some of the others described are related to changes for Wagtail 3.0. None of these are show stoppers for 3.0 but should be addressed on the way to 4.0. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
I'm delighted to announce that the first release candidate of Wagtail 3.0 is now available!
This version bump is marked by a few significant changes for the project:
A major design refresh. The admin interface has been updated with a new sidebar, font stack, tab design and page editor. Further updates are expected for the next release, scheduled for August.
Architectural improvements. Notably, imports such as
wagtail.core.modelsare now simplified towagtail.models, and it is no longer necessary to use dedicated panel types for choosers and StreamField. Additionally, StreamField and other areas of Wagtail using JSON data representations have been migrated to use Django's native JSONField support.A move to semantic versioning. As of this release, major version increments will be used more frequently, to more clearly communicate breaking changes in code and notable user-facing UI changes, and assist site owners and package maintainers in planning upgrades. As such, we expect to release a Wagtail 4.0 in August incorporating the remaining planned updates to the page editor.
For the full details of this release, see the Wagtail 3.0 release notes.
With a major release like this, we're especially keen to see it tested against real-world sites to help us catch any issues in advance of the final 3.0 release (scheduled for the first half of May), and so we'd like to invite you to try it out against your development and staging sites. Be sure to check the upgrade consideration notes, as they're more sizable than usual.
UPDATE 2022-04-22: Release candidate 2 is now available.
UPDATE 2022-04-29: Release candidate 3 is now available.
To install, set
wagtail==3.0rc3in your project's requirements. For general advice on upgrading, see Upgrading Wagtail.We'd love to hear your feedback, good or bad - on this thread, on GitHub issues where appropriate, or on #watercooler on Slack.
All reactions