github.com/drud/ddev@v1.21.5-alpha1.0.20230226034409-94fcc4b94453/docs/content/developers/project-types.md (about)

     1  # Adding New Project Types
     2  
     3  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.
     4  
     5  To add a new project type:
     6  
     7  * Add the new type to the list in `nodeps.go`
     8  * Add to `appTypeMatrix` in `apptypes.go`
     9  * Create a new go file for your project type, like `django.go`.
    10  * 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.
    11      * `settingsCreator` is the function that will create a main settings file if none exists.
    12      * `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.
    13      * `hookDefaultComments` adds comments to config.yaml about hooks with an example for that project type. It's probably not useful at all.
    14      * `apptypeSettingsPaths` returns the paths for the main settings file and the extra settings file that DDEV may create (like settings.ddev.php for Drupal).
    15      * `appTypeDetect` is a function that determines whether the project is of the type you’re implementing.
    16      * `postImportDBAction` can do something after db import. I don’t see it implemented anywhere.
    17      * `configOverrideAction` can change default config for your project type. For example, magento2 now requires `php8.1`, so a `configOverrideAction` can change the php version.
    18      * `postConfigAction` gives a chance to do something at the end of config, but it doesn’t seem to be used anywhere.
    19      * `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.
    20      * `importFilesAction` defines how [`ddev import-files`](../users/usage/commands.md#import-files) works for this project type.
    21      * `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.
    22  * 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.
    23  * 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).
    24      * Add your project to `TestSites` in `ddevapp_test.go`.
    25      * Create a DDEV project named `testpkg<projectype>` somewhere and get it going and working with a database and files you can export.
    26      * Export the database, files, and (optionally) code to tarballs or `.sql.gz`. Put them somewhere on the internet—they’ll end up in `drud/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.
    27      * 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"`