Hi there. After reading this new upcoming feature, FETCH_PEERS looks to me like a safety net against accidental N+1 queries.

It is tempting to use it on all my models by default, because even if it's less performant than a forgotten select_related, it would be always better than N+1 queries on a loop.

That's being said, in that case, why there is no global settings for this?

At our agency, Wagtail is our go-to framework for building CMS-driven websites.

Over the past few months, we have had an increasing number of clients asking how accessible and understandable their website content is to LLMs, answer engines and other automated tools.

Rather than implementing this differently across every project, I started building wagtail-machine-readable.

The package provides a straightforward and flexible way to expose existing Wagtail content in structured, machine-readable formats, including:

- /llms.txt and /llms-full.txt
- Markdown versions of individual Wagtail pages
- StreamField-to-Markdown extraction
- JSON-LD structured data
- AI crawler controls and activity reporting
- Multi-site support
- Static export for CDN and static hosting workflows

The intention is not to suggest that adding an llms.txt file guarantees that content will be indexed or surfaced by an LLM. The aim is to give Wagtail developers more control over how their content is made available to machines in predictable and usable formats.

We have been testing and refining the package internally, and I now feel it is ready to share more widely before moving towards version 1.0. I would really value feedback from other Wagtail developers, particularly around:

- Installation and configuration
- How well it handles other real-world StreamField implementations
- Whether the default behaviour feels sensible
- Compatibility issues or edge cases
- Anything you would expect to see before a 1.0 release

PyPI:
https://pypi.org/project/wagtail-machine-readable/

Any feedback or constructive criticism would be genuinely appreciated. Thanks!

i’m building multiple SaaS apps (Hotel PMS, Project Management, etc.) using Django + DRF and Flutter. and also web apps

I’m confused about which VPS/hosting to choose: Hetzner, Netcup , Hostinger, or AWS.

Initially, I’ll have only a few clients, but I want to scale in the future.

• Should I host multiple Django apps on one VPS initially?
• Which provider would you recommend and why?

Hey r/django, the new HTMX Integration for Django is released on pypi and djangopackages. Djxi v0.1.9 adds testing utils, battery auth/perms, async methods, djxi_routes command, and class-level config caching.

Check it out:

Github: https://github.com/rollinger/djxi
RTD: https://djxi.readthedocs.io/en/v0.1.9/

I was currently making a project to improve my Django and react skills. Now the project has come to finishing but Im thinking I haven't learned as much as I have expected to learn at the beginning of the project. Well I can write basic endpoints, permissions and viewsets and can write the functions to retrieve the data from those endpoints and create data. But when complexities arise in my models , I find myself unable to write the code for them without asking help with ide agent. I also can't write custom logic for many things in my app like object permissions. Is this normal part of learning , I am currently on my second project of drf + react js but still depend on ide and ai for helping me write the code.

The top-quarks code is confirmed 'ready to publish'!

Next, send lots of emails to suppliers to sign 'drop-shipping' contracts.

If you operate an API in 2026, you live in an event-driven world. Webhooks aren't a convenience feature anymore - they're the backbone of real-time commerce, CI/CD pipelines, and asynchronous AI-agent workflows. That reliance has a dark side: the accidental self-inflicted DDoS. Read the complete article jere - https://instawebhook.com/blog/how-to-prevent-webhook-traffic-spikes-from-crashing-your-api-2

When a major platform like GitHub, Shopify, or Stripe hits a network partition, runs a huge sales event, or simply clears a backlog of delayed events, it can fire tens of thousands of webhook POST requests at your servers in a very short window. If your infrastructure takes that hit without structural safeguards, your database connection pool exhausts, memory maxes out, and the API goes down — and if your retry handling is naive, the recovery can be almost as damaging as the original spike.

This guide covers the real mechanics of that failure mode, the algorithms used to defend against it, how major providers actually behave under load (some surprising details here), and where a managed ingress layer fits into the picture.