Refactor development commands / testing stack / docs.

.ddev/config.yaml

@@ -16,10 +16,7 @@ database:
 hooks:
     post-start:
         - exec: sudo sed -i '1s/^/TERM=xterm-256color\n/' ~/.bashrc
-        - exec-host: "[ -d '.test' ] && ddev composer install"
-        - exec-host: "[ -d '.test' ] && ddev install all"
         - exec: mkdir -p .test && cp /var/www/html/.ddev/test/index.php /var/www/html/.test/
-
 webimage_extra_packages: [parallel]
 use_dns_when_possible: true
 composer_version: "2"
@@ -213,7 +210,7 @@ corepack_enable: false
 
 # disable_settings_management: false
 # If true, DDEV will not create CMS-specific settings files like
-# Drupal's settings.php/settings.ddev.php or TYPO3's AdditionalConfiguration.php
+# Drupal's settings.php/settings.ddev.php or TYPO3's additional.php
 # In this case the user must provide all such settings.
 
 # You can inject environment variables into the web container with:

Documentation/Miscellaneous/Development/CommandsList/Index.rst

@@ -55,9 +55,8 @@ Examples:
     ddev ci all
 
 
-.. tip::
-   You can use this command to fast switch with development to whatever TYPO3/PHP
-   version you like because after ci tests it does not return to previous TYPO3/PHP.
+You can use this command to fast switch with development to whatever TYPO3/PHP
+version you like because after ci tests it does not return to previous TYPO3/PHP.
 
 
 .. _development_commands_list_ddev_data:
@@ -70,11 +69,10 @@ When you do new features or write postman tests this is very likely that you wil
 need to do changes to database/files and commit this state to git.
 This command is just for that reason.
 
-.. note::
-    All TYPO3 testing instances are using the same exported files. This means that
-    there is no much difference if you make :bash:`ddev data export 13` or
-    :bash:`ddev data export 12`. Important is only that you do export from the
-    testing instance you actually modified.
+All TYPO3 testing instances are using the same exported files. This means that
+there is no much difference if you make :bash:`ddev data export 13` or
+:bash:`ddev data export 12`. Important is only that you do export from the
+testing instance you actually modified.
 
 
 .. _development_commands_list_ddev_docs:

Documentation/Miscellaneous/Development/TypicalUseCases/BugsFixing/Index.rst

@@ -14,21 +14,18 @@ Bugs Fixing
 
    Clone your forked repo locally.
 
-3. Run ddev
+3. Install and make init test
 
-   :bash:`ddev restart`
+   Go inside cloned repo and run: :bash:`ddev ci 12`
 
-4. Test CI locally
+   This will install project locally (for TYPO3 12) and make tests to check if your
+   installed version is working well before you start to modify it.
 
-   Check if project is working correctly before adding your changes.
-
-   Run: :bash:`ddev ci`
-
-5. Branch
+4. Branch
 
    Create branch in your repo.
 
-6. Fix bug
+5. Fix bug
 
    You can use existing integration testing instances under url:
    :uri:`https://[T3_VERSION].t3api.ddev.site` to make some fast manual testing
@@ -48,8 +45,7 @@ Bugs Fixing
       * https://12.t3api.ddev.site/_api/news/news/1
       * https://12.t3api.ddev.site/_api/news/categories
 
-
-7. Automated fixes and tests
+6. Automated fixes and tests
 
    If you think you are ready with your bug then:
 
@@ -60,6 +56,6 @@ Bugs Fixing
 
    * :bash:`ddev ci all`
 
-8. Commit and make PR
+7. Commit and make PR
 
    * :bash:`git commit -m "BUGFIX: Fixing bug"`

composer.json

@@ -42,7 +42,7 @@
 		"saschaegerer/phpstan-typo3": "^1.10.0",
 		"seld/jsonlint": "^1.10.2",
 		"symfony/yaml": "^5.4 || ^6.1",
-		"typo3/coding-standards": "dev-update-rules",
+		"typo3/coding-standards": "^0.8",
 		"typo3/testing-framework": "^7.0.4",
 		"webmozart/assert": "^1.11.0"
 	},