No human being reads this site's sitemap.xml. It exists entirely for crawlers, gets zero direct visits worth counting, and if it silently broke tomorrow the only symptom would be a slow decline in indexing over weeks, with nothing in the site's own analytics pointing at the cause.
This site runs on a VPS that also runs two other things I don't think about most days: carmen-crm.net and fasterwebsites.net, neither of which has anything to do with linkhub.
The composer.json diff for the Drupal 10 to 11 upgrade on this site is thirteen lines: a handful of version constraints bumped, doctrine/annotations added back, symfony/runtime allow-listed. The composer.lock diff for that same commit is 2,109 lines changed — 1,416 insertions, 693 deletions, one file.
Composer has a specific way of telling you a package is a bad long-term bet: when a dependency is marked abandoned on Packagist, the lock file itself records "abandoned": true against that package's entry, and every install or update that touches it prints a warning.
There's a specific kind of unhelpful a 403 can be. Try to set a field you don't have permission for through Drupal's JSON:API and you get a real, actionable message back — something like "The current user is not allowed to POST the selected field (status). The 'administer nodes' permission is required." That's a 403 that tells you exactly what to go fix.
Somewhere in the middle of upgrading this site from Drupal 10 to 11, composer require drupal/core-recommended:^11 stopped and refused to install anything at all, not because of a version conflict this time, but because one of the packages it needed to pull in, symfony/runtime, ships a Composer plugin, and Composer plugins don't get to run just because they're in the de
Every Drupal config entity has a machine name and a UUID, and it's easy to go a long time treating the machine name as the entity's actual identity, because it's the one you type — id: api_publisher, right there at the top of the YAML file, human-readable and stable. The UUID sits a couple of lines above it, a string nobody reads, that looks like it shouldn't matter.
Drupal has two separate ideas of whether a module exists, and, unless something actively keeps them in sync, they're allowed to disagree with each other. One lives in core.extension config: is the module marked installed, does the database have its schema, does anything still reference its config objects.
Deploying the removal of a Drupal module looks like it has an obvious order: take the module out. In practice it's two separate operations that happen to both look like "removing a module" from the outside, and doing them in the wrong order left production in a broken half-state I had to clean up by hand.
Every guide to composer.lock tells you the same thing: commit it, and every environment that runs composer install against it gets identical dependency versions. That's true as far as it goes.