{"id":15061377,"url":"https://github.com/WPP-Public/Drupal-KIT","last_synced_at":"2025-10-31T12:30:23.072Z","repository":{"id":38237129,"uuid":"146511913","full_name":"VMLYR/Drupal-KIT","owner":"VMLYR","description":"VMLY\u0026R's Drupal  KIT is a project scaffold distribution which helps build and maintain Drupal projects.","archived":false,"fork":false,"pushed_at":"2024-04-06T01:08:04.000Z","size":16883,"stargazers_count":18,"open_issues_count":8,"forks_count":13,"subscribers_count":10,"default_branch":"9.x-1.x","last_synced_at":"2024-10-12T21:25:43.924Z","etag":null,"topics":["composer","drupal","vmlyrna"],"latest_commit_sha":null,"homepage":"","language":"PHP","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"gpl-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/VMLYR.png","metadata":{"files":{"readme":"readme.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null}},"created_at":"2018-08-28T22:05:30.000Z","updated_at":"2023-03-21T17:47:57.000Z","dependencies_parsed_at":"2023-01-23T09:16:16.168Z","dependency_job_id":"199363d1-c38a-4be9-8fbb-90b224c4e154","html_url":"https://github.com/VMLYR/Drupal-KIT","commit_stats":{"total_commits":112,"total_committers":14,"mean_commits":8.0,"dds":0.7589285714285714,"last_synced_commit":"c3ddb2f3ea3ad2d6469050975d7ce4cb5fa863d2"},"previous_names":["vml/drupal-kit"],"tags_count":40,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/VMLYR%2FDrupal-KIT","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/VMLYR%2FDrupal-KIT/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/VMLYR%2FDrupal-KIT/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/VMLYR%2FDrupal-KIT/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/VMLYR","download_url":"https://codeload.github.com/VMLYR/Drupal-KIT/tar.gz/refs/heads/9.x-1.x","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":219855652,"owners_count":16556160,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["composer","drupal","vmlyrna"],"created_at":"2024-09-24T23:18:56.246Z","updated_at":"2025-10-31T12:30:23.030Z","avatar_url":"https://github.com/VMLYR.png","language":"PHP","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Drupal 9 KIT\n\nVMLY\u0026R's Drupal 9 KIT is a distribution which helps build and maintain\nDrupal 9 projects.\n\n* [About KIT](#about-kit)\n* [Getting Started](#installation)\n* [Post-installation and provider-related configuration](#post-installation-and-provider-related-configuration)\n* [Notes \u0026 Suggestions](#notes-and-suggestions)\n* [Theme Development](#theme-development)\n\n\n\n## About KIT\n\nVia a suite of Docksal commands, an installation\nprofile, and a base theme, the distribution provides support\nfor the following:\n * [Common modules](#common-modules-+-_composer.json_)\n * [Composer project scaffolding](#composer-project-scaffolding)\n * [Docksal command suite](#docksal-command-suite)\n * [Using Docksal for CI and build processes](#docksal-+-ci-and-build-processes)\n * [Drupal site configuration](#drupal-site-configuration)\n * [Multi-environment configuration and development](#multi-environment-configuration-and-development)\n * [Multi-site configuration and development](#multi-site-support)\n * [Standardized theme management and structure](#standardized-theme-management-and-structure)\n\n### Common modules + _composer.json_\n\nKIT uses composer for handling project dependencies. The distribution\nincludes a selection of Modules and libraries by default. The list was\ndetermined using either the following criteria:\n - *Best-practices* – Drupal 9 Core is a much more viable product\n out-of-the-box than Drupal 7 was, but there are still certain modules\n and configuration that we need and should be using for every site,\n including support for multiple environments. Examples of these are\n Blazy for lazy-loading images, Advanced Aggregation for better\n style/script management, Configuration Sync + Config Split (instead of\n Features).\n - *Standardization* – being an open-source project, Drupal has a tendency\n  of having multiple modules with similar solutions to similar problems.\n  We've added items to the list by default to help standardize the tools\n  to handle certain problems, an example being a field to include a view\n  on an entity.\n\n### Composer project scaffolding\nKIT enforces structure by adding it's own scaffolding, which runs after\nDrupal's default scaffolding on composer install and update. Drupal's\nscaffolding automatically wipes and re-copies the files which get copied\noutside of Drupal core and into public directories\n(like default.settings.php, htaccess, robots.txt, etc.). VMLY\u0026R\nadditionally creates the standard config folder structure, as well as\nremoves and updates files that should be modified via patches\n(like .htaccess) or compiled (like drupal.settings.additional.php\ncompiling into drupal.settings.php) instead of being checked-into the\nrepository directly.\n\n### Docksal command suite\nThe project uses [Docksal](https://docksal.io/) for local-environment\ndevelopment and project-building. The following is a list of Docksal\ncommands that come included in the project:\n - `init` – Typically used when building or rebuilding the project\n and its dependencies. The command will start docksal, download\n dependencies, make sure that the project's relevant sites' directories\n and databases exits, build front-end artifacts, and import databases\n from another environment. The command takes an optional parameter\n `builder`, which is explained in detail below under the\n \"Docksal + CI and build processes\" section.\n - `init-deps` – Used when project dependencies need to be redownloaded \n and installed. Currently consists of Composer and NPM.\n - `init-services` – Used when project-based command and tool dependencies\n need to be redownloaded and installed. Currently consists of validating \n that nvm, npm, and node are available in the container.\n - `k` – A simple wrapper command to make it easier to run kit commands.\n For example, `fin k gulp` instead of `fin kit/gulp`.\n - `pre-deploy` – This is used in situations where there needs to be \n pre-deployment cleanup / modifications. Currently used to remove files \n from build artifact that don't need to be on an external environment.\n\nAdditional commands are included via the `vmlyr-drupal/kit-docksal-commands`\npackage and installed under a \"kit\" sub directory in the docksal commands\ndirectory. See the README.md file in that directory after composer is\ninstalled for more information on those commands.\n\n### Docksal + CI and build processes\n\nDocksal and KIT's commands can be used for running build processes. The\ncommand `init` can toggle \"CI mode\" by running appending the\n`ci` command: `fin init ci`. This is best used when\ndocksal is used to create the build files to be released. By default,\nthe builder runs composer in --no-dev mode, and auto-removes\nbuild-related files amound other things.\n\n### Drupal site configuration\nThis composer project comes with 2 VMLY\u0026R-created Drupal profiles:\n - _Biplane_ – This profile has a lot of required site-configuration and\n relevant modules installed and setup by default. It's fairly bare-bones\n besides items related to best-practices and standardization, but it\n does take care of a lot of monotony that comes with installing a new\n Drupal instance. Some examples are:\n   - Default environments (local, remote_dev, remote_stage, remote_prod)\n   and their relevant config-splits and settings and modules.\n   - Core files modified/removed by default, like .htaccess _https_\n   overrides, default settings.php changes, using RobotsTXT module\n   instead of the included core file, etc.\n   - Lighthouse-related settings, like Image Optimization, Responsive\n   Images + Focal Point, Advanced Aggregation, Blazy, etc.\n   - Various settings and needed for go-live on new sites, like setting\n   up Advanced Aggregation for production instances, default metatags\n   for global and Node pages, XML Sitemap defaults, disabling anonymous\n   user registration, etc.\n - _Blackbird_ – This profile builds off of the _Biplane_ profile, but is\n a little more opinionated. It includes helpful Paragraph components,\n Image Styles, Media implementations, among a slew of additional\n configuration. To get the full use of the additional components, make\n sure to run `fin kit/theme` and generate a new theme off of the \n \"Blackbird\" option of the same name.\n\n### Multi-environment configuration and development\n\nMulti-environment configuration is pre-configured as part of the\ndistribution via the default `settings.php` file and the _Biplane_ and _Blackbird_ profiles.\n\n#### Environments + _Settings.php_ file\nThe each site's default `settings.php file` includes the\n`/sites/environment.settings.php`, which has configuration to toggle the\nstatus of relevant configuration based on the current site's\nenvironment. Remote environments, such as those hosted by Acquia,\nPantheon, or Platform.sh, have `$_ENV` or `$_SERVER` variables which\ntell the site that it is a certain environment and to enable certain\nconfiguration or settings. When working on the site locally, all\nconfiguration splits should say either \"inactive\". The \"local\"\nconfig_split status is only enabled by the fin command `conf` on\nexport/import. This makes sure that configuration can be exported\nregularly without a certain environment taking accidental precedence.\n\nDevelopment and docksal settings files are automatically included via\nthe `environment.settings.php` file, if they exist. These files are\nignored by git and helpful for development overrides such as disabling\ncache or allowing verbose error reporting. The KitScriptHandler script,\nwhich is ran by composer, automatically copies a `settings.local.php`\nand `settings.docksal.php` into each sites directories to better assist\nlocal development.\n\n#### Environments + the VMLY\u0026R Profiles _Biplane_ and _Blackbird_\nThe VMLY\u0026R profiles include config-split options by default, and have\nadditional tasks during install to establish the default configuration\nand each split's configuration, as well as import as the local\nenvironment before the installation is complete.\n\nThe four included default configurations include:\n - Local (_local_) – Local development configuration overrides, such as\n disabling page cache and advanced aggregation, and enabling development\n modules.\n - Development (_remote_dev_) - Mainly enabling _Shield_ authentication\n and Stage File Proxy.\n - Stage (_remote_stage_) – Mainly enabling _Shield_ authentication and\n Stage File Proxy.\n - Production (_remote_prod_) – Enables Syslog and form Captcha.\n\n### Multi-site support\n\nMulti-site support is baked into the project via our supplied Docksal\ntools. When another site needs to be added, it's as simple as creating a\nthe new drush alias file and running `composer install`. The command will\nbuild out the site folder structure, copy the default settings.php file\ninto the site directory and is then ready for installation. The `kit/sync`\nand `kit/conf` tools both support syncing and exporting/importing any\nsite in a multi-site Drupal instance.\n\n### Standardized theme management and structure\nKIT automatically includes a base theme (Bazo) and two scaffolding\nthemes which use Bazo as a base theme.\n\n#### _Bazo_ base theme\nThe _Bazo_ base theme is meant to help assist its child-themes. It\nincludes standard templates but moves most of the classes into its\npreprocesses to allow them to be more-easily removed later by the child\npreprocess. The two more-important factors of the subtheme are:\n - Automatic Drupal library attachment – Bazo automatically attaches\n child-theme libraries to their related entities as long as they follow\n a naming convention:\n   - theme-name/entity-id\n   - theme-name/entity-id--view-mode\n   - theme-name/entity-id--view-mode--bundle\n\n   This not only helps your project stay organized, but it allows\n front-end developers to attach their libraries to components without\n needing to touch PHP.\n\n   Note: notice the _entity-id--view-mode--bundle_ is different than\n Drupal's default theme-name convention of _entity-id--bundle--view-mode_.\n This was done purposely, because typically all bundles of a certain\n view-mode will share a library versus all view-modes sharing a library\n of a certain bundle. This allows a universal library to be included for\n view-modes and then more-specific implementations that are\n bundle-specific also be included .\n - Automatic attribute-variable conversion – Baso automatically converts\n specified arrays to attribute variables in a \"postprocess\" function\n that are listed in the preprocess's\n `$variables['#attribute_variables']` array. IE:\n   - `$variables['#attribute_variables'][] = 'figcaption_attributes';`\n   - `$variables['#attribute_variables'][] = 'wrapper_attributes';`\n   - `$variables['#attribute_variables'][] = 'figcaption_attributes';`\n   - `$variables['#attribute_variables'][] = 'image_attributes';`\n\n#### Scaffolded child-themes via a Docksal command\nVMLY\u0026R has a couple scaffolding themes included to build from, but\nthey're not included in the project directly. Instead they can be\ngenerated via the `fin kit/theme` command.\n\n## Installation\n\nGetting a running site takes only a few steps for a project.\n\n1. [Install Docksal](https://docksal.io/installation) if it's not already installed.\n1. Install the project.\n    1. Use composer to create the new project. *Note: try not to use hyphenated project names if possible, docksal currently has weird issues with projects with hyphens.*\n       ```\n       fin run-cli \"composer create-project --no-install vmlyr-drupal/kit [FOLDER_NAME_HERE]\"\n       ```\n    1. Change into the directory.\n        ```\n        cd [FOLDER_NAME_HERE]\n        ```\n    1. If this directory was not already a git project, initialize the\n    new repository\n        ```\n        git init\n        ```\n    1. If this project has a remote repository, add the remote origin\n        ```\n        git remote add origin [REMOTE_REPOSITORY_URL_HERE]\n        ```\n        \n1. Run `fin start` in the project to create the Docksal project.\n1. Open each site's Drush alias file (`/drush/sites/` to update the\nlocal URI as well as any relevant server information if it's already\nknown. _(note: Your local should have been listed by Docksal at the end\nof running `fin start`)_\n1. If running a multisite install, open `/sites/sites.php` folder to\n make sure domains are mapped to the correct site.\n\n    **Docksal's domain name is the project folder name in alphanumeric\n    appended with .docksal. (I.E. _drupal-8-kit_ becomes\n    _drupal8kit.docksal_)**\n    ```\n    $sites['domainname.docksal'] = 'www';\n    $sites['www.domainname.docksal'] = 'www';\n    ```\n    **External domains are mapped here as well.**\n    ```\n    $sites['www.domainname.com'] = 'www';\n    $sites['dev-www.domainname.com'] = 'www';\n    $sites['stg-www.domainname.com'] = 'www';\n    $sites['prod-www.domainname.com'] = 'www';\n    ```\n    **Docksal supports subdomains, and Drupal supports mapping\n    subdomains on a multi-site install.**\n    ```\n    $sites['subdomain.domainname.docksal'] = 'subdomain';\n    ```\n    **External subdomains are mapped here as well.**\n    ```\n    $sites['subdomain.domainname.com'] = 'subdomain';\n    $sites['dev-subdomain.domainname.com'] = 'subdomain';\n    $sites['stg-subdomain.domainname.com'] = 'subdomain';\n    $sites['prod-subdomain.domainname.com'] = 'subdomain';\n    ```\n1. Run `fin init`\n1. Open a browser and go to the site; it should have been redirected to\nthe site install page.\n1. Walk through the install process. _(note: the site should\nautomatically start installing after a profile is selected; if it\ndoesn't, and it asks for database settings, reload the\n`/core/install.php` URL without any GET parameters)_\n1. Fill out the site configuration. If using either of the VMLY\u0026R\nProfiles and the environment URLs are unknown, make a best guess at what\nthey could be\n_(we suggest following the `//ENV-WWW.SITE_PROD.DOMAIN` structure)_.\nThe domains are used for indicating current environment and using other\nenvironment's assets via _Stage File Proxy_. Setting these up now helps\nnot needing to set these in multiple places later on during development.\n1. If you selected either of the VMLY\u0026R profiles, upon saving\nconfiguration, the site should export all relevant configuration into\nthe site's sync directory and import as the local environment.\n1. Installation is complete once redirected to the homepage of the site.\n1. To start building your own theme, run `fin kit/theme` to\ngenerate a new theme + theme source setup based on our example scaffold\nthemes. If the _Blackbird_ profile was installed, we suggest scaffolding\nfrom the _Blackbird_ theme option of the same name. If you're not using \n_Blackbird_ and want a more simple starting point for you theme we \nsuggest scaffolding from Biplane scaffold theme.\n\n## Post-installation and provider-related configuration\nBased on the hosting provider, some configuration needs to be created or \nupdated. Similarly, some configuration will also be unneeded and can be \nremoved.\n\n### Jenkins\n@TODO Jenkins setup walk-through.\n\n### Bitbucket pipelines\nTo enable bitbucket pipeline builds, rename `bitbucket-pipelines-example.yml` \nto `bitbucket-pipelines.yml`. Note: Bitbucket Pipelines needs to be \nenabled in bitbucket to work.\n#### Setup\nThere is a small amount of configuration to get pipelines talking to \nyour external repository after copying the pipelines file into the \nrepository. In your Bitbucket account:\n- go to Settings \u003e Pipelines \u003e Settings and toggle \"Enable Pipelines\"\n- go to Settings \u003e Pipelines \u003e Repository Variables and add a variable named `DESTINATION_REPOSITORY` with the url to your hosting providers repository (example: `ssh://codeserver.example.drush.in:2222/~/repository.git` for Pantheon).\n- go to Settings \u003e Pipelines \u003e Deployments and configure/create the Deployment environments you want to connect to.\n  - Rename the environment, make sure it matches the `deployment` key:value inside your pipelines file (example: `deployment: Development`)\n  - Add a variable here named `DESTINATION_REPOSITORY_BRANCH` and put the value as the branch you want to push into on your hosting providers repository (example: `master`).\n- go to Settings \u003e Pipelines \u003e SSH Keys. These keys are what are used to connect to your hosting provider repository.\n  - Generate a key pair. _Note: Acquia requires a stronger key-pair than the default that Bitbucket generates. Instead of clicking the generate button that Bitbucket provides, you will need to create the keypair manually by running `ssh-keygen -b 4096` in your local terminal (consider naming it something descriptive) and then adding its private and public keys to Bitbucket._\n  - Take the public key and add it to a user on the hosting provider repository. It's best to use either a deployment key if the provider supports it, or create a service account solely for connecting the provider to pipelines (example: a user on the provider with pipelines@yourwebsite.com that is solely for holding the connection to pipelines).\n  - Take the host address of the hosting provider's repository and place it in the \"Host addresses\" field in the Known Hosts area, then fetch the fingerprint to make sure the connection is validated.\nYou should now be able to push up your change and watch the pipelines kick off. \n\n_Note: sometimes it takes some playing-around-with to make sure that pipelines can connect to the hosting-provider repository, such as recreating the key pairs._\n\n#### Default pipelines provided\n##### Branch: Master\nThis pipeline watches the master branch, and when code is merged into it, automatically builds and deploys the code to the relevant \"Development\" environment repository.\n\nThis pipeline uses the default \"Build package\" and \"Deploy package\" pipeline steps. The \"Deploy package\" step defaults to run the \"Development\" deployment. \n\n_In scenarios where there should be a development branch building to the Development environment, and the master branch building to Stage or Production environments, the `deployment` would be changed to the relevant environment name, and a new branch-based pipeline would be created to push to Development._\n##### Custom: Feature\nThis pipeline takes any branch and allows to build to a custom \"feature\" branch on the hosting provider repository. This allows for easily creating \"Feature\" environments on the hosting provider.\n\nThis pipeline uses the default \"Build package\" and \"Deploy package\" pipeline steps. \"The Deploy package\" step defaults to run a \"Feature\" deployment, which will need to be created under the Settings \u003e Pipelines \u003e Deployments tab on Bitbucket Pipelines. \n\nTo run this pipeline:\n- go to the \"Branches\" section of your Bitbucket account\n- click the \"...\" to the very right of the branch that you want to build\n- select \"Run pipeline for a branch\"\n- select the \"custom: feature\" pipeline\n- fill out what you want the feature branch on the hosting provider repo to be called in the \"DESTINATION_REPOSITORY_BRANCH\" field (ex: feature/header-redesign)\n- click \"Run\"\n\n##### Pull-Requests\nThis pipeline automatically runs on pull-requests. It does a full build and then lints the code; it fails if any issues arise.\n\nThis pipeline uses the default \"Build package\" and \"Test package\" pipeline steps. It does not deploy code.\n\n### Files included in KIT\nThe following are grouped to give context for which \nfiles/directories can be modified or removed.\n\n###### Provider-specific files: Acquia\n- `/hooks/common`\n- `/hooks/dev`\n- `/hooks/prod`\n- `/hooks/samples`\n- `/hooks/test`\n###### Provider-specific files: AWS\n- `/.ebextensions`\n###### Provider-specific files: Pantheon\n- `/pantheon.yml`\n- `/scripts/pantheon/*`\n###### Provider-specific files: Platform\n###### Universal files\n- `/docroot/web.config` (we don't typically use ASP.NET; kept for reference if needed in the project)\n- `/env.example` (we don't suggest env files; kept for reference if needed in the project)\n- `/package.json` (was used by packagist to create project and no longer needed)\n- `/travis.yml` (we don't typically use travis; kept for reference if needed in the project)\n\n### Provider-specific modifications\nModifications to make to the project based on which hosting provider is \nchosen.\n\n###### Provider-specific modifications: Acquia\n1. Remove unnecessary files and directories for Acquia:\n    - [List of universal files to remove](#universal-files)\n    - [List of AWS files and directories](#provider-specific-files-aws)\n    - [List of Pantheon files and directories](#provider-specific-files-pantheon)\n    - [List of Platform.sh files and directories](#provider-specific-files-platform)\n1. Settings.php modifications\n    1. Open `/docroot/sites/www/settings.php` and find the \"Include server-specific configuration.\" section.\n    1. Uncomment the Acquia portion.\n    1. Remove uneeded server-specific configuration from other providers.\n###### Provider-specific modifications: AWS\n1. Remove unnecessary files and directories for Platform.sh:\n    - [List of universal files to remove](#universal-files)\n    - [List of Acquia files and directories](#provider-specific-files-acquia)\n    - [List of Pantheon files and directories](#provider-specific-files-pantheon)\n    - [List of Platform.sh files and directories](#provider-specific-files-platform)\n1. Settings.php modifications\n    1. Open `/docroot/sites/www/settings.php` and find the \"Include server-specific configuration.\" section.\n    1. Uncomment the AWS portion.\n    1. Modify appropriately.\n    1. Remove uneeded server-specific configuration from other providers.\n###### Provider-specific modifications: Pantheon\n1. Remove unnecessary files and directories for Pantheon:\n    - [List of universal files to remove](#universal-files)\n    - [List of Acquia files and directories](#provider-specific-files-acquia)\n    - [List of AWS files and directories](#provider-specific-files-aws)\n    - [List of Platform.sh files and directories](#provider-specific-files-platform)\n1. [Rename /docroot to /web](#renaming-docroot-to-web).\n1. Create symlink from installed sites directory to sites/default/files\n    1. cd to /sites/www (or other site directory if multisite).\n    1. run `rm -rf files` to remove current files directory.\n    1. run `ln -s ../default/files files` to create symlink to default files directory (which is then symlinked to /files on Pantheon's end). Make sure that a /default/files directory exists locally so files have a place to go.\n    1. run `git add files` and commit symlink to repo.\n1. Place post-deploy script in the correct place for pantheon to read it (inside the web directory).\n    1. Create `/web/private/scripts` directory.\n    1. Move `/scripts/pantheon/post_deploy.php` file into `/web/private/scripts`.\n    1. Remove empty `/scripts/pantheon` folder.\n1. Settings.php modifications\n    1. Copy over the settings.pantheon.php file from your initial pantheon install into your `www` (or relevant sites directory).\n    1. Open `/web/sites/www/settings.php` and find the \"Include server-specific configuration.\" section.\n    1. Uncomment the Pantheon portion.\n    1. Remove uneeded server-specific configuration from other providers.\n    \n###### Provider-specific modifications: Platform.sh\n1. Remove unnecessary files and directories for Platform.sh:\n    - [List of universal files to remove](#universal-files)\n    - [List of Acquia files and directories](#provider-specific-files-acquia)\n    - [List of AWS files and directories](#provider-specific-files-aws)\n    - [List of Pantheon files and directories](#provider-specific-files-pantheon)\n1. Settings.php modifications\n    1. Copy over the settings.platformsh.php file from your initial Platform.sh install into your `www` (or relevant sites directory).\n    1. Open `/docroot/sites/www/settings.php` and find the \"Include server-specific configuration.\" section.\n    1. Uncomment the Platform.sh portion.\n    1. Remove uneeded server-specific configuration from other providers.\n\n@TODO Some files and configuration are missing for Platform.sh, which still needed to be included in KIT.\n\n### Renaming docroot to web\nSome providers require a different docroot directory.\n1. Rename `docroot` directory to `web`.\n1. Update `docroot` references to `web` in the following files:\n    - `/.docksal/docksal.env`\n    - `/.gitignore`\n    - `/composer.json` (will need to run composer install afterward to regenerate autoload.php file)\n    - `/drush/*` files (`/drush/sites/www.site.yml`, etc.)\n    - `/patches/htaccess.patch`\n    - `/source/gulpfile.js`\n    - `/source/eslintrc.js`\n\n## Notes and suggestions\n#### Environment aliases\n```\nwww.domainname.com\ndev-www.domainname.com\nstg-www.domainname.com\nprod-www.domainname.com (for pre-go-live)\n```\nWe've found that adding an environment prefix to the production url is a\nlow-effort/high-reward action. This allows for environment URLs that are\neasier to remember and access, both for those working on the site and\nfor clients.\n\n## Theme Development\n\nWhen creating a new theme using the `fin kit/theme` command you'll have two directory structures created for you:\n\n1. **docroot/themes/custom/yourtheme** - This is meant to only contain the files Drupal needs to render the site - e.g. css, javascript, images, template files. It does **not** contain any source files used to generate those files (e.g. sass files). It's important to note that some files under this directory are generated (see next point) and some (e.g. template files) should be edited directly.\n\n1. **source/themes/custom/yourtheme** - Contains all of the source files used to generate the files in docroot/themes/custom/yourtheme.\n\nGulp is used to process the files in _source_ and writes the corresponding output to the matching theme directory under _docroot_. The default gulp file (source/gulpfile.js) is set up with a set of basic tasks needed by most themes. It is also set up to run those tasks in all of the directories under source/themes/custom. This allows the developer to have multiple themes (e.g. a base theme and child themes) under development and use a single command to build them all.\n\nThe following functionality is provided by the default gulp file:\n\n- Sass - Processes all of the scss files under _styles_ in each theme directory and generates source maps. The output is places in _docroot/themes/custom/yourtheme/css_.\n- Javascript - Copies and generates source maps for all js files under _scripts_ in each theme directory. The output is placed in _docroot/custom/yourtheme/js_. \n- Images - Minifies all images under _images_ and places the output in _docroot/custom/yourtheme/images_.\n- Fonts - Copies all the files under _fonts_ to _docroot/custom/yourtheme/fonts_.\n- Icons - Compiles all the svg files under _icons_ and writes the out put to the _docroot/custom/yourtheme/styles/vendor_ and _docroot/custom/yourtheme/fonts/icons_ directories.\n- Testing - Linting of sass and javascript files as configured in _source/.sass-lint.yml_ and _source/.eslintrc_.\n\nTasks provided by the default gulp file are:\n\n- default - Builds the Sass, Javascript, Images, Fonts, and Icons as described above.\n- test - Runs the sass and javascript linters.\n- watch - Builds everything included in the default task as file change in the _source_ directory structure.\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FWPP-Public%2FDrupal-KIT","html_url":"https://awesome.ecosyste.ms/projects/github.com%2FWPP-Public%2FDrupal-KIT","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2FWPP-Public%2FDrupal-KIT/lists"}