This site has been archived. To learn more about our current products Ibexa Content, Ibexa Experience, Ibexa Commerce head over to the Ibexa Developer Portal

eZ Community » Learn » eZ Publish » How to contribute to eZ Publish using...

How to contribute to eZ Publish using Git

Tuesday 01 March 2011 10:07:20 pm

  • Currently 5 out of 5 Stars.
  • 1
  • 2
  • 3
  • 4
  • 5

CLA / coding standards

Make sure you have signed the CLA (Contributor Licensing Agreement), we cannot accept code contributions without it: 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 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:



For PHP you can follow the eZ Publish 5.x coding standard and you can setup your IDE (for example PHPStorm) or use PHP CodeSniffer directly using
Note that there are some notable differences for "ezpublish-legacy": 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.3 and up, and does not use deprecated functionality in 5.5.



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 usedeprecatedfunctionality and be properly indented.



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 IE9.

For CSSLint setup, see



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 in ezpublish-legacy for ajax calls.

For JSHint setup, see


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 muchmorefragmented, it will require a much larger discussion.

36 542 Users on board!

Tutorial menu


Printer Friendly version of the full article on one page with plain styles


Proudly Developed with from