Contributing to the Zend Framework – Getting Started

Read the Zend Framework License

The license is BSD based and can be found at http://framework.zend.com/license.

Sign a Contributor License Agreement

To contribute source code or documentation into the framework at any level (from a few lines, through a patch, to a full set of classes), you must first sign the Contributor License Agreement. This will also give you access to become a developer in the issue tracking system and the developer's wiki.

Subscribe to the appropriate mailing lists

Also note that [RSS feeds and custom event notifications] are available from our systems.

Review the Coding Standards

All framework code is covered by the [Zend Framework PHP Coding Standard]. Learn them, love them, live them.
Please "watch" the page above using the "envelope" icon on the upper right side of the page. The Confluence Wiki has a robust email notification system, accessed through your "Preferences" after logging in. From there, click on the "Watches" folder tab, and see the link to "email preferences".

Learn PHPUnit

Development in the framework is backed by extensive unit testing. We use PHPUnit extensively as our testing framework. For code to be accepted, it must be tested and covered by a unit test.

Developers are expected to keep documentation and unit tests in sync with changes to code.

Contribute to the Wiki

Review and Submit Proposals

Proposals are contributed by developers and end-users of the Zend Framework. Our proposal wiki space shows the current status of proposals and manages the review process. Submit new proposals here, or help review other submissions as part of our collective intelligence.

Report, work on, resolve issues in the Issue Tracker

The Zend Framework Issue Tracker is the place to submit issues of all types. This includes bugs, change requests, feature requests (if large enough, they could be submitted as a proposal), and small patches. It is also the place to track the release roadmap and view the current status of framework components.

Please read the [Zend Framework Issue Tracker Etiquette] before working on issues.

Review SVN Commits

As code comes into SVN, it is displayed in our Fisheye browser with the change sets listed with full diffs. Review commits and double check the work of others. The more eyes, the better. This is also a great way to get a feel for the framework coding style and culture.

Contribute Code

Code can be submitted as patches (via the issue tracker), or directly to SVN. See user-contributed notes for how to make patches. Component leads and significant contributors are given direct access to the SVN repositories. If you find yourself constantly submitting patches and having the need for greater access, ask and your request will be considered. Please read the [Zend Framework Subversion Standards] before submitting new code via SVN.

Best Practices

Common Sense

• API changes should be committed in parallel with updated documentation.

Factory Methods, Classes, and Patterns

For the following, we define "factory" as a class or method that creates instance objects of one or more classes other than the class of the factory.

Direct instantiation is the preferred choice, and factory classes should be avoided by default, and used only when sufficient need exists.

Sometimes the code in a factory method could be moved to a common, shared superclass.

Container API

For now, we decided to avoid trying to micro-manage implementation details of ZF classes with containers to suit potential points of reuse throughout the framework. Zend_Session, for example, must wrap a nested PHP array ($_SESSION), not the recursive data structure found in Zend_Config. In a few months, we can revisit and discuss whether implementations of existing ZF classes with container data structures should be refactored.

Instead, we would like to propose API conventions to maintain consistency in style for accessing and manipulating container objects by following the example set in Zend_Config.

When getting and setting data in the container, we have some basic operations:

• get
• set
• isset
• unset
• iteration
• counting

Containers should implement the standard PHP Countable and Iterator interfaces.

Intermixing "$object->propName" with "$object->get('propName')" styles can lead to confusion. Pick one and be consistent. Also, if "propName" is not a valid PHP identifier (e.g. contains whitespace or UTF-8), use the "->get" / "->set" style. Due to the international "flavor" of ZF, please carefully consider whether those speaking other languages will need to use "get($propName)" and "set($propName, $value)".

Note: This section discusses accessing items in a container data structure, not other properties of the object wrapping the container. Thus, accessor methods for these other properties might have different requirements, like defined extension points should be represented by normal functions to access the properties they encapsulate.