The order of nested InlinePanels (recently formally added in 5566)
doesn't get saved properly due to some now-invalid assumptions in the JS
selector code.
Currently, Wagtail users can use the editor up/down arrows to order
InlinePanel elements that contain child InlinePanels, but these may not
be properly saved.
Before InlinePanel nesting was supported, it was a safer bet that a
child panel would only contain one hidden input named "-ORDER". With
nesting, however, a parent panel will also contain hidden inputs named
like this for its child panels. This breaks the logic used in the
ordering code.
This change modifies the logic to use the jQuery `.children()` selector
instead of `.next()`, ensuring that we reference the correct adjacent
panel item.
An easy way to test this against current master is to use the Wagtail
testapp test models that exercise this behavior:
1. `wagtail start testwagtail` to create a new project.
2. `cd testwagtail`
3. Edit testwagtail/settings/base.py to add the Wagtail test
application `'wagtail.tests.testapp'` to the list of `INSTALLED_APPS`.
For the admin to work properly with this app, you also need to add
`'wagtail.contrib.settings'` to that list and copy the definition of
`WAGTAILADMIN_RICH_TEXT_EDITORS` from wagtail/tests/settings.py.
4. `./manage.py migrate` to create your local database.
5. `./manage.py createsuperuser` to create an admin user.
6. Create a new Event Page
(http://localhost:8000/admin/pages/add/tests/eventpage/3/).
7. Fill in all required items, and then add multiple speakers under
"Speaker Lineup". For each speaker, add at least one Award. Save the
page.
8. Try using the up/down arrows to reorder the speakers (the parent
InlinePanel), and save the page.
9. Note that when the page reloads, the ordering hasn't been saved. If
you debug using the developer tools, you'll notice that this is because
the code being modified here selects the child panel items instead of
the adjacent parent panel item.
- items longer then the page height are no longer broken by the submenu footer
- long lists of submenu items are no longer blocked by the footer (version number)
- Typo in readme (verb did not agree with the subject)
- Grammatical error in topics/pages
- #5364 - Update URL config code block in getting-started/integrating-into-django
The current block id generation only sets the id as the block is serialized for storage in the database, which means that the id is unavailable in the block until it is pulled back from the database. In my debugging this caused the id to be set to new values up to 3 times when saving a brand new page (each time with a new id).
This updated logic applies the new id to the actual block which makes it available right away and prevents the id from being regenerated.
This commit adds WAGTAIL_EMAIL_MANAGEMENT_ENABLED setting that defaults
to True, but when disabled, hides the 'Change email' button in account
management view, and disables the associated route. This is useful when
using external authentication method like LDAP or OpenID Connect where
email management is handled elsewhere.
Wagtail already includes WAGTAIL_PASSWORD_MANAGEMENT_ENABLED setting.
This is almost exact copy of that implementation.
Fix doc and test on ES6 python client compat
This commit changes the statement that version < 6.3.1 of the
elasticsearch python client should be used to instead state
that 6.4.0 is fine.
It also update the tests to reflect the statement.
Initially the `update_all_types` argument has been used to work
around an issue described in:
https://github.com/wagtail/wagtail/issues/2968
This argument was removed in elasticsearch-py 6.3.1 and making
use of it was raising an error.
With 6.4.0 nothing is raising anymore.
Resolves "DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated, and in 3.8 it will stop working" - see #5484
Eric Sherman