#Installing Neos Dev
Contributing to Neos is easier than ever! Thanks to the user-friendly interface of GitHub and the always active community on Slack we are happy to help you if you want to contribute some code, let it be bugfixes, features or other! Any help is appreciated!
Getting Started Screencast
We've prepared a screencast to help you get started with contributing to Neos. It will give you an overview about the structure of the Neos repositories and the intention behind it, as well as guide you on how to create your first pull request.
Neos on GitHub
All packages maintained by the Neos team are bundled in the Neos organisation on GitHub. It's members have read and write access to all repositories of the organisation and can create new repositories as needed. To keep things simple, there are no further teams or distinctions when it comes to permissions. The exception to prove the rule is the "Owner" role, which not everyone has. If there is anything you need which only an owner can do, contact us via #guild-ops in Slack.
The repositories on GitHub are your average git repositories and the usual way of working with them applies. Again, of course there is an exception. Some repositories for single packages (Flow, Fluid, Neos, Fusion and others) are marked as read-only. These exist only to "feed" Packagist to enable installation of those packages via Composer. The development of those packages happens in monolithic repositories for Flow and Neos we call "development collections". Pull requests (Github login required) are created against those and whenever something is merged the read-only repositories are updated automatically.
For instructions on specialized development environments based on docker like DDEV or Flownative Beach see Specialized Development Environment.
For instructions on how to install Docker on your system see Install Docker.
git clone email@example.com:neos/neos-development-distribution.git cd neos-development-distribution docker compose up
This will do the following things:
- Starts a database container in Docker
- Starts a PHP Neos container
- Runs Composer install in PHP container
- Install all
"neos/*"packages as source
- Install all
- Initializes database
- Creates Neos instance based on Neos.Demo with default settings
- Creates a admin user with username "admin" and password "password"
- Starts the Neos instance on localhost:8081
For detailed information have a look at:
/docker/Dockerfile : building the Neos Docker container image
/docker/entrypoint.sh : executed when container starts
/docker-compose.yml : Docker Compose setup
/Configuration/Development/Docker/Settings.yaml : default Neos Settings
Join a Code Sprint!
Even if you do not know any team members personally: Join a sprint! You will learn, meet us in person and hopefully have a lot of fun. Just imagine how easy problems get if there is always someone in the room to ask and discuss.
You want to known the details: scroll down to the basics section for the required tools and frameworks.
You want to get your hands dirty first: read ahead!
Setup a local Web Server
- Install MySQL or PostgreSQL
- Install PHP according to our requirements
Checking out the Code Base
mkdir -p /your/local/path cd /your/local/path git clone https://github.com/neos/neos-development-distribution.git cd neos-development-distribution curl -s https://getcomposer.org/installer | php php composer.phar install ./flow server:run & echo "Open http://localhost:8081/setup and follow the instruction on the screen"
Check out our online documentation if you want to know what the commands do.
- Create a Fork
- git remote add fork firstname.lastname@example.org:your-github-fork
- Branch off for every PR you want to create
- git checkout -b dev-your-new-feature-or-bug-fix
- this keeps the version branches within your fork "clean"
- put "fixes #1234" into the PR message body (helps identifying)
- so, the 'third-party-contribution' is more identifiable/isolated for whatever happens after initial PR ...
- Checkout the lowest maintained version (concerned by your issue)
- do your changes in the lowest maintained branch, - NOT in the master
- --> Release Roadmap
- Make your changes
- Coding Guide Lines: COMMIT messages
- git commit -m "a nice message"
- Push fork
- git push fork
- Create a PR (=Pull Request)
- Eventually ToDo's after the successful merge
- merged branch can be deleted in 'my fork'
- "close" the related issue (if not already done automatically)
- "don't touch" already closed PRs (#xxxx which were errored) as they are in the main branches ...
To have a clear and focused history of code changes is greatly helped by using a consistent way of writing commit messages. Because of this and to help with (partly) automated generation of change logs for each release we have defined a fixed syntax for commit messages that is to be used.