PHPackages sleepingmonk/drupal-monk - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [Utility & Helpers](/categories/utility) 4. / 5. sleepingmonk/drupal-monk ActiveProject[Utility & Helpers](/categories/utility) sleepingmonk/drupal-monk ======================== Project template for Drupal projects with composer and helpers. 11.0.1(4mo ago)110[1 issues](https://github.com/sleepingmonk/drupal-monk/issues)[7 PRs](https://github.com/sleepingmonk/drupal-monk/pulls)GPL-2.0-or-laterPHPCI failing Since Feb 21Pushed 2w agoCompare [ Source](https://github.com/sleepingmonk/drupal-monk)[ Packagist](https://packagist.org/packages/sleepingmonk/drupal-monk)[ RSS](/packages/sleepingmonk-drupal-monk/feed)WikiDiscussions 11.x Synced 2w ago READMEChangelogDependencies (28)Versions (31)Used By (0) Readme ====== [](#readme) Meta ---- [](#meta) This document should be updated by *YOU*, as necessary as the project evolves. Add your author information for historical reference and professional context, as: - `Date first edited: NAME (email)` ### Authors: [](#authors) - 2020-01-10: Calvin (sleepingmonk) ### Project Info: [](#project-info) - Working Repo: [Github](https://github.com/%3Cuser%3E/%3Cproject%3E) - Hosting: [](host%20url) - CI/CD: [](platform%20url) - - Backend: [Drupal 8](https://drupal.org/) - Frontend: [](drupal%20theme%7Cheadless%20repo) ### Contents [](#contents) - [Readme](#readme) - [Meta](#meta) - [Authors:](#authors) - [Project Info:](#project-info) - [Contents](#contents) - [Local Development](#local-development) - [Options:](#options) - [Module Management](#module-management) - [Adding Contrib Modules](#adding-contrib-modules) - [Updating Core](#updating-core) - [Updating Contrib Modules](#updating-contrib-modules) - [Removing Contrib Modules](#removing-contrib-modules) - [Applying Patches](#applying-patches) - [Git Workflow and Deploying Code](#git-workflow-and-deploying-code) - [Alternative Release Options](#alternative-release-options) - [Testing and Approval](#testing-and-approval) - [Automated Testing](#automated-testing) - [Deploying Code](#deploying-code) Local Development ----------------- [](#local-development) *NOTE:* `composer.json: extra: working-repo` is used to prevent developers from accidentally working on a cloned production artifact. Set it's value to the working github repo url. Composer will check it against `git remote get-url origin`. - Docker: - Lando: Lando/Docker optional, any `*AMP` environment will do, but there is helpful tooling here for Lando. **WARNING: Use the Lando installer to install it's preferred version of Docker.** Once installed cd to project directory and type `lando` for a list of commands. *Spin up the local:* - `lando start` - Spin up the environment. - `lando db-import [path to db]` - Import your database. Store db in `data/`. - `lando composer install` - Composer install. - `lando tb` - Build the theme assets. - `lando reset` - Runs updb, cim, cr ... Composer install will move `settings.local.php` and `services.local.yml` to the `sites/default/` directory with functional configuration. You can replace or alter these files if you wish. They will not be replaced if they exist. **Ready to work.** Database can be fetched in multiple ways. I recommend saving to `data/` directory which is ignored and within the environment so it can be saved for future resets and imported from there, whithout cluttering up the project root with different versions of the database. #### Options: [](#options) \[env\] = live or the most live like environment. - Drush Alias - lando drush @\[proj\].\[env\] sql-dump --gzip > data/\[env\]-YYYY-MM-DD.sql.gz Module Management ----------------- [](#module-management) From the project root: ### Adding Contrib Modules [](#adding-contrib-modules) - `lando composer require drupal/[package_name] --no-update` to add it to the composer.json without updating everything. - `lando composer update drupal/[package_name]` to fetch/update only the desired module. ### Updating Core [](#updating-core) - `lando composer update drupal/core drupal/core-recommended --with-dependencies` ### Updating Contrib Modules [](#updating-contrib-modules) - `lando composer update drupal/[package_name]` Sometimes several contrib modules are several versions behind. *Do not use `lando composer update` without specifying a module, or it will update everything that's outdated at once, possibly introducing regressions which you'll have to do much more testing for.* *Updates should be controlled and tested well. It's easiest to do that in smaller chunks. Especially watch out for BETA, ALPHA, or DEV versions of modules which are not stable and make no guarantees about not breaking things between updates. Ideally, never use Alpha/Dev modules and use BETA's sparingly. Consider contributing to the project to help get it to a full release.* ### Removing Contrib Modules [](#removing-contrib-modules) Enabled modules should be removed from a code base in 2 separate releases. The first release update should simply uninstall the module. The second release should remove the module from the codebase as described below. If you do it all at once Drupal will not be able to find the module code to be able to uninstall it, because it won't exist anymore. Phase 1: Uninstall the module: - `lando drush pmu [module]` - uninstall the module. - `lando drush cex` - export the config changes caused by uninstalling the module. - Deploy the changes to update the Production site. Phase 2: Remove the module: - `lando composer remove [package] --no-update` will remove a package from require or require-dev, without running all updates. - `lando composer update [package]` will remove the package code. ### Applying Patches [](#applying-patches) If you need to apply patches, you can do so with the [composer-patches](https://github.com/cweagans/composer-patches) plugin. To add a patch to drupal module `foobar` insert the patches section in the extra section of composer.json: ``` "extra": { "patches": { "drupal/foobar": { "Patch description": "Drupal URL to patch" } } } ``` Git Workflow and Deploying Code ------------------------------- [](#git-workflow-and-deploying-code) **NOTE: Always reset your local to a production like state before starting a new feature. Configuration should be imported from `master` and/or a production database should be imported before starting work, so that config changes from the new feature are clean when exported.** This project is configured for a \[Parallel Git Workflow - See note if hosting on Pantheon\]\[parallelpdf\] using multidev environments. ENV -> GIT BRANCH - develop -> `develop` - stage -> `stage` - Live -> `master` In this way `master` is ALWAYS clean production code. New feature branches for any work should be branched from `master` so it starts clean. If you branch from anything else, you will carry in code that's not related to your ticket that can be hard to separate for deployment to Production if your code is approved, but the other code is not. Your branch will be "contaminated". Stay clean to not accidentally introduce rejected code to production and to not frustrate whoever needs to deploy project code with precision. `feature/[ticket-id]--short-description` Lead commit messages with ticket id: **PRJ-27: Message ...** This repo is managed here[repo](https://github.com/%3Cuser%3E/%3Cproject%3E) so push your feature there and make a Pull Request to `develop`. This will be merged and deployed to the develop environment on [host](host%20url) for INTERNAL review/QA. If that passes, merge the clean FEATURE branch into `stage` for deploy to the stage (multidev) environment on [host](host%20url) for CLIENT review/approval. If it's approved for deployment to production, merge the clean FEATURE branch into `master` for deploy to the Live environment. In this way, individual features can move through the environments without affecting, or being affected by, other work in progress. Issues can stall in any environment for any reason and not hold up the progress of any other issues in development. Hotfixes and security updates can breeze through without having to worry about whether or not you can deploy the 5 other things that might already have been sitting on stage for the last 3 months. #### Alternative Release Options [](#alternative-release-options) - **Single Feature/Hotfix**: Deploy a single approved feature branch as a production release by merging it into the master branch. - **Release Branch**: As features are approved on `stage` they can be merged into a new `release-x.y.z` branch that was cut from the clean `master` branch. Do not merge any un-approved feature branches into the release branch. Deploy the `release` branch whenever it's ready by merging it into the `master` branch. - **Completed Stage**: You can consider `stage` a release branch if you're diligent in confirming all features merged into it are approved and signed off, then merging `stage` into `master` to deploy it as a release. There is some risk in deploying code that may have made it to `stage` but has not been signed off for release, so be careful. ### Testing and Approval [](#testing-and-approval) A **solo dev** with limited oversight could be trusted to approve at the develop level, so the develop environment step may not be necessary. Leave it in place for when you need more detailed internal review. Just remember that stage and Live will get ahead of it if you don't use it for every feature, so you'll need to merge `master` into `develop` first, if you want a clean and concise Pull Request into develop. Features should always be approved by the product owner on stage. Avoid doing internal review on stage because if it fails, stage would be contaminated with a feature not ready for product owner review which can be confusing to the product owner or PM. Though a solo dev may be trusted to deploy a feature or update without approval, requiring approval and signoff is recommended to help spot issues we may have blind spots for, and to protect us from breakage on production. ### Automated Testing [](#automated-testing) - PHP linting on CI build\_test - PHP Code Sniffer on CI build\_test - Other automated testing may be added and is encouraged ### Deploying Code [](#deploying-code) Merging a PR or pushing new commits to one of the environment branches on [Repo](https://github.com/%3Cuser%3E/%3Cproject%3E) (develop, stage, master), will trigger CircleCI to build, test and deploy the updated branch to it's corresponding environment. It does this by syncing the production code from the working repo, to a separate production repo on the host. Drush via alias, should run post deploy commands like `updb -y`, `cim -y`, `cr`. Make sure you check this for failure and run manually if needed. This process keeps working code separate from production code. ### Health Score 44 — FairBetter than 91% of packages Maintenance68 Regular maintenance activity Popularity7 Limited adoption so far Community19 Small or concentrated contributor base Maturity74 Established project with proven stability Bus Factor1 Top contributor holds 57.9% of commits — single point of failure How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Release Activity Cadence Every ~145 days Recently: every ~305 days Total 22 Last Release 130d ago Major Versions 7.x-dev → 8.1.02018-01-15 8.x-dev → v9.0.02022-10-18 9.x-dev → 11.0.02026-02-19 ### Community Maintainers ![](https://www.gravatar.com/avatar/0a878ec244783c4786aafadcd0b9bbc12ce280b5b0ef8a0c4b7e4e698eed89c3?d=identicon)[sleepingmonk](/maintainers/sleepingmonk) --- Top Contributors [![webflo](https://avatars.githubusercontent.com/u/123946?v=4)](https://github.com/webflo "webflo (117 commits)")[![sleepingmonk](https://avatars.githubusercontent.com/u/6646958?v=4)](https://github.com/sleepingmonk "sleepingmonk (37 commits)")[![pfrenssen](https://avatars.githubusercontent.com/u/442924?v=4)](https://github.com/pfrenssen "pfrenssen (6 commits)")[![derhasi](https://avatars.githubusercontent.com/u/118502?v=4)](https://github.com/derhasi "derhasi (4 commits)")[![weitzman](https://avatars.githubusercontent.com/u/7740?v=4)](https://github.com/weitzman "weitzman (4 commits)")[![greg-1-anderson](https://avatars.githubusercontent.com/u/612191?v=4)](https://github.com/greg-1-anderson "greg-1-anderson (4 commits)")[![jmolivas](https://avatars.githubusercontent.com/u/366275?v=4)](https://github.com/jmolivas "jmolivas (3 commits)")[![bradjones1](https://avatars.githubusercontent.com/u/981966?v=4)](https://github.com/bradjones1 "bradjones1 (2 commits)")[![jorissteyn](https://avatars.githubusercontent.com/u/448056?v=4)](https://github.com/jorissteyn "jorissteyn (2 commits)")[![jonhattan](https://avatars.githubusercontent.com/u/482058?v=4)](https://github.com/jonhattan "jonhattan (2 commits)")[![jcnventura](https://avatars.githubusercontent.com/u/329663?v=4)](https://github.com/jcnventura "jcnventura (2 commits)")[![mikran](https://avatars.githubusercontent.com/u/820244?v=4)](https://github.com/mikran "mikran (1 commits)")[![ModulesUnraveled](https://avatars.githubusercontent.com/u/1663810?v=4)](https://github.com/ModulesUnraveled "ModulesUnraveled (1 commits)")[![opdavies](https://avatars.githubusercontent.com/u/339813?v=4)](https://github.com/opdavies "opdavies (1 commits)")[![rwanyoike](https://avatars.githubusercontent.com/u/3677497?v=4)](https://github.com/rwanyoike "rwanyoike (1 commits)")[![Saphyel](https://avatars.githubusercontent.com/u/5764721?v=4)](https://github.com/Saphyel "Saphyel (1 commits)")[![thom8](https://avatars.githubusercontent.com/u/331453?v=4)](https://github.com/thom8 "thom8 (1 commits)")[![tstoeckler](https://avatars.githubusercontent.com/u/3929504?v=4)](https://github.com/tstoeckler "tstoeckler (1 commits)")[![bojanz](https://avatars.githubusercontent.com/u/330162?v=4)](https://github.com/bojanz "bojanz (1 commits)")[![zaporylie](https://avatars.githubusercontent.com/u/1690685?v=4)](https://github.com/zaporylie "zaporylie (1 commits)") ### Embed Badge ![Health badge](/badges/sleepingmonk-drupal-monk/health.svg) ``` [![Health](https://phpackages.com/badges/sleepingmonk-drupal-monk/health.svg)](https://phpackages.com/packages/sleepingmonk-drupal-monk) ``` ### Alternatives [az-digital/az_quickstart Arizona Quickstart 52265.6k3](/packages/az-digital-az-quickstart)[govcms/govcms GovCMS Drupal Distribution 197100.6k3](/packages/govcms-govcms)[thunder/thunder-distribution The thunder distribution 51653.5k3](/packages/thunder-thunder-distribution)[drupalwxt/wxt Project template for Drupal 10 sites built with the WxT distribution. 29163.3k8](/packages/drupalwxt-wxt)[fourkitchens/sous-drupal-project Starter project for Sous a Drupal distribution featuring a theme based on Emulsify Design System. 141.1k](/packages/fourkitchens-sous-drupal-project) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)