- Issues
- Feature Requests
- Submission Guidelines
- Coding Rules
- Git commit message conventions
- Specific contribution rules for t3kit
If you find a bug in the code or a mistake in the documentation, you can help us by submitting an issue to our GitHub repository, or even better you can submit a Pull Request with a fix.
Please follow the Submitting an Issue Guidelines
You can suggest new feature by submitting an issue to our GitHub repository, or even better you can implement a new feature and add Pull Request with your changes.
Please follow the Submitting a Pull Request Guidelines
Before you submit your issue please check that you've considered the following steps:
- Check duplicates - use the search feature to ensure that the bug hasn't been reported before.
- Check dependencies - make sure you're on the right version of dependencies.
- Issue description - Included as much information about the bug as possible.
- Browsers and devices - check out browser and device support for t3kit
- Suggestions - if you can't fix the bug yourself, perhaps you can point to what might be causing the problem (line of code or commit)
Before you submit your pull request please check that you've considered the following steps:
- Check documentation about Pull Request in Github
- Search in GitHub for an open or closed Pull Request that relates to your submission.
- Follow our Coding Rules
- Follow our Git commit message conventions
- Follow Specific contribution rules for t3kit
- Make your changes in a new git branch:
git checkout -b my-feature master
- Compile your changes locally to ensure that your fix/feature is not causing new bugs. Test it. Push your branch to your forked GitHub repo:
git push origin my-feature
- In GitHub, send a pull request to original repository.
- Write a convincing description of your PR and why we should land it.
After your pull request is merged, you can safely delete your branch and pull the changes from the main (upstream) repository
- Delete the remote branch:
git push origin --delete my-feature
- Check out the master branch:
git checkout master
- Delete the local branch:
git branch -D my-feature
- Update your master with the latest upstream version:
git pull upstream master
- t3kit project uses specific code rules and style guides. Those rules you can find in appropriate files on the root of project or in submodules:
.jscsrc
.jshintrc
.htmlhintrc
.csslintrc
.editorconfig
- Also for TYPO3 extensions keep in mind TYPO3 CMS Coding Guidelines.
Each commit message consists of a label and short message.
Also it is possible to use special keywords for closing Github issues or pointing to another issue tracker. For example to pointing commit with bug report or feature request from Podio need to add this keywords at the end of the message: (Podio bug_21), (Podio feature_12)
Please use semantic labels for your messages, but if commit message is not very important, you can skip labels. All commits with labels will be added in CHANGELOG file, that's why it is important to use predefined labels on your commits.
- [FEATURE] - A new feature
- [BUGFIX] - A bug fix
- [CLEANUP] - A coding style fixes, compliance etc
- [TASK] - Refactoring and similar, including performance
- [TEST] - Adding missing tests
- [DOC] - Documentation only changes
- [!!!] - Breaking Changes
- [WIP] - Work in progress tag, should not be present when creating pull requests
- [SECURITY] - To mark important updates, when evaluating when we should update older sites
Important: Commit label must be only one, except if it Breaking Changes, then we will need to add "Breaking Changes" label
[!!!]
plus one more label.
For example (Breaking Changes):
[!!!][BUGFIX] disable custom.js in t3kit
- Use the imperative, present tense: "change" not "changed" or "changes"
- don't capitalize first letter
- no dot (.) at the end
- Use existing less variables for defining colors and some dimensions. Better to avoid creating new less variables, because it will cause changes in Theme extension. Check
customVariables.less
file.
dev/styles/customVariables.less
- Keep your changes easily updatable according original code. It should be easy to update old sites with your changes.
- Your code should work with multi-site/multi-language
- Your code should work with the current Theme of t3kit
- Use Theme variables and TS constants
- Keep your changes easily updatable according original code. It should be easy to update old sites with new changes.
- Do not modify any existing default behaviour for backend users.
- Your code should ship with correct access rights for backend user groups defined in t3kit (might need update of t3kit_db)
- Desktop browsers: IE11, Microsoft Edge, Chrome, Firefox, Safari
- Tablets & Phones: iOS 9+, Android 4.4+