atendesigngroup/drupal-kickstart

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

A starter install of an Aten Design Group Drupal website.

11.x-dev 2024-09-03 21:19 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

Starter repo for a Drupal website.

Getting Started

To start a new Drupal project, run the following command:

composer create-project atendesigngroup/drupal-kickstart

Development Workflow

Projects built using this starter project make a number of assumptions. First that the project codebase is hosted on Github. This allows leveraging of Github Actions for deployments to various remote hosting environments.

For all projects in active development, Pantheon hosting is assumed at least to start. This allows developers to leverage Pantheon's free sandbox and multidev environments. Additional hosting providers can be configured by updating Github Actions deployment scripts.

Branches prefixed with feature/ will get a new multidev environment created when a new PR is opened against the main branch. Sequential pushes to that branch will update the multidev environment. Closing the PR will destroy the multidev environment.

Patches

Composer based websites should use the composer-patches plugin. This allows for patches to be applied every time composer install is ran. To keep things clean, all patches should live in an external composer.patches.json file and not within the main composer.json file.

Best practice should be that patches are contributed back to their associated Drupal project and referenced by with the issue number. For example:

"drupal/core": {
  "#12345: Short description...": "https://www.drupal.org/path/to/file.patch",
}

In rare cases where a local patch is needed, keep the .patch or .diff file in the repo's /patches folder.

Scaffold Development Instructions

To add or update packages to this base install, pass the --no-update flag into the composer require or composer update commands. This will ensure no package.json file is created and dependencies are not installed.

There a series of scripts for testing updates to the installer:

• composer test:ak-installer: Runs a test install. Places files on the Desktop.
• composer cleanup:ak-installer: Removes the installed directory. Gets ran before new installs.