Upgrade to Django 4.2 #3049
Comments
This version is Django 4.2 compatible
|
Ik heb het samen nagelopen met @sergei-maertens en we zijn tot de conclusie gekomen dat de versie van |
This version supports Django 4.2. Thanks to @ErhanCitil for doing the research.
|
Het enige wat er gedaan moet worden is het updaten van de package naar een nieuwere versie in de requirements, de laatste versie op dit moment is: |
django-yubin now uses celery for queuing out of the box, so we no longer need to simulate cron to actually send out the e-mails. See https://django-yubin.readthedocs.io/en/latest/install.html\#upgrading-from-previous-versions which documents the upgrade steps.
django-yubin now uses celery for queuing out of the box, so we no longer need to simulate cron to actually send out the e-mails. See https://django-yubin.readthedocs.io/en/latest/install.html\#upgrading-from-previous-versions which documents the upgrade steps.
django-yubin now uses celery for queuing out of the box, so we no longer need to simulate cron to actually send out the e-mails. See https://django-yubin.readthedocs.io/en/latest/install.html\#upgrading-from-previous-versions which documents the upgrade steps.
|
|
|
Ik heb de tox bestand bekeken en de GitHub actions en de tests die slagen. |
|
Deze package kan goedgekeurd worden op de bovenstaande lijst. |
|
Alleen de |
|
Deze package moet geupdate worden in de requirements naar de versie |
|
Dus de package moet in de requirements geupdate worden van |
|
Dus de package |
|
Deze package moet dus geupdate worden van versie |
|
@ErhanCitil je mag gerust pull requests maken naar open forms om deze dependencies te updaten! Ik zorg even dat er een fork is onder maykinmedia |
Isgoed zal ik doen! |
The theme toggle sets a theme attribute on the html node, so that the user can configure this instead of configuring their entire browser appearance. In auto mode, this requires some special care to not accidentally apply dark theme styles in some places (like form fields).
Logging out is now done through a POST request with a form, so the link styles are no longer applied automatically.
The logout link is now a logout form, so response.form in webtest crashes because multiple forms are on the page.
Due to auto/explicit modes now being a thing, the detection purely through a media query is not sufficient. Instead, if an explicit theme is set, that maps to the skin/content_css properties. If the theme mode is set to 'auto', then the media query applies to figure out whether dark or light theme needs to be applied. The code is refactored to remove duplication and instead have a more declarative approach for possible future themes.
… changes tinyMCE does not handle this itself, you need to explicitly force it to destroy and re-initialize itself. Django has two mechanisms w/r to the theme: * store the selected theme in localStorage (if unset, it's assumed to be 'auto') * set the data-theme attribute on the root html node, which triggers the relevant CSS rules to change the appearance So, whenever the theme changes, the localStorage is updated and the data-attribute on the HTML node changes. We can observe the html node changes, and use that to synchronize our (derived) global state. We don't care about dark/light/auto, only about the resulting theme of a particular choice - this result is stored in the global state. Then, our pages with tinymce editors need to subscribe to the global state changes so that they can re-initialize: * react component, easy, just make sure the 'key' prop changes and react will unmount and remount the node, triggering the re-init in the process from @tinymce/react * the django-tinymce code is trickier, since there we need to get each editor instance ourselves and subscribe to the global state to ensure we reset the editors. This further customizes the overridden code from the upstream package.
* Fixed missing (new) class name in react components to apply inline labels + fields * Override django admin styling to not vertically stretch input fields for labels longer than 160px that wrap unto the next line * Override checkbox styling to vertically center checkbox + label instead of the weird offsets we otherwise have. It's probably wise to re-do the admin overrides implementation from vanilla admin CSS again to see what is actually still needed, but ideally we'd have visual regression testing set up for all involved components.
The Django markup changed substantially so the existing CSS was no longer usable. However, using the :has pseudo selector we can re-instate the same appearance with some clever CSS grid/flexbox usage. Colors for the tooltip are now specified as CSS variables too, so this patch should be easily backported to default-project. The relevant styles are put in a separate SASS module to easier keep track of which aspect of the django admin they touch.
Set to auto so that the browser preferences and storybooks default dark/light mode tool (hopefully) work out of the box without requiring an explicit theme switcher.
The admin markup has changed, so hijack needs to be pointed to the correct HTML element to properly display.
In 4.2 it is no longer possible to query relations on instances not in the DB https://github.com/django/django/blob/4.2/django/db/models/fields/related_descriptors.py#L718 In some places this points out a genuine defect in the test where helpers run DB queries that could lead to a different outcome, in other places (like audit logging) the audit logging is not what is being tested and we can just disable it so we can benefit from the SimpleTestCase and .build() speed advantages. Co-authored-by: @sergei-maertens <sergei@maykinmedia.nl>
Django supports stdlib zoneinfo since 4.0.
The pytz -> zoneinfo update results in different behaviour how DST seems to be treated. The new variant captures correctly the beginning and end DST/UTC offset, and it keeps the hour for the end-user consistent, so in my mind it makes sense?
Added in Django 4 in the base templates, which we need to account for in our overrides.
The theme toggle sets a theme attribute on the html node, so that the user can configure this instead of configuring their entire browser appearance. In auto mode, this requires some special care to not accidentally apply dark theme styles in some places (like form fields).
Logging out is now done through a POST request with a form, so the link styles are no longer applied automatically.
The logout link is now a logout form, so response.form in webtest crashes because multiple forms are on the page.
Due to auto/explicit modes now being a thing, the detection purely through a media query is not sufficient. Instead, if an explicit theme is set, that maps to the skin/content_css properties. If the theme mode is set to 'auto', then the media query applies to figure out whether dark or light theme needs to be applied. The code is refactored to remove duplication and instead have a more declarative approach for possible future themes.
… changes tinyMCE does not handle this itself, you need to explicitly force it to destroy and re-initialize itself. Django has two mechanisms w/r to the theme: * store the selected theme in localStorage (if unset, it's assumed to be 'auto') * set the data-theme attribute on the root html node, which triggers the relevant CSS rules to change the appearance So, whenever the theme changes, the localStorage is updated and the data-attribute on the HTML node changes. We can observe the html node changes, and use that to synchronize our (derived) global state. We don't care about dark/light/auto, only about the resulting theme of a particular choice - this result is stored in the global state. Then, our pages with tinymce editors need to subscribe to the global state changes so that they can re-initialize: * react component, easy, just make sure the 'key' prop changes and react will unmount and remount the node, triggering the re-init in the process from @tinymce/react * the django-tinymce code is trickier, since there we need to get each editor instance ourselves and subscribe to the global state to ensure we reset the editors. This further customizes the overridden code from the upstream package.
* Fixed missing (new) class name in react components to apply inline labels + fields * Override django admin styling to not vertically stretch input fields for labels longer than 160px that wrap unto the next line * Override checkbox styling to vertically center checkbox + label instead of the weird offsets we otherwise have. It's probably wise to re-do the admin overrides implementation from vanilla admin CSS again to see what is actually still needed, but ideally we'd have visual regression testing set up for all involved components.
The Django markup changed substantially so the existing CSS was no longer usable. However, using the :has pseudo selector we can re-instate the same appearance with some clever CSS grid/flexbox usage. Colors for the tooltip are now specified as CSS variables too, so this patch should be easily backported to default-project. The relevant styles are put in a separate SASS module to easier keep track of which aspect of the django admin they touch.
[#3049] Upgrade to django 4.2
👽 [#3049] Ensure the data-theme attribute is set
Checklist to prepare the Django 4.2 LTS upgrade
3rd party packages to verify/make compatible
Open Forms itself
ugettext*variants (theuprefix can be dropped)pytztozoneinfoThe text was updated successfully, but these errors were encountered: