...where the 1234 is the bug ID from Bugzilla. This allows Bugzilla to track back to the commits made in that entry and helps us assemble release notes consistently.

...where the 1234 is the bug ID from Bugzilla. This allows Bugzilla to track back to the commits made in that entry and helps us assemble release notes consistently.

+

+

=== PKP library submodule changes ===

+

+

If you changed something in library, you will also need to commit the library submodule changes in the application repository. This is necessary especially for our continuous integration structure. Basically, the submodule changes commit will tell anyone that pulls the application code where the submodule repository HEAD is, including the CI script.

+

+

This is needed because the CI script is prepared to get the library from PKP's official repository. In case of a pull request from a developer, we need to tell the CI script to also update the library with commits from the developer's library repository. That way the CI tool can correctly build and test your pull request code before merging. To make that happen, do the following:

+

+

* create your commits normally, both for application and library;

+

* if you have library commits, commit the submodule changes, at the application repository, in an UNIQUE separate commit, making sure that it is the HEAD:

+

<pre>

+

git add lib/pkp

+

git commit -m '*1234* Any message here ##githubUser/branch##'

+

</pre>

+

1234 is the bug ID;

+

githubUser is your github user;

+

branch is the branch in your github repository where the library commits are;

+

* make sure your local application and library repositories are updated with the official, as it is expected if you want to do a pull request;

+

* push both library and application commits to your repository in github;

+

+

After doing this, you can create a pull request using the GitHub interface, and check the CI build result. If it doesn't pass, you can read the logs, see the errors, fix the code and update your pull request by pushing your code to your own repository again.

Managing Contributions

PKP code development, including external contributions, is managed between Bugzilla and Github. We prefer that issues be opened as either bugs or feature requests in Bugzilla, and that fixes are submitted as pull requests via Github, but we do still accept patches uploaded to Bugzilla itself if you do not want to submit via Github pull request.

Identifying an Issue

You can access our Bugzilla database here. We welcome any bug reports and feature requests, so long as they are understandably written and flagged correctly (mostly an issue of setting the severity between enhancement; trivial; minor; normal; major; critical; or blocker levels, although you can also set the priority as well if you'd like). You can see a great set of bug-writing guidelines here.

You are also advised to search for similar reports to avoid duplication.

To contribute code back to us, feel free to submit a pull request from git.

If you are working against a particular entry in our Bugzilla database, use the following format for commit messages:

*1234* My Commit Description

...where the 1234 is the bug ID from Bugzilla. This allows Bugzilla to track back to the commits made in that entry and helps us assemble release notes consistently.

PKP library submodule changes

If you changed something in library, you will also need to commit the library submodule changes in the application repository. This is necessary especially for our continuous integration structure. Basically, the submodule changes commit will tell anyone that pulls the application code where the submodule repository HEAD is, including the CI script.

This is needed because the CI script is prepared to get the library from PKP's official repository. In case of a pull request from a developer, we need to tell the CI script to also update the library with commits from the developer's library repository. That way the CI tool can correctly build and test your pull request code before merging. To make that happen, do the following:

create your commits normally, both for application and library;

if you have library commits, commit the submodule changes, at the application repository, in an UNIQUE separate commit, making sure that it is the HEAD:

1234 is the bug ID;
githubUser is your github user;
branch is the branch in your github repository where the library commits are;

make sure your local application and library repositories are updated with the official, as it is expected if you want to do a pull request;

push both library and application commits to your repository in github;

After doing this, you can create a pull request using the GitHub interface, and check the CI build result. If it doesn't pass, you can read the logs, see the errors, fix the code and update your pull request by pushing your code to your own repository again.

Contributing Patches

If you cannot or do not want to contribute via Github, you can upload patches directly to bug reports. We're always happy to receive patches, whether for contribution to a project or for general community availability on the forums. The one thing we do ask is that you provide the patch in Unified Diff format. If you are using our git instructions to work with the application codebase (highly recommended), you can create unified diffs via git using the following command:

git diff -u ./ > patch.diff

... which will find all differences in the working directory and recursively, and write them to a file called patch.diff.

Applying Patches

Patching Manually

If you want to apply a patch manually, whether from Bugzilla or from Github, download it to your development environment, and from the application's root directory and run

patch -p0 < ./path/to/patch.diff

The --dry-run option to the patch tool allows you to safely test the patch to see if it will apply cleanly, and if not, where the conflicts will arise.

Next, make sure your local repository is up to date (NB that this does not automatically merge all new remote commits to your repository, it just stores them locally):

git fetch

Then, cherry-pick the commit you want to apply by hash:

git cherry-pick 4aba081d35133c1ee9a9e1f3b9166ca5db5fd48d

Setting up a flexible development environment

NB: This is not a beginner's installation/configuration tutorial. We only highlight a few important differences from a standard installation as a help for experienced PKP, database, PHP and web server users.

Install and Configure Databases

There is nothing special to the database installation. Use your OS' standard installation procedure to install the necessary databases you want to test in parallel.

Edit config.inc.php to switch the database connection.

Install and Configure supported PHP versions

Download or build the PHP binaries you want to test (newer versions can be downloaded from php.net or are part of the standard OS distributions, older versions must be built from source).

You'll need the thread-safe version if you want to test mod_php in Apache.

Install all binaries and configuration separately. Do not create any shared files or configuration (separate php.ini, separate installation directories).

On Windows:

Get the PHP zip arquive distributions where available and unzip them into separate folders.

XAMPP has lots of old Windows binaries if the version you look for is no longer officially supported on php.net.

Download the thread-safe VC6 version as VC9 versions are not compatible with Apache.

Do not install DLL files in C:\WINDOWS or any other directory on the path.

Do not install any registry keys.

Do not configure any shared environment variables.

Exception: Install PEAR in a central folder that is accessible by all PHP versions. Install necessary PEAR dependencies (e.g. PHPUnit, etc.) - see separate documentation on this Wiki for that.

Edit the development php.ini files as required:

extension_dir must point to the absolute path of the version specific extension binaries

Install and Configure Apache

We use Apache so that we can test CGI, FCGI and Module configurations in parallel. Install Apache 2.2 (standard distribution for your OS). Then get and install mod_fcgid as explained on the linked web pages.

All the magic lies in Apache's httpd.conf. Here's the Windows version. It should be easy to adapt that to your specific OS: