• Search:



Planet eZ publish




granite horizon

› Overview of Document History in Nuxeo: Event Log and Archived Versions

Nuxeo is an ECM system. Nuxeo keeps track of a document's history, tracking important facts about the document's creation and about each edit.
24/04/2015 2:17 am (UTC)   http://granitehorizon.com/blog   View entry   Digg!  digg it!   del.icio.us  del.icio.us

granite horizon

› 5 Great Features in Nuxeo Studio

Nuxeo Studio is an online service that provides a vast array of features to help users manage their enterprise content better in Nuxeo Platform.
22/04/2015 12:07 am (UTC)   http://granitehorizon.com/blog   View entry   Digg!  digg it!   del.icio.us  del.icio.us

ez publish community gateway

› What to Expect from the eZ Publish Summer Camp 2015

A few weeks ago, we at Netgen announced the location and the dates of the 4th eZ Publish Summer Camp. It will be held at the same place (Rovinj, Croatia) and one week earlier than last year (August 26-29).

17/04/2015 9:05 am (UTC)   http://share.ez.no   View entry   Digg!  digg it!   del.icio.us  del.icio.us

netgen

› March @ Netgen

March was a great month for us - our hard work finally started to pay off. We definitely earned the long weekend we have had :)

07/04/2015 1:10 pm (UTC)   http://www.netgenlabs.com/Blog   View entry   Digg!  digg it!   del.icio.us  del.icio.us

derick rethans

› Xdebug 2.3: Shared Secret to Enable Tracing or Profiling

Xdebug 2.3: Shared Secret to Enable Tracing or Profiling

This is the sixth article in a series about new features in Xdebug 2.3, which was first released on February 22nd.

Xdebug's profiling and trace file capabilities can both be triggered by a cookie, GET or POST variable, as long as you have enabled xdebug.profiler_enable_trigger and/or xdebug.trace_enable_trigger. With these triggers enabled, basically anybody could initiate a profile run, or trace file, by simply sending the XDEBUG_PROFILE or XDEBUG_TRACE cookies with an HTTP request.

Although you should not really run Xdebug in production, you can see that this is not an optimal solution.

Xdebug 2.3 adds supports for shared secrets for the trace file and profiler triggers through the xdebug.trace_enable_trigger_value and xdebug.profiler_enable_trigger_value. If these settings are changed from their default (empty string), then the value of XDEBUG_PROFILE needs to match the value of xdebug.profiler_enable_trigger_value, and the value of XDEBUG_TRACE needs to match the value of xdebug.trace_enable_trigger_value in order for the profiling to start, or the trace file to be generated.

Often users would use one of the browser extensions for triggering profile runs or enabling tracing, these extensions need to be updated. The author of The easiest Xdebug, Nikita Nikitin, managed to get an updated version out before I could complete this article. It now has support for supplying your own values for XDEBUG_TRACE and XDEBUG_PROFILE:

The other two browser helpers have not been updated yet. I have emailed the author of Chrome's Xdebug helper, and I have filled an issue for Safari's xdebug-helper-for-safari on Github. Let's hope they get updated soon too.


Other parts in this series:

07/04/2015 10:13 am (UTC)   Derick Rethans   View entry   Digg!  digg it!   del.icio.us  del.icio.us

ez publish community gateway

› eZ Community Board meeting minutes - March 25, 2015

Here are the minutes of the latest Community Project Board meeting, March 11 2015. Our previous minutes can be found here.

31/03/2015 6:29 pm (UTC)   http://share.ez.no   View entry   Digg!  digg it!   del.icio.us  del.icio.us

derick rethans

› Xdebug 2.3: Improvements to Tracing

Xdebug 2.3: Improvements to Tracing

This is the fifth article in a series about new features in Xdebug 2.3, which was first released on February 22nd.

In this instalment we are going to have a look at the additions to the trace file functionality. Trace files are a way to document every function call, and if you enable it, variable assignment and function's return values — including when these functions were called, and how much memory PHP was using at the moment of function entry (and exit).

Xdebug 2.3 adds a new type of parameter rendering for stack traces and function traces through the xdebug.collect_params setting. Existing options are 1/2 for just the variable type, 3 for a string description, and 4 for a string description and a variable name. Xdebug 2.3 now also features a base64 encoded serialized representation of the variable's contents (option 5). Which means that the following lines:

$a = array(1, "foo", M_PI);
var_dump($a);

show up in the following 5 ways with different variations of the xdebug.collect_params setting:

  1. var_dump(array(3))

  2. var_dump(array(3))

  3. var_dump(array (0 => 1, 1 => 'foo', 2 => 3.1415926535898))

  4. var_dump(array (0 => 1, 1 => 'foo', 2 => 3.1415926535898))

  5. var_dump(YTozOntpOjA7aToxO2k6MTtzOjM6ImZvbyI7aToyO2Q6My4xNDE1OTI2NTM1ODk3OTMxO30=)

