Contributing
Target group: Contributors
Thank you for considering contributions! You can contact us with any questions.
Documentation
You are welcome to help improve this guide. Just click on "Edit me on GitHub" on the top right to submit your improvement via a Pull Request.
Translations
Translations are managed on the official TYPO3 translation platform. See Translation.
Feedback
Any problems? You miss a feature? There is an incompatibility? You have strategic input?
Please open an issue at our Github repository after you have read the documentation.
Code (Templates, JavaScript, PHP)
We are happy to receive pull requests.
Branches
We use one branch for each stable TYPO3 API version. This model is not followed by many extensions.
It allows us to
focus on that API only and not worry about compatibility constructs or inabilities to incorporate any new
TYPO3 feature. So absolutely no if in cookieman.
Also it simplifies testing, as each version might need a different setup.
After switching branches, you might need a git clean - to remove any ignored files which were
created by another version's build (append -e '!. to exclude .idea).
Supported TYPO3 versions
- all LTS versions: features, bugfixes, security
- ELTS versions: security
Exceptions can be made if Pull Requests are provided.
We strive to support the latest version, too (but no promises).
Releases
Releases follow semver. Including with composer via dmind/ shall never
break any documented feature or the input or output of any function marked with @api in the code.
Be sure to shoot us an angry message if we messed up!
We usually release for all maintained TYPO3 APIs at the same time and use consecutive patch versions (e.g. 2.2.3, 2.2.4, 2.2.5), each supporting one.
Create a new release
Before creating a release you should merge the automatic Crowdin PRs until TYPO3v9 (in v10+ translations are Crowdin-only, for earlier versions we distribute them because we were not on the older "poodle" server).
The DDEV host command ddev release <version, e.g. 2.5.7> will create a release commit and an annotated Git tag. It expects that you have set up Git for signing commits (git config --get user.signingKey).
Pushing the tag with git push --tags makes the new release available for composer (packagist). It also triggers the Github Actions workflow "publish-ter" which uses the TER API via "tailor" to publish the new release to TER.
Commits
We loosely follow the commit message style of conventional commits.
Run locally
ddev start && ddev launch will install a TYPO3 with example content and cookieman. This installs helper extensions that automatically enable a certain theme and some TypoScript setup to facilitate development. The admin user is "admin", password "aaAA11!!".
The ddev custom command ddev install-git-hooks installs CGL checkers as pre-commit hooks (only tested on Linux so far - the script runs under the container environment so good chances that this would work for other OSs as well).
To throw away the database and restart cleanly, run ddev delete -Oy && git clean -fdX -e '!.idea' && ddev start
Run in Gitpod
Thanks to https://drud.github.io/ddev-gitpod-launcher/, we are able to develop on cookieman with DDEV in the cloud.
This link opens the cookieman development environment in Gitpod.
Composer scripts
Have a look at the composer.'s script section. This is the main entry point for commands needed
during development.
- ddev composer cookieman:... enables an official cookieman theme. The "customtheme" shall resemble an integrator following our documentation.
- ddev composer build generates minified JS/CSS.
- ddev composer test runs all important tests. You do not strictly have to run tests before opening a pull request - they are also run post-commit on Github actions.
- ddev composer fix:cgl tries to fix linting problems.