How to contribute to eZ Publish using Git

CLA / coding standards

Make sure you have signed the CLA (Contributor Licensing Agreement), we cannot accept code contributions without it:
http://share.ez.no/community-project/contributor-licensing-agreement-cla. We are considering easier ways for you to sign it, but for now, a scan of the signed, printed-out version, sent through email to community@ez.no is good.

Also make sure you follow our coding standard to save time on several unnecessary review rounds. For instance, always use 4 spaces instead of tabs for indenting. Here are details:

PHP

For PHP you can follow the eZ Components / Apache Zeta Components coding standard : http://incubator.apache.org/zetacomponents/community/implementation.html
With some notable differences: class name prefix is ‘ezp’ for new classes, use ‘eZDebug’ for error, warnings, notices, strict errors and debug statements instead of ‘trigger_error’ and ‘Component configuration’ / ‘Directory structure’ does not really apply.

Also for exceptions, use with caution, a document / wiki is in the works to define exception hierarchy and it’s going to inherit from PHP/SPL exceptions. Make sure your code works on PHP 5.2 and up, and does not use deprecated functionality.

Templates

Make sure your html validates as html5 and xhtml traditional (in that order when they contradict each other), in the future we will most likely aim for xhtml5 (html5 using XML rules for simplified parsing). The template code itself should not use deprecated functionality and be properly indented.

CSS

Follow CSS 2.1 spec and only use CSS 3.0 for visual enhancements so there are no loss of functionality or major display regressions on older clients, including IE6.

JavaScript

Follow the official EcmaScript (ES) standard, do feature detection and not browser detection to fallback when browsers do not support [ES] features, but preferably use available functionality in jQuery or YUI which is already doing these things for you. Be unobtrusive (separate html and js code and enhance the html using general CSS selectors progressively meaning basic functionality is still maintained if it fails), and for jQuery / YUI3, use ezjscore.

Browser testing

We more or less follow Yahoos A-Grade browser list, with one exception, we don’t spend time on getting out interfaces to look the same in older browsers, it needs to be functional, but not pixel perfect.

As a simple rule test in latest stable version of FireFox, Chrome/Safari and IE in addition to IE 6.0. When IE 9.0 is stable start testing in that as well, but as it behaves closer to how upcoming FireFox / Web-kit versions do, it’s not as important to test as 6.0 and 8.0 (for now).

As for IE 6.0, attention to who your customers are should be taken, but in general we plan to stop testing in IE 6.0 for future products when it dips bellow 10% browser share, and for current products when it’s well bellow 5% if current browser share trends continue at the same pace. Considerations for testing on mobile browsers will be defined later, as the mobile browser market is much more fragmented, it will require a much larger discussion.