Documentation
- 1 Getting started
- 2 Integrated fundamentals
- 3 Content store
- 4 Blocks
- 5 Multi channel publishing
- 6 Storage
- 7 Themes and templating
- 8 Solr
- 9 Contributing
- 9.1 Guidelines and conventions
- 9.3 Integrated Branch Model
- 9.4 Make changes in existing bundles with a fork and pull request
- 9.5 Best practices
- 9 Social media
- 9 Users
9.1 Guidelines and conventions
Code requirements
- Code must meet the Symfony code standards and Symfony conventions, including PSR-2.
- Use of translation tags for text
- Use XML files instead of annotations. They are easier to override and have code completion
- Integrated controllers need to be registered as service and need to have PSR-7 support
- Use the short array notation: []
- Fully unit tested, except controllers, commands and views
Testing requirements
- Every controller action should have a Behat test
- Library code should have a unit test
Bundle requirements
- Bundles must be compatible with Composer and must contain a composer.json
- The Bundle must contain a LICENSE file in the root of the bundle
- The Bundle must contain a readme.md file in the root of the bundle, containing installation instructions
- Other developer documentation can be placed in the Resources/doc folder in .md files and/or submitted to integratedfordevelopers.com
- If the Bundle can be used by developers in other bundles, the following documentation is suggested:
- Introduction
- Description of functionality
- How to start
- Examples
Using third party code
The use of third party code need to be approved by the Integrated core team and should meet the following requirements:
- Dependencies can be managed with Composer (PHP) or Webpack (Javascript).
- The third party code is well maintained
- The third party code is Open Source and has a GPL-compatible license
Naming
- User singular names for collection and table names