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.
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.
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.
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
I'd like to propose removing the shims for IE6-9 from the project template.
The rationale for this is the same as for dropping support for EOL version of Django, etc. - i.e., these versions of Internet Explorer are no longer supported by the vendor (the last version of Windows that you cannot upgrade to use IE10 or higher was Windows XP, which reached end of life in 2014).
On that basis I think that Wagtail should not include these shims by default - projects that for whatever reason still need to support these browsers can easily add them to their templates.
