atendesigngroup/drupal-kickstart

There is no license information available for the latest version (11.x-dev) of this package.

Drupal 11 kickstart project — managed by drupal-kickstart.sh.

11.x-dev 2024-09-23 17:11 UTC

Requires

• composer/installers: ^2.3
• cweagans/composer-patches: ^1.7
• drupal/admin_toolbar: ^3.5
• drupal/core-composer-scaffold: ^11
• drupal/core-project-message: ^11
• drupal/core-recommended: ^11
• drupal/editoria11y: ^2.1
• drupal/environment_indicator: ^4.0
• drupal/gin: ^3.0@RC
• drupal/gin_toolbar: ^1.0@RC
• drupal/google_tag: ^2.0
• drupal/metatag: ^2.0
• drupal/pathauto: ^1.13
• drupal/redirect: ^1.10
• drupal/tab_toolbar: ^1.0
• drupal/twig_field_value: ^2.0
• drupal/twig_tweak: ^3.4
• drupal/ultimate_cron: ^2.0@alpha
• drupal/view_unpublished: ^1.3
• drush/drush: ^13.0
• pantheon-systems/drupal-integrations: ^10.0

Requires (Dev)

• drupal/coder: ^8.3
• drupal/core-dev: ^11
• drupal/devel: ^5.3
• drupal/stage_file_proxy: ^3.1

Conflicts

• drupal/drupal: *

Unknown License

• James Nettik

README

• Production URL: https://atendesigngroup.com/
• Aten Shortname: PROJECTCODE

Project Setup

See docs for details on project setup, including:

• Drupal Kickstart
• Grumphp

Overview

Description of project intention & goals.

People & Roles in Project

Aten

• Jack Reacher (Project Manager)
• James Bond (Tech Lead)
• Jason Bourne (Developer)

Communication

• Slack: #client-PROJECTCODE
• JIRA: https://atendesign.atlassian.net/jira/software/projects/PROJECTCODE/

Code Repository

• Host: Pantheon/Platform.sh/Acquia
• Repo Name: Project Name
• Development URL: https://example.com/
• Repo URL: https://example.com/
• Default Branch: master
• Owner: Aten/Client

Hosting

Production

• Provider: Pantheon/Acquia
• Owner: Aten/Client

Automated Testing

No testing:

• This project does not currently have automated testing configured.

Has testing:

