Wagtail VS django-debug-toolbar

If you like Python 🐍 then check out this project. Wagtail is a popular CMS, combining Django’s powerful customization capabilities with a slick user interface. The newest update brings Django 5.0 support, a new searchable and filterable listing UI, the accessibility checker built into the admin interface, and a brand new 10-step tutorial for developers. This release marks Wagtail's 10th birthday 🎂. Happy birthday to the team and all the best for the next ten years and beyond 🥳.

Repo : https://github.com/wagtail/wagtail

- The discussion thread we use to track all public feedback: https://github.com/wagtail/wagtail/discussions/9553. Comments very welcome.

Not so long ago, I submitted a Pull Request in wagtail to improve the admin performance, especially for non-superusers. Basically, it caches all the user's permissions on first access. However, I was pretty sure that this would load a lot of model fields that we never need but there isn't a tool that gives us that type of report. Therefore, I started building an app that keeps track of all fields accessed so you can easily know which ones haven't been used and apply the only/defer optimisation for Django querysets.

Wagtail would be a good example https://github.com/wagtail/wagtail/tree/main/wagtail/tests

Paarth moving from no contributions to the 21st most contributions - https://github.com/wagtail/wagtail/graphs/contributors.

Over the last few years, I have had the incredible opportunity to be a core team member of the Wagtail project. In that time, I have reviewed many new pull requests, and I’ve also had the chance to submit many of my own across Wagtail and many other projects.

Wagtail 2.15 is the most recent LTS (Long Term Support) release, so it’s not a bad release to stick to at all, at least until February 2023.

The reason behind this splitting is that we can safely use packages and related settings only where we need. For example, this starter kit has the package django-debug-toolbar. This is only intended for your development environment and not for your production. This can be very risky if used in production because if your Django project encounters errors, all the debug info will be shown to the user which is a severe security risk. Similarly, for tracking errors in production, we're using Sentry which is not needed in our local environment since we already have django-debug-toolbar. For keeping these settings file separate so that they don't conflict with each other, the settings file is split for serving different environments.

django-debug-toolbar: https://github.com/jazzband/django-debug-toolbar

https://github.com/jazzband/django-debug-toolbar/issues?q=is%3Aopen+is%3Aissue+label%3ABug

https://github.com/jazzband/django-debug-toolbar Allows you to check which sql queries are being run on your app. See if they are optimized first.

Perhaps try the django-debug-toolbar. It might be able to tell you what is causing the slow load time.

I would start with https://github.com/jazzband/django-debug-toolbar and figure out what causes the slowness.

-> The debugging above from django-debug-toolbar

Documentation, including installation and configuration instructions, is available at https://django-debug-toolbar.readthedocs.io/.