github.com/ddev/ddev@v1.23.2-0.20240519125000-d824ffe36ff3/docs/content/developers/project-types.md (about) 1 --- 2 search: 3 boost: .5 4 --- 5 # Adding New Project Types 6 7 Adding and maintaining project types (like `typo3`, `magento2`, etc.) is not too hard. Please update and add to this doc when you find things that have been missed. 8 9 To add a new project type: 10 11 * Add the new type to the list in `nodeps.go` 12 * Add to `appTypeMatrix` in `apptypes.go` 13 * Create a new go file for your project type, like `django.go`. 14 * Implement the functions that you think are needed for your project type and add references to them in your `appTypeMatrix` stanza. There are lots of examples that you can start with in places like `drupal.go` and `typo3.go`, `shopware6.go`, etc. The comments in the code in `apptypes.go` for the `appTypeFuncs` for each type of action tell what these are for, but here's a quick summary. 15 * `settingsCreator` is the function that will create a main settings file if none exists. 16 * `uploadDir` returns the filepath of the user-uploaded files directory for the project type, like `sites/default/files` for Drupal or `pub/media` for magento2. 17 * `hookDefaultComments` adds comments to config.yaml about hooks with an example for that project type. It's probably not useful at all. 18 * `apptypeSettingsPaths` returns the paths for the main settings file and the extra settings file that DDEV may create (like settings.ddev.php for Drupal). 19 * `appTypeDetect` is a function that determines whether the project is of the type you’re implementing. 20 * `postImportDBAction` can do something after db import. I don’t see it implemented anywhere. 21 * `configOverrideAction` can change default config for your project type. For example, your CMS may require `php8.3`, so a `configOverrideAction` can change the php version. 22 * `postConfigAction` gives a chance to do something at the end of config, but it doesn’t seem to be used anywhere. 23 * `postStartAction` adds actions at the end of [`ddev start`](../users/usage/commands.md#start). You'll see several implementations of this, for things like creating needed default directories, or setting permissions on files, etc. 24 * `importFilesAction` defines how [`ddev import-files`](../users/usage/commands.md#import-files) works for this project type. 25 * `defaultWorkingDirMap` allows the project type to override the project’s [`working_dir`](../users/configuration/config.md#working_dir) (where [`ddev ssh`](../users/usage/commands.md#ssh) and [`ddev exec`](../users/usage/commands.md#exec) start by default). This is mostly not done anymore, as the `working_dir` is typically the project root. 26 * `composerCreateAllowedPaths` specifies the paths that can exist in a directory when `ddev composer create` is being used. 27 * You’ll likely need templates for settings files, use the Drupal or TYPO3 templates as examples, for example `pkg/ddevapp/drupal` and `pkg/ddevapp/typo3`. Those templates have to be loaded at runtime as well. 28 * Once your project type starts working and behaving as you’d like, you’ll need to add test artifacts for it and try testing it (locally first). 29 * Add your project to `TestSites` in `ddevapp_test.go`. 30 * Create a DDEV project named `testpkg<projectype>` somewhere and get it going and working with a database and files you can export. 31 * Export the database, files, and (optionally) code to tarballs or `.sql.gz`. Put them somewhere on the internet—they’ll end up in `ddev/ddev_test_tarballs`. I can give you permissions on that if you like. The `magento2` project has descriptions explaining how each tarball gets created. Do that for yours as well. 32 * Run the test and get it working. I usually use the trick of setting `GOTEST_SHORT=<element_in_TestSites>`, like `GOTEST_SHORT=7`. Then set that environment variable in the GoLand profile or your environment. `export GOTEST_SHORT=7 && make testpkg TEST_ARGS="-run TestDdevFullsiteSetup"`