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
| // | |
| // 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 () | |
| { |
| <?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. |
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 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
| 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 |
Recipes have two ways to affect site configuration:
- They can have a
configdirectory containing YAML files, like you'd find in aconfig/installdirectory or config export. - 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: