Setting up a core development environment
This document is intended to be a place to collect useful techniques for developing the Zikula Core.
First, it is required that you set up the basic git repository.
This is only done once for each project you wish to contribute to.
In this example we'll fork the github.com/zikula/core repository. 'zikula' is the Github username, and 'core' is the repository name. We're using 'zikula/core' to refer to this repository. If you are contributing to another repository, say github.com/foo/bar then simply replace the username and repository accordingly, e.g 'foo/bar'.
Simply fork the project repository https://github.com/zikula/core by pressing the
fork button on the website.
Now setup the local repository:
git clone -o zikula git://github.com/zikula/core.git
Add your fork as a remote:
cd core git remote add <your_username> email@example.com:/<your_username>/core.git
'core' points to the main Zikula repository. The remote called 'your_username' points to your fork. Using this naming makes it easier for you to know which repository you are referring to. If you are already fluent with GIT you may choose any remote naming schema you prefer.
Keeping your code up to date with rebase:
git fetch git rebase master zikula/master git rebase 2.0 zikula/2.0
Your public fork's only purpose is to public your patches, there is absolutely no reason to push your local
master branch (or other branches present in the central repository you have forked from).
We use rebase to prevent unnecessary merge commits when synchronising with the upstream repositories. It rewinds your work, updates from the central repository, then replays your work on top. This keeps a linear, logical history.
debug and set kernel environment to
If not already configured, it is recommend to set the kernel environment to
dev and set
debug to true. To do so, adjust the parameters in your
Emails are always difficult to handle during development, especially if you want to test a module sending lot's of them, i.e. a newsletter module. Of course you don't want to spam other peoples inboxes, and always use your own email address instead. But this leads to problems when your module only allows unique emails. To overcome this problem, follow the instructions in the official Symfony documentation and either disable sending completely or redirect all emails to your development email address.