I upgraded this site from Drupal 10 to Drupal 11. The Drupal part went fine, eventually. What actually took the site down for four minutes had nothing to do with Drupal at all — it was a missing setgid bit, and I only found it because I've learned not to trust a Drupal error log to tell me the whole story.
Most guides to enabling REST or JSON:API in Drupal tell you to go to /admin/config/services, tick some checkboxes, and save. That's fine advice for a one-off experiment, and terrible advice for anything you intend to depend on.
If you have ever wondered why Doctrine entities cannot be final, this is the article that answers it. And the answer stops being true in PHP 8.4.
This is the largest change in the Symfony 8 and Doctrine 4 move, and it is not really a framework change at all. It is a PHP language feature removing the need for a fifteen-year-old workaround.
You run Rector. It rewrites every docblock into an attribute. The diff looks perfect. You commit, deploy, and your entities are no longer recognised at all.
Symfony 6.4 stops receiving bug fixes in November 2026. Security fixes continue for another year, until November 2027, but after that the version is done.
If you are on 6.4, this is your window. And the good news is that the upgrade is much less work than the version numbers suggest, provided you understand what Symfony is actually asking you to do.
Drupal ships a sensible robots.txt. It blocks the admin paths, the login and registration forms, the search pages, and the node creation forms. For a single-language site it does the job.
I run a site in Danish and Swedish. On that site, almost none of those rules do anything.
Both tools do the same job. You describe how a machine should be configured, you keep that description in version control, and the tool makes the machine match. Most of what you learned from Puppet still applies.
I have two servers and one OpenSearch node. The obvious move is to put a node on the second server and call it a cluster.
That works, and it is worth doing. But it does not give you high availability, and the reason is counterintuitive enough that a lot of people find out during their first outage. So this article covers the setup and the limitation together.
My robots.txt blocks nothing. Every page carries a meta robots tag permitting indexing. Google crawls the site happily and indexes almost everything within a few days of publication.
And when an AI assistant tried to read one of my articles, it was refused.
Every example IP in the previous article was 203.0.113.10. That is not a number I invented, and it is not a real server. It comes from TEST-NET-3, one of three IPv4 ranges the IETF reserved specifically so that technical writers have addresses they can safely put in front of readers.