ZF-3943: Zend_Db_Profiler_Firebug does not initialize header's sending

Issue Type: Bug Created: 2008-08-13T08:07:33.000+0000 Last Updated: 2008-09-02T10:39:17.000+0000 Status: Resolved Fix version(s): - 1.6.0 (02/Sep/08)

Reporter: Martin Hujer (mhujer) Assignee: Christoph Dorn (cadorn) Tags: - Zend_Log

  • Zend_Wildfire

Related issues: Attachments:


You also need to register the plugin: $front->registerPlugin(Zend_Wildfire_Channel_HttpHeaders::getInstance());

It should be done automatically or mentioned in docs



Posted by Christoph Dorn (cadorn) on 2008-08-13T10:16:20.000+0000

It is done automatically if you have initialized your front controller before calling the first DB query that the profiler is registered with.

Is this not working for you?

Posted by Matthew Weier O'Phinney (matthew) on 2008-08-13T11:01:56.000+0000

I can confirm; I have an app where I'm initializing the front control prior to the first DB query, and I'm not getting headers. In fact, even manually adding the Wildfire channel plugin is not producing any headers for me. :(

Posted by Matthew Weier O'Phinney (matthew) on 2008-08-13T11:14:47.000+0000

I've had some success now. I had to call setEnabled() on the profiler AND register the plugin manually. Once I did both tasks, all worked as expected.

Neither the constructor nor setEnabled() register the plugin, btw; I've verified this looking in the source.

My recommendation is that the profiler should be enabled by default, and the constructor should attempt to register the plugin.

Posted by Martin Hujer (mhujer) on 2008-08-13T12:50:33.000+0000

Another discussion on mailing list

Posted by Adam Jensen (jazzslider) on 2008-08-14T07:40:10.000+0000

I've been experiencing a similar issue with Zend_Log_Writer_Firebug. Please see the mailing list discussion Martin Hujer referenced yesterday for a full description.

The problem may well be the order in which plugins are Firebug logger instance works perfectly in every context except layout scripts. If the layout script is rendered after Zend_Wildfire_Channel_HttpHeaders::postDispatch() has already fired, any Firebug log messages triggered in the layout script will not make it into the final response.

Manually flushing out the headers again (Zend_Wildfire_Channel_HttpHeaders::getInstance()->flush()) at the very end of the layout script solves the issue; however, it's not an ideal solution.

Posted by Mickael Perraud (mikaelkael) on 2008-08-14T09:27:07.000+0000

Part of message exchange directly with [~cadorn]: "I use Db_Profiler_Firebug and Log_Writer_Firebug. I create Db_Profiler_Firebug in a auth plugin (dispatchLoopStartup) just for administrator. I create my logger in my bootstrap. I send info log in a postDispatch plugin (auth) just for administrator (so the first log is very late in my code).

Case 1: Just the doc => nothing in Firebug

Case 2: The doc + the manual registration => all is in Firebug

Case 3: The doc + an immediate log just after the creation of the logger (in bootstrap, so very early in my code) => all is in Firebug

I think, there is sending of headers too early. I don't know if it's due to my particular code."

Posted by Matthew Weier O'Phinney (matthew) on 2008-08-22T15:15:20.000+0000

Scheduling for RC3.

Posted by Christoph Dorn (cadorn) on 2008-08-24T00:16:47.000+0000

The registering of the plugin has been fixed for Zend_Db_Profiler_Firebug.

You only need to call setEnabled() on Zend_Db_Profiler_Firebug not Zend_Wildfire_Plugin_FirePhp as it is enabled by default.

For the issue of flushing messages in Zend_Wildfire_Channel_HttpHeaders::postDispatch() see ZF-3963.

Posted by Mickael Perraud (mikaelkael) on 2008-08-26T12:29:38.000+0000

This OK for me. ZF SVN 11073.

Posted by Wil Sinclair (wil) on 2008-09-02T10:39:17.000+0000

Updating for the 1.6.0 release.

Have you found an issue?

See the Overview section for more details.


© 2006-2018 by Zend, a Rogue Wave Company. Made with by awesome contributors.

This website is built using zend-expressive and it runs on PHP 7.