Fixes #4791
Previously, our rich text conversion functions handled the case where a document link specified an ID which is not found in the database. However, they failed with a KeyError when the id attribute was missing completely; links of this second type would occur whenever a link of the first type was re-saved from the Draftail editor. The fix is two-fold:
1) Catch the "missing ID attribute" case - in this case, the resulting link will be missing both the href and id attributes
2) Update the handling of the "ID present but document not found" case so that the id attribute survives the round-trip to the editor and back. The final link as rendered on the front-end will still be an attribute-less <a> element, but the id will be retained in the database (and in the versions rendered within rich text editors) which may be useful for troubleshooting.
Added important note about using url() on older versions of django, but switched the examples to re_path as to comply with Django docs for 2.0 and later.
Currently queries executed in the hooks don't run in the transaction
with the page deletion query and it's harder to write hook without
copying the whole view if you want to keep queries running in the hooks
integral with page deletion.
According to a google search I just did, it seems a lot of people have forgotten to add ``Disallow: /admin`` in their robots.txt (or forgot to add robots.txt) at all.
Adding this meta tag into the head of all admin pages should prevent any admin pages being indexed even if this was missed.
The behaviour of `has_usable_password` has changed in Django 2.1, such that `None` is no longer considered a 'non-usable' password: https://docs.djangoproject.com/en/2.1/ref/contrib/auth/#django.contrib.auth.models.User.has_usable_password
As a consequence of the fix applied in Django https://code.djangoproject.com/ticket/28718 , Wagtail users created without a password will now be able to complete the password reset process to gain access to Wagtail. Sites that do not want this behaviour (e.g. because those users should be using an LDAP login instead) should disable password changes via WAGTAIL_PASSWORD_MANAGEMENT_ENABLED and WAGTAIL_PASSWORD_RESET_ENABLED.
* Update integrating_into_django.rst
flaw in url, was still referencing depreciated method, fixed.
* Update integrating_into_django.rst
Add important notice that versions of Django earlier than 2.0 require url() instead of re_path()
By optionally passing the request object to Page.get_sitemap_urls() it
will now use the cached site root on the request object instead of
retrieving it for each call. This cuts the number of queries required
for a sitemap roughly in half.
After migrating a Wagtail-based site from MySQL to Postgres, we
noticed that malicious requests to the site that included percent-
encoded Unicode NULLs (`%00`) raised a `ValueError` exception that we
hadn't seen when using MySQL: `A string literal cannot contain NUL
(0x00) characters.` This appears to relate to `psycopg2`'s decision to
raise an exception in these situations, as discussed here:
https://github.com/psycopg/psycopg2/issues/420
While newer versions of Django appear to provide some field validation
that addresses these characters, it doesn't look like Wagtail's
redirect middleware is making use of those validators, and so it seemed
reasonable to clean these characters in the context of 'normalizing'
the paths before looking for corresponding redirects -- especially
since a quick investigation on the internet suggests that U+0000 in
URLs can be used as a means of attack, and also since RFC 3986 says:
Note, however, that the "%00" percent-encoding (NUL) may require
special handling and should be rejected if the application is not
expecting to receive raw data within a component.
Fixes #4424. As of #3354, `get_url` is the preferred way of obtaining a page URL, rather than the `.url` property;
.url is just a wrapper around get_url (which meant that the docstring for `get_url` was erroneously being picked up).
We currently index all items in Elasticsearch using the root bulk api
(at ``/_bulk``). This API is to allow multiple indices to be inserted
into at once. However, Wagtail inserts into one index at a time so this
is not needed. If we pass the index name as a parameter in the call to
``bulk()``, the index-specific bulk API will be used instead (at
``/<index name>/_bulk``.
The advantage of this change is it makes it possible to implement access
control by checking the URL an application is using. This is required in
order for the Bulk API to work on certain hosts (such as Divio).
* Expose Draftail package as global variable for reuse
* Expose Wagtail React components for reuse
* Expose Draftail-related React components for reuse
This change prevents non-admins from navigating around the Wagtail page
tree for pages that lie outside of their explorable root. Currently,
non-admins can hit any page in the tree using a URL like
/admin/pages/123/
even if they don't have any permissions over that page or its part of
the page tree.
This change adds a (temporary) redirect to requests like this, so that
users may not navigate to parts of the tree that lie outside outside of
their explorable site root, as determined by the page privileges they
have. If they try to hit a URL like the one above, they get redirected
to their explorable site root navigation page instead.
Relevant unit tests have been modified to incorporate this change.
This change modifies how the Wagtail home site summary panel displays
the number of pages on the site, and where that number links to.
Instead of showing the total number of pages on the site, the panel
should show the number of pages under the user's explorable root page
(inclusive). If the user has access to the full tree, the Wagtail root
is not counted in this total.
Previously, the site summary page link would go to the Wagtail root if
there were multiple sites in an installation, and to the site root page
for a single site. This change modifies this logic so that the link
always goes to the user's explorable root page (which may be their
explorable root page).
The unit tests for the site summary panel have been pulled out into a
new module at `wagtail.admin.tests.test_site_summary`, and augmented to
test how things work for users with different permissions.
This implements a new "find" view for all endpoints which can be used
for finding an individual object based on the URL parameters passed to
it.
If an object is found, the view will return a ``302`` redirect to detail
page of that object. If not, the view will return a ``404`` response.
For the pages endpoint, I've added a ``html_path`` parameter to this
view, this allows finding a page by its path on the site.
For example a GET request to ``/api/v2/pages/find/?html_path=/`` will
always generate a 302 response to the detail view of the homepage. This
uses Wagtail's internal routing mechanism so routable pages are
supported as well.
Fixes #4154
Searching the docs for the phrases "add django model to wagtail admin" and "add model to wagtail admin" (without the quotes) did not even yield this crucial page as one of the results. The proposed wording puts the main idea of being able to show/edit ANY model via the Wagtail admin at the top of the document and includes wording to, hopefully, have this page appear at the top for anyone searching for how to implement this functionality.
* Add a new hook 'register_account_menu_item'
This new hook makes it easier for third party apps to add new buttons on
the 'my account' page in the Wagtail admin. Existing buttons are
converted to the new hooks to make the code consistent.
* Add documentation for the new register_account_menu_item hook
