phenaproxima

I fucking hate reviewing AI-generated bullshit.

Reviewing code was never my favorite activity. It's slow, it's painstaking, it's cognitively taxing. It's pretty much a given that reading code is always slower, and less fun, than writing it.

So why would I ever do it? Because it's a collaborative process. I read your code, then ask questions and offer suggestions. We talk about them, we implement some things and not others. Together, we find our way and sculpt a patch we like. It's sociable, it's gratifying, and we get to share the satisfaction of co-creation. And it's based (ideally) on trust and respect: you did this work, and I would like to help you make it as good as it can be. Your success becomes my success.

If you're a person, that is.

If I have to review AI-generated code, or AI-generated writing for that matter, all of this flies out the window. I don't feel like a co-creator; I feel like I have to clean up a bag of dogshit left at my door. Anything good about the review process evaporate

phenaproxima

Recipe Dojo: config files vs. config actions

Recipes have two ways to affect site configuration:

1. They can have a config directory containing YAML files, like you'd find in a config/install directory or config export.
2. They can use config actions in their recipe.yml.

These techniques have different purposes and generally aren't interchangeable, but it's not always obvious which one to use. Well, I'm going to compare and contrast them, hopefully giving you a few rules of thumb.

Let's start with this:

phenaproxima

diff --git a/core/core.services.yml b/core/core.services.yml
index 31b7a5b6aa5..0704a1ff8fd 100644
--- a/core/core.services.yml
+++ b/core/core.services.yml
@@ -76,6 +76,10 @@ services:
     arguments: ['@config.manager', '@config.storage', '@config.typed', '@config.factory']
   Drupal\Core\DefaultContent\Importer:
     autowire: true
+  Drupal\Core\DefaultContent\Exporter:
+    autowire: true

phenaproxima

Let's learn a little bit about how Project Browser works.

You can trust me. Together with @chrisfromredfin, @tim.plunkett, and a lot of other contributors, I have spent the better part of the last year refactoring, rearchitecting, and rewriting most of Project Browser, to try and lift it out of its proof-of-concept roots and turn it into a modernized extension browsing and installation system for Drupal. This, then, is a tour of Project Browser from a developer's perspective.

The thing you need to know about Project Browser is that, despite being a decoupled app, it has no JavaScript API at all. The UI, which is written in Svelte, is completely and totally locked down and cannot be extended. What API surface it has is entirely on the PHP side. So let's talk about what those parts are.

The Project class

The most important class in Project Browser is Project. It is a value object that represents a single project that you can see in the UI. Project Browser takes a pretty expansive definition of what

phenaproxima

This documentation was merged into Experience Builder Drupal Canvas! It now lives at https://git.drupalcode.org/project/canvas/-/blob/1.x/docs/intro.md?ref_type=heads

phenaproxima

<?php

use Drupal\Core\Batch\BatchBuilder;
use Drupal\Core\Recipe\Recipe;
use Drupal\Core\Recipe\RecipeRunner;

// There are two ways to apply a recipe programmatically: immediately, or as a batch job.
// The batch job is generally the safer option, since more complex recipes could risk
// timing out if they try to do too much at once.

phenaproxima

//
// This ipsum generator is adapted from code at
// https://hackernoon.com/creating-a-lorem-ipsum-generator-with-node-and-express-9e1af0b31c86
//
// Tamarian phrases from http://memory-alpha.wikia.com/wiki/Tamarian_language
//
class DarmokIpsum
{
    constructor ()
    {