The first stable version of the eZ XML Installer has just been released.

Please look here for details.

Please look here to download and test the new release.

Xdebug's CVS server was previously hosted at eZ Systems' office, but as I am leaving soon I needed to move this to a different server. At the same time, I decided to also convert from CVS to SVN. So from now on, there is no more cvs.xdebug.org, but just a svn.xdebug.org. This SVN server doesn't only host Xdebug, but also some of my other projects, such as VLD (opcode dumper to aid PHP engine development), the DBGp specs (debugger protocol as used by Xdebug and ActiveState's debuggers) and my OpenMoko perversions and projects.

Xdebug can now be checked out from SVN with:

svn co svn://svn.xdebug.org/svn/xdebug/xdebug/trunk xdebug

All other Xdebug services (mailinglists, web, e-mail and the bug system) moved to the same server as well. Just be aware that DNS servers might still need updating when you try to access the new services.

The big new feature of the roadmap of eZ Publish 4.3 is a new admin interface. The work on it has started with a requirements document and a prototype of a page (download it locally if you want to see it in your browser). jQuery is used in the prototype, I don't know if it's a definitive choice, but as I have already said on that topic, a choice of a framework is better than no real choice (even if jQuery is not my preferred JavaScript framework). I think that most of the big needs are already covered in the document but there are some small details that miss in the current admin interface that I would like to see in the future one :

• Labels of each field should be linked to their related input with the for attribute. That's a very small addition but I find it more than useful in web applications.
• The focused input should be highlighted with a different colour. This is another very small improvement which can greatly improve users experience.
• Buttons in the admin interface should be of a different colour depending on the action they trigger. For instance cancel buttons can be orange, publish buttons blue, remove buttons red, ... The main key here is to be consistent over all the interface.

The edit interface of each datatype should also be considered individually to provide the best interface. For instance, the edit template of a datetime attribute should provide a JavaScript calendar (like with the ezwebin package), the template of a time attribute a button to fill inputs field with the current time, the keyword datatype an autocomplete input (like with the ezkeywords_autocomplete extension), ... Beside an advanced edit interface for each attribute, the data entered in the edit form should also be checked with JavaScript (required or not, valid syntax, ...). In case of errors, fields that do not validate should be highlighted with a message until a new valid value is entered. Obviously, if JavaScript is disabled, a server side check should do the same thing. On this topic, there's also a very old feature request in the issue tracker about the ability to add an help text in the class definition that would be displayed under the edit interface of the attribute.

Finally, a great improvement would be to apply general rules on performances frontend. I think of packing and minifying CSS et JavaScript files (with ezjscore !), using CSS Sprites for design images and use optimized PNG files instead of GIF files. This would improve the user experience by speeding up response time and making the admin interface usable with a slow Internet line

Highlights:

• storage dirs are now analyzed for total size and file count
• same for all cache types
• orders in the shop are also monitored
• the cli script has got a couple of new options to be more friendly than ever
• for the first time, a plugin for a monitoring tool is included: PRTG

First alpha release of eZ Cache Manager extension is available.

eZ Cache Manager was made to finetune compiled cache management. eZ Publish only provides full compiled cache flush. It means that it is only possible to delete all the compiled templates or the user info cache file.

First release allows to delete cache file one at a time in the admin siteaccess, no need to flush files with a ftp or ssh connection. jQuery framework is needed with this alpha release.

You can anonymously check out the source code released by this project from its Subversion repository : svn checkout http://svn.projects.ez.no/ez-cache-manager

We are waiting for your feedback.

Recently people started to ask me how to use Xdebug to figure out which parts of applications use a lot of memory. Traditionally this was part of Xdebug's profiling functionality. Unfortunately the cachegrind format didn't fit this so well, and because it returned incorrect data I removed this functionality from the profiler. However, there is other functionality in Xdebug that does provide the correct data: the function traces.

Function traces log every include, function call and method call to a file. If the xdebug.trace_format setting is set to "1" then the trace file is an easy-to-parse tab separated format. The information that is logged includes the time-index when the function started and ended, and it also contains the amount of memory that was in use when entering the function, as well as when leaving it. With the last two numbers it's rather trivial to write a script to figure out which functions/methods increase the memory usage a lot. Of course, nobody had written a script yet to do anything with this information

As part of my preparations for my Xdebug talk at IPC next week, I now have written such a script. The script parses the tab-separated function trace files and aggregates all the information by function name. You can sort the output on a few different keys: time-own, memory-own, time-inclusive, memory-inclusive and calls. You can also configure how many elements it will show. As an example here is some output from a trace of one of the presentation system's PHP scripts:

$ php tracefile-analyser.php trace.2043925204.xt memory-own 20

parsing...
Done.
Showing the 20 most costly calls sorted by 'memory-own'.
                                               Inclusive        Own
function                               #calls  time     memory  time     memory
-------------------------------------------------------------------------------
require_once                                9  0.0541  4595160  0.0277  2548104
{main}                                      1  0.0600  2906032  0.0034   249744
fread                                       4  0.0001    33296  0.0001    33296
session_start                               1  0.0002    31824  0.0002    31824
XML_Presentation->startHandler             38  0.0073    36360  0.0035    18424
_pres_slide->_pres_slide                   27  0.0009    10152  0.0009    10152
_presentation->_presentation                1  0.0001     7912  0.0001     7912
strtolower                                 67  0.0017     6456  0.0017     6456
compact                                     1  0.0000     4832  0.0000     4832
each                                        5  0.0001     4320  0.0001     4320
XML_Presentation->endHandler               38  0.0014     3800  0.0014     3960
_slide->_slide                              1  0.0001     3896  0.0001     3896
XML_Slide->startHandler                     4  0.0009    10800  0.0004     3736
_image->_image                              1  0.0000     3040  0.0000     3040
fopen                                       2  0.0001     2816  0.0001     2816
getimagesize                                1  0.0001     2296  0.0001     2296
display->display                            1  0.0001     2120  0.0001     2120
explode                                     2  0.0001     2120  0.0001     2120
xml_parser_create                           2  0.0001     1680  0.0001     1680
XML_Parser->_initHandlers                   2  0.0011     1600  0.0005     1360

The script is available from CVS by running:

cvs -d :pserver:cvsread@cvs.xdebug.org:/repository login
(pw = srmread)
cvs -d :pserver:cvsread@cvs.xdebug.org:/repository co xdebug/contrib

The script to run is then "tracefile-analyser.php" from inside the "xdebug/contrib" directory.

eZMailHide Alpha 0.1 is waiting for your feedbacks !

eZMailHide extension helps you protect your customers inboxes from spamming by asking anonymous users to solve a reCAPTCHA challenge before they can view any email address published by the content management system of eZ Publish.

You can anonymously check out the source code released by this project from its Subversion repository : svn checkout http://svn.projects.ez.no/ezmailhide

A Zip file is also available here : http://projects.ez.no/ezmailhide/downloads