This is probably more useful with the computerized trace files that are easier to parse.


In Xdebug 2.3, normal (human readable) trace files now also show the time index and memory usage for function exit lines. Function exit lines are generated when xdebug.collect_return is set to 1. Which means that with with Xdebug 2.2 you would see:

TRACE START [2015-03-28 18:48:39]
  0.0008     275928   -> test1() …/closure-trace.phpt:27
  0.0008     276848     -> {closure:…/closure-trace.phpt:20-22}() …/closure-trace.phpt:24
  0.0009     277168       -> strlen() …/closure-trace.phpt:21
                           >=> 3
                         >=> 3
                       >=> NULL
  0.0010     276056   -> xdebug_stop_trace() …/closure-trace.phpt:28
  0.0010     276184
TRACE END   [2015-03-28 18:48:39]

But in Xdebug 2.3 you instead see:

TRACE START [2015-03-28 18:48:45]
  0.0008     269144   -> test1() …/closure-trace.phpt:27
  0.0009     270096     -> {closure:…/closure-trace.phpt:20-22}() …/closure-trace.phpt:24
  0.0009     270336       -> strlen() …/closure-trace.phpt:21
  0.0010     270504        >=> 3
  0.0010     270216      >=> 3
  0.0010     269264    >=> NULL
  0.0011     269264   -> xdebug_stop_trace() …/closure-trace.phpt:28
  0.0011     269384
TRACE END   [2015-03-28 18:48:45]

This makes it easier to see how much time and memory a specific function call took, similarly to what already was shown for "computerized" trace files.


And lastly, the computerized format (xdebug.trace_format=1), has now support for showing return values as well. The return value is part of a new "frame" for a function.

Take the following invocation of PHP:

php -dxdebug.collect_params=0 -dxdebug.collect_return=1 \
        -dxdebug.trace_format=1 \
        -r '$a = array(1, "foo", M_PI); xdebug_start_trace("/tmp/trace"); echo
        serialize($a);' \
>/dev/null && cat /tmp/trace.xt

In Xdebug 2.2 this shows:

TRACE START [2015-03-29 00:08:34]
2    1    1    0.000417    267192
2    2    0    0.000547    266848    serialize   0   Command line code   1   1   array (0 => 1, 1 => 'foo', 2 => 3.1415926535898)
2    2    1    0.000626    267024
1    0    1    0.000695    266968
               0.000925    8536
TRACE END   [2015-03-29 00:08:34]

But Xdebug 2.3 has an extra "return frame" with the return value:

TRACE START [2015-03-29 00:10:11]
2    1    1    0.000462    263152
2    2    0    0.000520    262928    serialize   0   Command line code   1   1   array (0 => 1, 1 => 'foo', 2 => 3.1415926535898)
2    2    1    0.000594    263096
2    2    R                          'a:3:{i:0;i:1;i:1;s:3:"foo";i:2;d:3.1415926535897931;}'
1    0    1    0.000676    263040
               0.000881    8512
TRACE END   [2015-03-29 00:10:11]

Function 2 (the call to serialize) now has an entry frame (0) and exit frame (1) showing the time index and memory usage, as well as the new R frame showing the return value. Unlike human readable traces it is not on the same line as the exit frame because of backwards compatibility reasons.


Other parts in this series:

31/03/2015 10:12 am (UTC)   Derick Rethans   View entry   Digg!  digg it!   del.icio.us  del.icio.us

ez publish community gateway

› Joining eZ Systems as Online Community Manager

I want to share some exciting news with our community. I will be joining eZ Systems as Online Community Manager and I hope to pick up where Nicolas Pastorino left off, as he parted eZ Systems back in August, 2014. This will be a part time position, I will continue as a member of the Community Board, and keep any other activities.

27/03/2015 7:04 pm (UTC)   http://share.ez.no   View entry   Digg!  digg it!   del.icio.us  del.icio.us

mugo web

› Custom fatal error message for eZ Publish (legacy)

Until some time ago, it was necessary to hack the eZ Publish legacy kernel in order to customize its generic error message, "Fatal error: The web server did not finish its request". This error occurs on all eZ Publish installations whenever there is an HTTP 500 status server error. It is a very common error; some examples of how it's triggered include: trying to access the value of a non-existent object attribute; the use of a non-existent PHP class or function; and too much memory usage.

Now, since this pull request from Mugo has been merged to the eZ Publish kernel, we have made it possible to customize the error page without hacking the kernel. In this post I will show you the new standard way to do this with a simple INI setting and your own PHP function.

26/03/2015 5:52 pm (UTC)   Mugo Web   View entry   Digg!  digg it!   del.icio.us  del.icio.us