A minimal project build for Drupal 10 module development.
This project requires DDEV and Composer 2 be installed before you begin.
Checkout the project and run the following commands from project root:
ddev start
composer install
ddev auth ssh
Now you are ready to install Drupal and test modules:
ddev install
This command will install Drupal 10 plus the following useful modules: config_inspector
, admin_toolbar
, and admin_toolbar_tools
. You can login with admin / admin
at https://ui-patterns-2.ddev.site/user.
If using NFS to speed up the container, see these steps.
ddev debug nfsmount
(optional)- See the macOS NFS Setup section of the DDEV documentation.
drush 12
is installed by default and can be run with ddev drush COMMAND
. You can use ddev drush site:install
if you want to customize the install.
The use of composer require
is assumed to be used for maintenance of the core framework, not adding modules for testing.
You can use composer require
to add modules that you need -- and to check dependencies. Do not commit those additions to the project.
Modules are installed to web/modules/contrib
, which is leveraged by our common ddev tasks.
We have automated common tasks as ddev commands to reduce dependencies. The following tasks are available.
Command: ddev check MODULE
Example: ddev check admin_toolbar
The check
command will run code reviews using PHPCBF, PHPCS, PHPMD, and PHPStan against the selected module. PHPCBF may change the module's code as part of this action.
These commands can also be run individually as ddev md
, ddev sniff
, and ddev stan
.
Note that PHPStan is pinned to PHPStan level 2 in this command. Use ddev stan
to override the level.
Command: ddev cleanup
Removes test files generated by ddev test
.
Command: ddev clone MODULE_NAME [-b BRANCH_NAME | -t TAG_NAME] [-c]
Example: ddev clone admin_toolbar
Example: ddev clone workbench_access -c
Example: ddev clone admin_toolbar -b 8.x-1.x
Example: ddev clone my_module -o [email protected]:palantirnet
Use ddev clone
rather than composer require
if you want to checkout a git project for development.
The clone
command will checkout the default branch of the selected module to the web/modules/contrib
directory.
Use the -b
or -t
flags to specify a branch or tag. The flags cannot be used together.
Adding the -c
flag indicates you are a project contributor
, not a project maintainer
. The command will use https rather than ssh to checkout the project. This flag is ignored when using -o
.
Use the -o
flag to specify a different origin than drupal.org. The argument is a path to the account that owns the repository (see the example above).
Note that this command will delete
an existing copy of the module.
Command: ddev compat MODULE [-v VERSION]
Example: ddev compat admin_toolbar
Example: ddev compat admin_toolbar -v 7.4
The compat
command will run PHPCS against the selected module using the PHPCompatibility
coding standard.
Use the -v
flag to specify a PHP version to test. By default, the version is 8.2
.
Command: ddev eslint MODULE
Example: ddev eslint admin_toolbar
Example: ddev eslint admin_toolbar --fix
The eslint
command will run core's eslint
and JS prettier
profiles against your code. By default, the command runs in report mode. You may pass flags to the command (such as --fix
) as documented by eslint.
This command will also install the node dependencies required for core development.
This command is adapted from ddev contrib.
Command: ddev install
Installs the default drupal site. This command will also install the node dependencies required for core development.
Command: ddev md MODULE
Example: ddev md admin_toolbar
The md
command will run code reviews using PHPMD against the selected module.
Command: ddev rector MODULE
or ddev rector MODULE -d
or ddev rector MODULE --dry-run
Example: ddev rector admin_toolbar
Example: ddev rector admin_toolbar -d
The rector
command will run Drupal Rector updates against the selected module, potentially rewriting the module's code. Using the -d
or --dry-run
flag will not perform the changes, but instead show the suggested changes.
Command: ddev remove MODULE
Example: ddev rector admin_toolbar
The ddev remove
command will uninstall a module and delete it from the web/modules/contrib
directory.
Command: ddev sniff MODULE
Example: ddev sniff admin_toolbar
The sniff
command will run code reviews using PHPCBF and PHPCS against the selected module. PHPCBF may change the module's code as part of this action.
Command: ddev stan MODULE
Example: ddev stan admin_toolbar
Example: ddev stan admin_toolbar -l 8
The stan
command will run code reviews using PHPStan against the selected module.
This command defaults to use PHPStan level 2. You can pass a preferred level (0-9
, or max
) using the -l
flag.
Command: ddev stylelint MODULE
Example: ddev stylelint admin_toolbar
Example: ddev stylelint admin_toolbar --fix
The stylelint
command will run core's stylelint
CSS profiles against your code. By default, the command runs in report mode. You may pass flags to the command (such as --fix
) as documented by styelint.
This command will also install the node dependencies required for core development.
Command: ddev test MODULE
Example: ddev test admin_toolbar
Example: ddev test admin_toolbar Functional AdminToolbarAdminMenuTest
The ddev test
command runs all tests defined by a module according to Drupal's testing standards.
If you pass the type of test (Functional, FuntionalJavascript, Kernel, Unit
) and a test class, only tests in that class will be run.
This command uses testdox
output, which is easy to read but does not provide debugging output.
You can run testb
with the same parameters to get browser output.
Let's assume you want to write a patch for the workbench_tabs
module. Follow these steps:
ddev start
composer install
ddev install
ddev clone workbench_tabs
- If you are a maintainer, use
ddev clone workbench_tabs -y
- If you are a maintainer, use
ddev test workbench_tabs
- Run this step to ensure that existing tests pass.
- Then run
ddev cleanup
to remove test files.
ddev drush en workbench_tabs
- Now develop your new feature or bugfix in the module
- Do not check your changes into git before creating the patch.
- Create a patch
cd web/modules/workbench_tabs
git diff > ISSUE#-MODULE-summary-COMMENT.patch
- Now you can upload the patch to the Drupal.org issue.
ddev start
composer install
ddev install
ddev clone workbench_tabs
- If you are a maintainer, use
ddev clone workbench_tabs -y
- If you are a maintainer, use
ddev test workbench_tabs
- Run this step to ensure that existing tests pass.
- Then run
ddev cleanup
to remove test files.
ddev drush en workbench_tabs
- Download the patch to
web/modules/workbench_tabs
:cd web/modules/workbench_tabs
wget https://drupal.org/PATH-TO-FILE/NAME-OF-FILE
patch -p1 < NAME-OF-FILE
ddev drush cr
- Now you can test the patch in the site.
We are deliberately not using other project dependencies (notably the-build
, phing
, and drupal-skeleton
) on this project. We want this project template to be as independent as possible. This project also does not require integrations with CircleCI and web hosts.
Solr support is not provided by default. It can be added later if needed.
The main
branch is locked against commits that are not in approved pull requests.
A solr server is provided at http://drupal-10-development.ddev.site:8983/solr/. To ensure service is ready to be used, restart service using ddev restart
.
search_api_solr
server dependency is not currently installed, if you want to test the functionality try this branch search_api_example or follow these steps.
- Install
search_api_solr
module:- Run
composer require drupal/search_api_solr
to install all dependencies. - If you wish to test a branch of that module, then run
ddev clone
to overwrite the composer checkout.
- Run
- Enable the
search_api_solr
module either using the web interface orddev drush en -y search_api_solr
- Navigate to Search api page, click "Add server button"
- Choose Solr as backend.
- Choose "Standard" as the Solr connector type and configure it:
- Set "Server name" to anything you want. Maybe
ddev-solr-server
. - Set "Backend" to
Solr
- Set "Solr host" to
drupal-10-development.ddev.site
. - Set "Solr core" name to
dev
. - Under "Advanced server configuration" set the "solr.install.dir" to
/opt/solr
.
- Set "Server name" to anything you want. Maybe
The Solr installation is not currently using cloud config. Pull requests to add this feature are welcome.