menu

Neos Core

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.

Quick Start

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.

Start Coding

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
  1. Install MySQL or PostgreSQL
  2. 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.

Basics

If you want to start to program you should get roughly familiar with the used tools and programming languages. Note that PHP is used on the backend, and JavaScript for the in-place editing UI.

Programming Languages

Development Tools

  • git to synchronize file changes with others
  • github.com as git platform
  • hub to easy access github from the command line
  • composer for managing dependencies between different packages in different git repositories
  • npm / nvm to manage JavaScript dependencies

Contribution Workflow

Contribute Changes

  1. Create a Fork
    • git remote add fork git@github.com:your-github-fork
    • https://help.github.com/en/articles/fork-a-repo
  2. 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 ...
  3. Checkout the lowest maintained version (concerned by your issue)
    • do your changes in the lowest maintained branch, - NOT in the master
    • --> Release Roadmap 
  4. Make your changes
    • feature
    • bugfix
    • ...
  5. Commit
  6. Push fork
    • git push fork
  7. Create a PR (=Pull Request)
  8. 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 ...

Style Guides

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.