• This project has automated testing configured.
• Type of testing: Cypress (https://www.cypress.io/)
• Location to READ.ME: web/...

Theme Information

• Base Theme: Prototype
• Custom Theme: THEME_NAME
• Location to READ.ME: web/themes/custom/THEME_NAME/README.md

Development Workflow

When adding new features to the project, you'll need to create a feature branch, which is commonly named after the Jira ticket number (e.g., JIRA-XXX). You will commit all your code changes to this feature branch and push the branch to the code repository. Once the ticket is ready for QA, it should be merged into the main branch, which will then be deployed to the development instance on the hosting platform.

Assign the Jira ticket to a QA team member, provide the link to the development environment, and include instructions on what needs to be tested. Additionally, please ensure that you set up the environment with dummy data to verify that it's functioning correctly before involving the QA team.

Deployment

When code is pushed to GitHub, an automated process using GitHub Actions deploys the site to the development environment on Pantheon. Production deployments are still conducted manually and must follow the Pantheon workflow, as they need to go through Test and then Live. When working on an isolated feature that you want to test independently, you can create a feature branch using the following naming convention for your branch (feature/[JIRA-ISSUE]). When you push the feature branch to GitHub, it will create a Multi-dev environment based on that code; the development database will be used when creating the Multi-dev environment.

Local Development

The Drupal project was configured to support DDev out of the box. Developers can quickly begin setting up their local environment by following the instructions below. Please ensure that you've installed DDev.

First, let's start by installing the project's composer packages:

composer install

Now, you'll need to start up the local instance:

ddev start

Now, you'll need to import the development database to the local environment:

ddev import-db local.database.sql.gz

Drush aliases are also available. To sync the DB from any Pantheon environment to your local run:

ddev drush sql-sync @lapl.[ENVIRONMENT_ID] @self

If you get an error around pubkeys, run ddev auth ssh and try again.

1. Get your Pantheon.io machine token: a. Login to your Pantheon Dashboard, and Generate a Machine Token for ddev to use. b. Add the API token to the web_environment section in your global ddev configuration at ~/.ddev/global_config.yaml

yaml
  web_environment:
    - TERMINUS_MACHINE_TOKEN=abcdeyourtoken

1. ddev pull pantheon
2. You can append --skip-files or --skip-db to the ddev pull pantheon command to skip files or database import respectively.

Branch Structure & Sync Workflow

This repository uses two long-lived branches with distinct roles:

Branch	Purpose
11.0.x	Starter template — the clean, reusable project scaffold. Contains recipes, assets, DDEV commands, and tooling config with DK_* token placeholders.
dk-start-build	Built project — a real Drupal installation created by running drupal-kickstart.sh. Contains the full Drupal codebase (web/, vendor/, composer.json, config/sync/).

How the sync works

When starter-scoped files are changed on dk-start-build and pushed, a GitHub Action automatically opens a PR against 11.0.x containing only those files.

Files that sync back to 11.0.x:

• recipes/ — Drupal recipes (formulas)
• assets/ — settings templates, Pantheon assets
• .ddev/commands/ — custom DDEV commands
• drupal-kickstart.sh — the project setup script
• composer.custom.json, composer.patches.json — Composer configuration
• grumphp.yml, phpcs.xml, phpunit.xml, eslint.config.js — tooling config
• docs/, AGENTS.md, README.md

Files that never sync (build artifacts):

• composer.json, composer.lock — generated by drupal-kickstart.sh
• web/ — Drupal core, contrib modules, and themes
• vendor/ — Composer vendor directory
• config/sync/ — exported Drupal configuration
• pantheon.yml, private/, .env, .kickstart.env

Token reversal

drupal-kickstart.sh replaces DK_* placeholders with real project values during the build (e.g. DK_COMMIT_PREFIX → GRE). The sync workflow reverses this automatically before opening the PR, so 11.0.x always contains the original placeholders — never project-specific values.

Token values are stored as GitHub repository variables (Settings → Secrets and variables → Actions → Variables):

Variable	Description	Example
DK_DDEV_NAME	DDEV project name	my-client-site
DK_THEME_NAME	Theme machine name	my_theme
DK_THEME_DESC	Theme display name	My Theme
DK_COMMIT_PREFIX	Commit prefix used in this build	GRE
DK_PHP_VERSION	PHP version	8.3

Triggering a sync manually

Go to Actions → "Sync build → 11.0.x" → Run workflow (select branch dk-start-build). Useful when the automatic push trigger didn't fire or you want to re-sync after updating the repository variables.

Theme Development

Powered by some of the latest and greatest tools, this package streamlines theme development.

Install the required npm packages:

ddev theme-install

That's it for installs! You can start developing by running:

ddev theme-watch

To compile your build files, stop watching and run:

ddev theme-build

Known Issues: drupal/prototype Starterkit

Upstream bugs in drupal/prototype affecting Drupal 11. Patches in composer.patches.json apply automatically on composer install.

1. SDC strict null validation breaks optional props

Problem/Motivation: Drupal 11's ComponentValidator rejects null for bare types (type: string, type: array). Prototype component schemas use bare types for optional props, so leaving any optional field empty causes InvalidComponentException: NULL value found, but a string is required and breaks page rendering.

Steps to reproduce:

1. Create a paragraph of type CTA, Pullquote, Slideshow, Teaser, or Video.
2. Leave at least one optional field (title, caption, link, etc.) blank.
3. View the node — the page throws an InvalidComponentException.

Proposed resolution: patches/prototype-sdc-null-safety.patch — converts bare types to type: ['string', 'null'] and removes required arrays from optional props.

2. slideshow.twig — 'type': loop resolves to null

Problem/Motivation: The default Splide config in slideshow.twig uses the bare word loop as a value ('type': loop). Outside a {% for %} block, loop is undefined in Twig and evaluates to null, producing data-splide='{"type":null}'. Splide fails to initialize and the carousel does not function.

Steps to reproduce:

1. Add a Slideshow paragraph with at least one slide.
2. Do not pass an explicit options.type from the bridge template.
3. Inspect the rendered HTML — data-splide contains "type":null and the carousel is broken.

Proposed resolution: patches/prototype-sdc-null-safety.patch — changes 'type': loop to 'type': 'loop'.

3. Starterkit.php — class name casing breaks theme generation on Linux

Problem/Motivation: Drupal's GenerateTheme command looks for Drupal\prototype\StarterKit (capital K), but the file is named Starterkit.php (lowercase k). On Linux's case-sensitive filesystem (including inside DDEV), PSR-4 autoloading silently skips postProcess(), leaving the tests/ directory in the generated theme. Template discovery then picks up test templates over the real bridge templates, breaking paragraph rendering.

Steps to reproduce:

1. Run ddev exec php web/themes/contrib/prototype/generator.php -n my_theme -d "My Theme" -p web/themes/custom — must run via ddev exec to use the Linux container filesystem where case-sensitivity applies.
2. Inspect web/themes/custom/my_theme/ — the tests/ directory is present.
3. Enable the theme, add a Slideshow paragraph to a node — the test template renders instead of the real bridge template.

Proposed resolution: patches/prototype-starterkit-class-name-change.patch — renames src/Starterkit.php to src/StarterKit.php, updates the class declaration, and corrects the .starterkit.yml ignore patterns.